Automated Privacy Policy Generation from Application Code Analysis

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Mobile application developers are ill-equipped to address privacy concerns, leading to misuse of user data, as existing methods fail to effectively transform application access and data storage details into privacy policies, thereby compromising user privacy.

Innovation Solution

A system that processes application code to identify invoked APIs, profiles their characteristics, and maps these against policy templates to generate application-specific privacy policies, providing transparent information to users before installation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If application code is processed to identify APIs and generate privacy policies, then user privacy protection is improved, but processing complexity and time increase

Engineering Contradiction:
Improveuser privacy protectionVSAvoidprocessing complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs static analysis of application code during the app development or submission phase, before the app is installed on user devices. This preliminary processing identifies all API invocations and data access patterns in advance, allowing privacy policies to be generated beforehand. The key preliminary actions include: parsing application source code to identify API calls, analyzing data flow between APIs and sensitive data, and generating privacy policy documents before deployment.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary privacy policy generation system that acts as a mediator between application developers and end users. This intermediary component automatically analyzes application code, identifies data access behaviors, and generates privacy policies without requiring direct involvement from developers or users. The intermediary system includes modules for code parsing, API identification, data flow analysis, and policy template matching, which collectively transform raw application code into structured privacy information.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Measurement precision

If detailed profiling of API invocation characteristics is performed, then privacy policy accuracy is improved, but processing time increases

Engineering Contradiction:
Improveprivacy policy accuracyVSAvoidprocessing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system focuses its analysis on partial but critical aspects of API behavior rather than attempting to profile every possible characteristic. It specifically targets invocations of APIs that access sensitive data (location, contacts, camera, etc.) and their direct data flow paths. The analysis excludes routine API calls that do not involve sensitive data, thereby achieving sufficient accuracy for privacy policies while reducing overall processing time and complexity.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The patent transforms the analysis from examining all possible API parameters to focusing on specific critical parameters related to sensitive data access. Instead of profiling complete API invocation signatures, the system identifies and analyzes only the parameters that indicate sensitive data access patterns, such as data types being accessed, permission requirements, and data flow destinations. This parameter selection strategy maintains policy accuracy while significantly reducing processing overhead.

Inventive Principle:
Principle #35Parameter changes

3Extent of automation

If mapping against policy templates is performed, then privacy policy generation is automated, but adaptability to specific applications decreases

Engineering Contradiction:
Improvepolicy generation automationVSAvoidapplication-specific customization
Core Design Contradiction:
Extent of automationVSAdaptability or versatility

Solution Approach 1:

The patent segments the privacy policy generation process into distinct modular components: code parsing module, API identification module, data flow analysis module, template matching module, and policy generation module. Each module handles a specific aspect of the analysis and can be independently configured. The template system itself is segmented into reusable policy patterns that can be selectively applied based on the application's specific data access behaviors, allowing both automation and customization.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system employs dynamic template selection and customization based on the analyzed application characteristics. Rather than using a single static template, the system selects and adapts policy templates according to the specific types of sensitive data accessed, the frequency of API invocations, and the data flow patterns identified during static analysis. This dynamic approach allows the same automated framework to generate appropriately customized privacy policies for different applications while maintaining full automation.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS9705929B2Method and apparatus for transforming application access and data storage details to privacy policies
Publication Date: 2017.07.11 NOKIA TECHNOLOGIES OY
  • US9705929B2 patent drawing
  • US9705929B2 patent drawing
  • US9705929B2 patent drawing

AI summary

An approach is provided for transforming application access and data storage details associated with a mobile device to application specific privacy policies. A policy platform processes and/or facilitates a processing of an application code to identify one or more application programming interfaces invoked by the application code. The policy platform causes, at least in part, a profiling of one or more invocation characteristics of the one or more application programming interfaces. The policy platform further causes, at least in part, a mapping of the one or more invocation characteristics against one or more policy templates to cause, at least in part, a generation of at least one policy for the application code.