Limiting data access

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for validating data access requests of an application. One method includes receiving, for an application, a request to access data collected by a device; determining, based on contents of a twice-signed data usage token of the application, an identifier of the application and a declared usage of the data by the application; and controlling access of the application to the data, including enabling access to the data when (i) both signatures of the twice-signed data usage token have been verified, and (ii) the declared usage of the data matches an authorized usage of the data, and blocking the application from accessing the data when (i) either signature of the twice-signed data usage token has not been verified, or (ii) the declared usage of the data does not match the authorized usage of the data.

Description

Background Technology

[0001] Some devices may include multiple applications running on that device. These applications can have different trust levels. For example, the operating system on the device may have a higher trust level and access to more types of data compared to third-party applications. Some examples of third-party applications include social networking apps, web browsers, and banking apps. Summary of the Invention

[0002] To enhance data security, devices can use a double-signed data usage token from an application to verify or authenticate the application's access to data, such as personal or other sensitive data. The double-signed data usage token can identify the claimed use of data collected by the application, information about privacy policies (e.g., the application's publisher), and other relevant information. The double-signed data usage token can be an enable-level data structure, such as the data structure used at the application layer in the Open Systems Interconnection model (“OSI model”).

[0003] A double-signed data use token can be signed by both the system that has the application's data (e.g., the application's publisher or the entity that will receive the data generated by the application) and the data access authorization system. While the following examples generally discuss the application publisher's signature, the data use token can be signed by another entity, such as the entity receiving the data generated by the application. The data access authorization system could be the vendor of the device's operating system. Including both the publisher's and vendor's signatures in the double-signed data use token allows for public verification of the token, such as verifying that the token has not been altered, that the token is for the application, or both.

[0004] A device (e.g., the device's operating system) can receive system application programming interface (“API”) calls from an application to access data collected by the device. The data collected by the device can be data stored in the device's memory or data collected by sensors in the device that is not stored in persistent memory, such as heartbeat data. API calls may include a reference to a double-signed data usage token for the application. When an API call does not include a reference to a double-signed data usage token, the application, the application's publisher's system, or both may make the double-signed data usage token available to the device, such as through a system API. For example, when an application is installed on a device, the publisher's system may send a double-signed data usage token to the device. The device may store the double-signed data usage token in a double-signed token database for later use when determining whether to allow the application to access the data. In some examples, after receiving an API call from the application, the device may request a double-signed data usage token from the publisher's system.

[0005] After receiving an API call from an application to access data, the device (e.g., a system API) verifies a double-signed data usage token. The device matches the application's identity against the double-signed data usage token. When the identity matches, the device can determine what type of data the application is allowed to access based on the double-signed data usage token. When the application can access the requested data type, the device can allow or enable the application's access to the requested data, for example, by providing the requested data to the application. When the application's identity does not match, or when the application cannot access the requested data type, the device can prevent the application from accessing the requested data, for example, by deciding to skip providing the requested data to the application.

[0006] If an off-device system wants to access data collected by the device, the device can generate a token that includes the requested data and an identifier of the device, such as a pseudonym. The device can encrypt the token and provide it to an application, which can then send the token to the off-device system. The device can use the off-device system's public key to encrypt the token, for example, so that only the off-device system can decrypt the token, and the application cannot access the unencrypted data. The public key can be encoded in the double-signed data using the token.

[0007] External systems can store data in a manner that allows for later access to the data stored on the external system. For example, an external system can store a token along with a pseudonym identifier in a database. When the external system receives a data-related request, for example, from the device, it uses the pseudonym identifier to locate the token in the database and performs the corresponding action. This request could be deleting data, correcting at least some data, causing at least some data to be presented, or another appropriate action. Requests generated by the device for the external system to perform data-related actions may include pseudonyms as indicators of what data the external system should act on.

[0008] In some implementations, an application can be associated with more than one double-signed data use token. For example, a device can have double-signed data use tokens for different data uses. The first use could be for advertising purposes. The second use could be for non-advertising purposes. For example, each token used for data use outside the device could include a different public / private key pair to maintain separate access to each use.

[0009] In these implementations, upon receiving a first use request with a data use token bearing a first and second signature, the device can block access to certain types of data, and enable access to certain types of data for a second use request with a data use token bearing a second and second signature. For example, a data use token bearing a first and second signature can identify an advertisement as a claim of use, and a data use token bearing a second and second signature can identify health monitoring as a claim of use. When the device receives a request from an app to access heartbeat data associated with an advertising claim of use token, the device can block access to the heartbeat data. When the device receives another request from an app to access heartbeat data associated with a health monitoring claim of use token, the device can enable the app's access to the heartbeat data. This can improve data security, data privacy, or both.

[0010] Typically, one aspect of the subject matter described in this specification can be embodied in a method comprising the following actions: receiving a request from an application for access to data collected by the device; determining, based on the content of a data use token digitally signed by both (i) a system having the application's data and (ii) a data access authorization system, an identifier of the application and the application's claimed use of the data; and controlling the application's access to the data using the application's identifier, the claimed use of the data, and the authorized use of the data, including: enabling access to the data for the application when (i) both signatures of the double-signed data use token have been verified and (ii) the claimed use of the data matches the authorized use of the data; and preventing the application from accessing the data when (i) either signature of the double-signed data use token has not been verified, or (ii) the claimed use of the data does not match the authorized use of the data. Other embodiments of this aspect include corresponding computer systems, apparatuses, computer program products, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. A system of one or more computers can be configured to perform specific operations or actions by installing software, firmware, hardware, or a combination thereof on the system, which, in operation, causes the system to perform these actions. One or more computer programs can be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause that device to perform the actions.

[0011] The foregoing and other embodiments may each optionally include one or more of the following features (alone or in combination): Device-controlled application access to data may include device-controlled application access to data by the device's operating system. Receiving the request may include receiving a request to identify a token used to verify double-signed data.

[0012] In some implementations, the method may include: in response to receiving a request, determining an identifier for the application; and retrieving a double-signed data usage token from a token database using the application identifier. Controlling application access to data may include: the device controlling application access to data using the application identifier, the declared use of the data, one or more requested data types, and the data type of the requested data, including: enabling application access to data by the device when (i) both signatures of the double-signed data usage token have been verified, (ii) the declared use of the data matches the authorized use of the data, and (iii) neither signature has expired; and preventing the application from accessing the data when (i) either signature of the double-signed data usage token has not been verified, or (ii) the declared use of the data does not match the authorized use of the data, or (iii) either signature has expired.

[0013] In some implementations, the method may include determining one or more requested data types identified by a double-signed data use token. Controlling an application's access to the data may include: the device controlling the application's access to the data using the application's identifier, the data's claimed use, one or more requested data types, and the data type of the requested data, including: enabling the application to access the data when (i) both signatures of the double-signed data use token have been verified, (ii) the data's claimed use matches the data's authorized use, and (iii) one or more requested data types include the data type of the requested data; and preventing the application from accessing the data when (i) either signature of the double-signed data use token has not been verified, or (ii) the data's claimed use does not match the data's authorized use, or (iii) one or more requested data types do not include the data type of the requested data.

[0014] In some implementations, the application's claimed use of data may come from a predefined set of claimed data uses. One or more requested data types may come from a predefined set of data types. The double-signed data use token may include one or more of the following: a link to the application's publisher's privacy policy, the publisher's identifier, the publisher's public key, or time data indicating when the double-signed data use token expires. The time data may include: (a) a signing date, indicating when the publisher signed the double-signed data use token, after which the double-signed data use token will expire at the end of a predetermined time period; or (b) an expiration date, indicating when the double-signed data use token expires. The publisher's public key may indicate the application's claimed use of the data, the system having the application's data, or both.

[0015] In some implementations, the first signature of the system containing the application's data can verify the content of the first part of the data usage token between the two signatures. The second signature of the data access authorization system can verify the content of the data usage token between the two signatures. The first signature of the system containing the application's data can verify the application's identifier and the application's claim to use the data.

[0016] In some implementations, the method may include: receiving, by a device and for a second application different from the application, a second request for access to second data collected by the device; determining, by the device, that the device includes data access settings for the second application; in response to determining that the device includes data access settings for the second application, determining to skip analysis of any double-signed data usage tokens of the second application; and using the data access settings to control the second application's access to the second data. The method may also include: receiving, by a device and for a second application different from the application, a second request for access to second data collected by the device; determining, by the device, that the device does not have double-signed data usage tokens of the second application; in response to determining that the device does not have double-signed data usage tokens of the second application, determining a default data access setting for the second application; and using the default data access setting to control the second application's access to the second data.

[0017] In some implementations, the method may include: receiving a first request by a device and for a second application different from the application: (a) to access second data collected by the device, and (b) identifying a first double-signed data usage token of the second application using a first claim of use of the second data by the second application; determining authorized use of the second data by the device; determining by the device that the first claim of use of the second data by the second application does not match authorized use of the second data; and preventing the second application from accessing the second data in response to determining that the first claim of use of the second data by the second application does not match authorized use of the second data; receiving a second request by the device and for the second application: (a) to access the second data collected by the device, and (b) identifying a second double-signed data usage token of the second application using a second claim of use of the second data by the second application; determining by the device that the second claim of use of the second data by the second application matches authorized use of the second data; and enabling access to the second data by the device for the second application in response to determining that the second claim of use of the second data by the second application matches authorized use of the second data.

[0018] In some implementations, the use of a first declaration of second data may include using the second data for a specific purpose. The use of a second declaration of second data may include using the second data for a purpose different from that specific purpose.

[0019] In some implementations, the method may include: creating an entry in an access database when the device enables access to data for an application, the entry identifying the application and the data accessed by the application collected by the device; receiving user input from the device instructing the presentation of a user interface, the user input identifying the data accessed by the application collected by the device; and using the access database to provide instructions to cause the presentation of a user interface, the instructions identifying the data accessed by the application collected by the device. The method may include: receiving second user input from the device and when the user interface is presented, the second user input indicating a request for customized data access settings for the application; and updating the application's data access settings by the device using the request for customized data access settings for the application. The method may include: receiving a second request from the device and for the application for access to data collected by the device; determining that the device includes the application's data access settings; in response to determining that the device includes the application's data access settings, determining to skip the analysis of data usage tokens that require double signatures for the application; and using the data access settings to control the application's access to data.

[0020] In some implementations, the method may include: in response to controlling an application's access to data, the device storing a control record and a timestamp in memory, the control record indicating whether the device enables or blocks the application's access to data; the device and the application receiving a second request for access to data collected by the device; the device using the control record to determine that the device has controlled the application's access to data within a threshold time period; and in response to determining that the device has controlled the application's access to data within the threshold time period, the device controlling the application's access to data based on the control record.

[0021] In some implementations, the method may include the device determining that the application is requesting data to be used by an application outside the device. Enabling the application to access the data may include creating a token that includes the requested data; encrypting the token; and providing the encrypted token to the application. Encrypting the token may include encrypting the token using the public key of the application outside the device. Encrypting the token using the public key of the application outside the device may include encrypting the token using the public key of the application outside the device, which is included in the data usage token in two signatures.

[0022] In some implementations, the method may include: receiving, by a data access authorization system, a request from a computer associated with a system having application data to verify a single-signature data use token, the request including a single-signature data use token comprising an identifier of the application, a claim of application use of data received from a device, and a first digital signature of the system having the application data; verifying the single-signature data use token by the data access authorization system including: determining that the application is permitted to use data of a data type received from the device for the claim of use; and determining that the single-signature data use token is trustworthy using the first digital signature of the system having the application data; and generating a double-signature data use token by the data access authorization system using a second digital signature of the data access authorization system and data from the single-signature data use token including the first signature of the system having application data. Generating the double-signature data use token may include the data access authorization system generating the double-signature data use token by appending the second digital signature of the data access authorization system to the single-signature data use token. Generating a double-signed data use token may involve a data access authorization system generating the double-signed data use token by appending a second digital signature from the data access authorization system and the expiration date of the second digital signature to a single-signed data use token. The method may include: a device generating a request to delete data whose expiration date has expired; and sending a request to delete the data to a publisher system of an application outside the device. The method may include deleting data from an application outside the device in response to: receiving a request generated by the device to delete a data entry including a specific token identifier; or determining that the expiration date of the second digital signature has expired.

[0023] The subject matter described in this specification can be implemented in various embodiments and can produce one or more of the following advantages. In some implementations, the systems and methods described in this document, such as systems and methods using double-signed data usage tokens, can provide improved data security, improved user privacy, reduced likelihood of sensitive data being used for a specific purpose (e.g., advertising), reduced unauthorized data access, or a combination of two or more of these. For example, comparing claimed use of data with authorized use can improve data security, prevent an application from accessing data it does not have permission to access, improve user privacy, reduce the likelihood of sensitive data being used for a specific purpose (e.g., advertising), reduce unauthorized data access, or a combination of two or more of these. In some implementations, using a double-signed data usage token that includes signatures from both a system that has data from an application and a data access authorization system (e.g., a system managed by the device's operating system vendor) can improve data security, prevent an application from accessing data it does not have permission to access, improve user privacy, reduce the likelihood of sensitive data being used for a specific purpose (e.g., advertising), reduce unauthorized data access, or a combination of two or more of these.

[0024] In some implementations, using double-signed data usage tokens can improve data usage transparency, for example, by enabling users to view audit logs about data usage; enhance user consent, for example, by enabling users to revoke access to data for a specific application or a specific data type, or both; or improve user control, for example, by using data access requests. In some implementations, using double-signed data usage tokens can improve the strengthening of data retention policies. For example, a data access authorization system can use a double-signed data usage token that includes data retention information to strengthen a data retention policy defined by that information, so that another system (e.g., an application or another system having data from that application) can delete data collected by a computing device.

[0025] Details of one or more implementations of the subject matter described herein are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of the subject matter will become apparent from the detailed description, the drawings, and the claims. Attached Figure Description

[0026] Figure 1 An exemplary environment in which a computing device controls an application's access to data is described.

[0027] Figure 2 It is a swimlane diagram used to restrict access to data.

[0028] Figure 3 It is a flowchart used to control the process of an application's access to data.

[0029] The same reference numerals and names in each figure indicate the same elements. Detailed Implementation

[0030] Figure 1 An exemplary environment 100 is depicted in which computing device 102 controls application 116's access to data. When controlling application 116's access to data, computing device 102, such as operating system 104 running on computing device 102, can use a data access token 118 that is double-signed for application 116. Application 116 runs on computing device 102.

[0031] When a publisher develops application 116, publisher system 124 can generate a double-signed data access token, which the computing device executing application 116 can use to control data access to application 116. The double-signed data access token may include various information that computing device 102 can use to determine whether to enable or block data access to application 116, for example, to control data access to application 116. In some implementations, the double-signed data access token may include various information that computing device 102 can use to determine whether to enable or block data access to publisher system 124 via application 116, for example, to control data access to publisher system 124. Publisher system 124 may provide the double-signed data access token to computing device 102 as part of the application 116 installation or separately. Computing device 102 can then use the double-signed data access token to control application 116's access to data collected by computing device 102.

[0032] The publisher system 124 or the application developer system can generate data structures, such as single-signature data use tokens, which include multiple data fields for controlling application 116's access to data collected by the computing device. The examples in this document refer to publisher system 124, but another system can perform the operations described with reference to publisher system 124, such as an application developer system that differs from publisher system 124.

[0033] Data fields may include fields representing categories of data types that application 116 may request. Some categories may include fine-grained location data (e.g., location data 112) and biometric data (such as the user's heart rate data 110 for a computing device). Data fields may include fields for declaring the use of the data. The use of the declaration may be one of a pre-defined list of uses, selected by the publisher system 124, for example, based on developer input. The pre-defined list of uses may be generated by the data access authorization system 134.

[0034] Data fields may include privacy information fields. Privacy information may be a link to a privacy policy, data about the publisher's privacy policy, or both, such as a Uniform Resource Identifier (“URI”). Data fields may include fields for publisher identity, application identity, or both. For example, a single-signature data access token may include a publisher identifier for a computing device, a data access authorization system, or both, to be used when verifying the token using the publisher's signature. Computing device 102 may use the application's identity to verify that the requesting application is associated with a double-signature data access token included in the data access request. In an implementation, when an application requests data from an external system, for example, in lieu of or in addition to the application identifier, fields may include fields for an external system identifier. For example, when a request received by computing device 102 does not include a double-signature data access token, computing device 102 may use the application's identity to retrieve the double-signature data access token from a database.

[0035] The publisher's identifier, the identifier of the external system, or both can identify the system storing data from computing device 102. For example, the identifier could be the URI of the system storing the data.

[0036] Data fields may include fields containing human-friendly strings. Human-friendly strings may include Unicode characters. Human-friendly strings may include human-readable characters that identify the publisher's name, the application's name, or both. Human-readable characters may include Unicode characters.

[0037] The data field may include a field indicating the expiration date of the double-signed data access token. The expiration date may indicate a time after which the double-signed data access token cannot be used to verify the data access request of application 116. For example, when computing device 102 receives a double-signed data access token with an expiration date of May 12, 2023, computing device 102 may continue to use the double-signed data access token until May 12, 2023. When computing device 102 receives a data access request from application 116 after May 12, 2020, computing device 102 may determine to prevent application 116 from accessing the requested data, for example, by determining to skip providing the requested data to application 116.

[0038] In some implementations, the data field may include a signature date instead of an expiration date, or in addition to an expiration date. The signature date can indicate when the publisher system signs the content of a double-signed data use token (e.g., a single-signed data use token whose content is included in a double-signed data use token). The system can use the signature date to determine the expiration time of the double-signed data use token. For example, a system such as data access authorization system 134 or computing device 102 can determine that a double-signed data use token or a single-signed data use token expires at the end of a predetermined period of time (e.g., one or two years) after the signature date.

[0039] The data fields may include a field for the publisher's public key. In some implementations, the data fields do not include a field for the publisher's public key. Instead, device 102 or operating system 104 can directly extract the publisher's public key from the publisher's website.

[0040] The data field may include a field for the publisher's signature. A device or system can use the publisher's public key to verify that the publisher's signature is valid, for example, that the data in a single-signature data use token has not been tampered with. The publisher's signature can be a signature capable of verifying the content of the single-signature data use token, such as a digital signature. For example, publisher system 124 can use its private key to generate the publisher's signature to encode data in a single-signature data use token. Another system, such as data access authorization system 134 or computing device 102, can use publisher system 124's public key and the publisher's signature to verify the content of a single-signature data use token or the corresponding content of a double-signature data use token. For example, another system can encrypt the content of the single-signature data use token and compare the encrypted content with the publisher's signature. If they match, data access authorization system 134 can determine that the publisher's signature has been verified. If they differ, data access authorization system 134 can determine that the publisher's signature has not been verified.

[0041] Publisher System 124 at time T A A single-signature data use token is provided to the data access authorization system 134. The data access authorization system 134 uses a signature, a public key, or both to verify the content of the single-signature data use token. For example, the data access authorization system 134 can use the publisher's signature to ensure that the content of the single-signature data use token has not been modified since the publisher system 124 generated it. If the content has not been modified, the data access authorization system 134 can continue with the remainder of the verification process for the single-signature data use token. If the content has been modified, the data access authorization system 134 can determine that the single-signature data use token is invalid.

[0042] Data access authorization system 134 can verify that the public key is indeed the public key of publisher system 124. Data access authorization system 134 can use any appropriate process. For example, data access authorization system 134 can access public key databases of multiple publisher systems and determine that the public key from the single-signature data use token matches a public key in the database. In some implementations, the publisher's public key can be replaced by a digital certificate issued by a trusted certification authority (“CA”). The digital certificate includes data identifying the publisher, the publisher's public key, and the CA's identity and signature on the remainder of the digital certificate. Data access authorization system 134 can use the public key from the single-signature data use token to encrypt the content of the single-signature data use token. If the encrypted content matches the publisher's signature, data access authorization system 134 can determine that the single-signature data use token is verified. If the encrypted content differs from the publisher's signature, or if the public key from the single-signature data use token differs from a public key in the public key database, data access authorization system 134 can determine that the digital signature in the single-signature data use token is invalid. Otherwise, data signed once is valid using the digital signature in the token.

[0043] If both the public key and the digital signature are verified, the data access authorization system 134 can continue with the remainder of the verification process for the single-signature data use token. If not, the data access authorization system 134 can determine that the single-signature data use token is invalid and stop the process of creating a double-signature data use token.

[0044] Data access authorization system 134 can verify that the publisher's expiration date has not yet expired. Data access authorization system 134 can verify the expiration date by comparing it to the current date. If the current date is after the expiration date, data access authorization system 134 can determine that the expiration date has expired. If the current date is before or the same as the expiration date, data access authorization system 134 can determine that the expiration date has not yet expired. If the date has not expired, data access authorization system 134 can continue with the remainder of the verification process for a single-signature data use token. If the date has expired, data access authorization system 134 can determine that the single-signature data use token is invalid and stop the process of creating a double-signature data use token.

[0045] In some implementations, the data access authorization system 134 can verify a single-signature data use token by validating whether the application 116 should be allowed to access data based on the claimed use, the category of the requested data type, or both. For example, the data access authorization system 134 can determine whether the application 116 should be able to access the requested data category, such as location data and biometric data, based on the claimed use, such as advertising or health monitoring. For instance, the data access authorization system 134 can determine that the application 116 should not access biometric data used for advertising claims, but can access biometric data used for health monitoring claims.

[0046] Data access authorization system 134 may include a database that identifies data types, allowing applications to access those data types for the corresponding claims. Data access authorization system 134 can verify the use of a claim and the requested data type category by determining whether the database associates each data type category with the use of the claim. If the database does not associate each data type category with the use of the claim, data access authorization system 134 may determine that a single-signed data use token is invalid, or create a double-signed data use token that is limited to the data type associated with the use of the claim in the database and originates from a single-signed data use token. If the database associates each data type category with the use of the claim, data access authorization system 134 may determine that a single-signed data use token is valid based on the use of the claim and the requested data type category.

[0047] In some implementations, the verification process may include testing of the corresponding application. For example, data access authorization system 134 may test application 116 to determine the data requested by application 116. When the data type requested by application 116 corresponds to the category of the requested data type, data access authorization system 134 may determine that the token is valid, for example, assuming that all other parts of the verification process have also passed. When at least one of the data types requested by application 116 is different from the category of the requested data type, data access authorization system 134 may determine that the token is invalid.

[0048] Data access authorization system 134 generates a double-signed data use token 118 for application 116. During creation, data access authorization system 134 may generate a data structure including the contents of a single-signed data use token with one or more additional fields. The additional fields may include an authorization system expiration date. The authorization system expiration date may indicate a time after which the double-signed data use token cannot be used to verify application 116's access to data. The authorization system expiration date may be the same as or a different date from the expiration date of the single-signed data use token.

[0049] Double-signed data use tokens can include one or more expiration dates to ensure that publisher system 124 updates the double-signed data use token used by application 116 to continue accessing the data collected by the computing device. This can increase data security, privacy, or both. In some implementations, the use of expiration dates can ensure that changes to the publisher's privacy policy are reflected in the double-signed data use token. An expiration date in a single-signed data structure can imply the publisher's commitment to the privacy policy at least until the expiration date.

[0050] The double-signed data use token includes a field for the signature of the data access authorization system 134. After verifying the single-signed data use token, the data access authorization system 134 can generate a second signature. The second signature can be a digital signature that verifies the content of the double-signed data use token. For example, the second signature can be used to verify the content of the data signature from the single-signed token, such as fields including the publisher's signature and the authorization system expiration date. The publisher's signature and the second signature can be byte arrays, for example, 64 bytes in size when using an elliptic curve digital signature algorithm. The elliptic curve digital signature algorithm can use the P-256 curve from the National Institute of Standards and Technology (“NIST”). The publisher's public key and the public key of the data access authorization system 134 can be in a compressed format, for example, a 33-byte compressed format of the NIST P-256 curve or a 64-byte uncompressed format of the NIST P-256 curve. The system can use compressed signatures to reduce bandwidth requirements, for example, when generating the double-signed data use token, when providing the double-signed data use token for a data access request, or both. In some implementations, the system can use the Edwards curve digital signature algorithm, such as the ED25519 curve, which has a 32-byte public key size and a 64-byte digital signature.

[0051] The publisher's signature, the second signature, the publisher's public key, or a combination thereof, can be encrypted, for example, using 256-bit encryption. For instance, data access authorization system 134 can use the Elliptic Curve Digital Signature Algorithm (“ECDSA”) to generate its signature. Publisher system 124 can use ECDSA to generate its signature.

[0052] At time T BThe publisher system 124 receives a double-signed data usage token from the data access authorization system 134. The publisher system 124 stores the double-signed data usage token 118 in a double-signed token database 128. For example, the publisher system 124 includes an application database 126 containing data for each of multiple applications, including application 116. This data may include executable programs or other files that implement the application on a device such as computing device 102. This data may include references to multiple applications, such as identifiers, references to the location of files storing the applications, or both.

[0053] As part of the same database or a separate database, publisher system 124 maintains a double-signed token database 128, which includes tokens for some or all applications identified by application database 126. For example, publisher system 124 may include double-signed data usage tokens for each application referenced in published application database 126 in the double-signed token database 128.

[0054] In some examples, the token can be version-specific. For instance, publisher system 124 can maintain a double-signed data use token for each application version (e.g., any version or any major version) in a double-signed token database 128. In some implementations, the permitted application versions can be encoded in the double-signed data use token.

[0055] Based on the installation of application 116 on computing device 102, computing device 102 at time T C The data usage token 118 is received from the publisher system 124 or from the application 116 itself. For example, the computing device 102 may receive data instructing user input. The user input may be a command to install the application 116. The computing device 102 may request installation data from the publisher system 124 in response to the user input. The publisher system 124 may be specific to a single application publisher or include data from multiple different publishers, and it may provide the installation data to the computing device 102. The installation data may include the double-signed data usage token 118. In some examples, the publisher system 124 may send the double-signed data usage token separately from the installation data to the computing device 102. In some examples, the double-signed data usage token may be carried by the application 116, for example, as part of an application resource.

[0056] In some implementations, application 116 may be installed on computing device 102 as part of the initial device setup. For example, application 116 may be installed when the software is initially placed on computing device 102, such as along with operating system 104, when the user first configures computing device 102, or at another appropriate time.

[0057] Based on the installation of application 116, or as part of the installation of application 116, computing device 102 can receive a double-signed data usage token 118. Computing device 102 stores the double-signed data usage token 118 in memory. For example, when executing on computing device 102, application 116 can store the double-signed data usage token 118 in memory as part of the application 116's data. Computing device 102 can store the double-signed data usage token 118 in a token database, for example, maintained by operating system 104. For example, application 116 may not be able to access the token database, and only operating system 104 can access the token database.

[0058] When computing device 102 (e.g., operating system 104) receives a request to access data from application 116, computing device 102 determines a double-signed data usage token 118 for the application 116. The request may include the double-signed data usage token 118. Computing device 102 can retrieve the double-signed data usage token 118 from the request.

[0059] When the request does not include the double-signed data usage token 118, the computing device 102 can use an identifier of the application 116 to determine the double-signed data usage token 118 of the application 116, which is included in the request or based on a request received from the application 116. For example, the computing device 102 can use this identifier as a key for a token database that includes double-signed data usage tokens for applications installed on the computing device 102. The computing device 102 can retrieve records from the database identified by this key. These records may include the double-signed data usage token 118.

[0060] In some examples, computing device 102 may use an identifier of application 116 to request a double-signed data usage token 118 from another system. For example, after receiving a data access request, computing device 102 may request the double-signed data usage token 118 from publisher system 124, data access authorization system 134, or another system. Computing device 102 may request the double-signed data usage token 118 from another system when computing device 102 first executes application 116, when computing device 102 first receives a request from application 116 for data collected by computing device 102, or at another appropriate time. Computing device 102 may store the double-signed data usage token 118 received from another system in a database, such as a database for double-signed data usage tokens for applications on computing device 102.

[0061] The verification engine 106 on computing device 102 uses a double-signed data usage token 118 to verify the data access request of application 116. For example, the verification engine 106 uses the category of the requested data type, the declared data usage, or other data from the double-signed data usage token to verify the data access request of application 116.

[0062] As part of the verification process, verification engine 106 can verify one or both signatures included in the data use token that is signed twice. For example, verification engine 106 can use the publisher's signature to verify the category of the requested data type, the declared data use, privacy policy data, the publisher's identifier, the identifier of application 116, the publisher's public key, the publisher's expiration date, or a combination of two or more of these. Verification engine can use the signature of data access authorization system 134 to verify the publisher's signature, the category of the requested data type, the declared data use, privacy policy data, the publisher's identifier, the identifier of application 116, the publisher's public key, the publisher's expiration date, the authorization system expiration date, or a combination of two or more of these.

[0063] Verification engine 106 can verify a signature by encrypting the content corresponding to the signature using a public key. For a publisher's signature, verification engine 106 can use the publisher's public key. For a data access authorization system signature, verification engine 106 can use the data access authorization system's public key. When the encrypted content matches the signature, verification engine 106 can determine that the content has been verified. A publisher's signature can correspond to data included in a single-signature data use token. A data access authorization system signature can correspond to all other data included in a double-signature data use token.

[0064] When the verification engine 106 determines that the request is invalid, the computing device 102 prevents the application 116 from accessing the requested data. For example, the verification engine 106, the operating system 104, or both may prevent the application 116 from accessing the requested data. Blocking access may include providing the application 116 with a response indicating that the request has been denied. Blocking access may include determining that the privileges necessary for the application 116 to access the requested data are not granted.

[0065] When the verification engine 106 determines that the request is valid, the computing device 102 enables the application 116 to access the requested data. For example, the verification engine 106, the operating system 104, or both can change the data access privileges for the requested data to enable the application 116 to access that data. In some examples, the computing device 102 can provide the requested data to the application 116, such as heart rate data 110 or location data 112.

[0066] Upon receiving requested data, application 116 may store the requested data in memory as sensitive data 120 collected by computing device 102. Application 116 may use the sensitive data, for example, based on the use of a token claim derived from data with two signatures. For example, health monitoring application 116 may analyze the data and generate a user interface with information about the received data.

[0067] When computing device 102 provides requested data to application 116, computing device 102 adds an entry in audit log 108 that identifies application 116, such as an identifier for the application. This entry may identify the data type provided to application 116, the declared use of the data, the category of the requested data type, the specific data provided to application 116, or a combination of two or more of these.

[0068] Entries in audit log 108 may include the publisher's signature, a double-signed data usage token, an application identifier, the publisher's identifier, or a combination of two or more of these. For example, computing device 102 may add a double-signed data usage token to an entry in audit log 108 to facilitate later retrieval of information about data accessed by application 116, publisher system 124, or both. In some examples, the application identifier, publisher identifier, or both may be, for example, a human-friendly string derived from a double-signed data usage token. In some examples, the entry may indicate whether application 116 is allowed or denied access to the requested data; for example, computing device 102 may create an entry in audit log 108 for a denied request when application 116's data access is blocked.

[0069] Computing device 102 may use audit log 108 to generate a user interface, which, for example, presents information to the user of computing device 102 about data provided to applications running on computing device 102, and / or enables the user to take actions regarding the application's use of the information. See below for reference. Figure 2 In more detail, the user interface can enable changes to application data access, such as application data privileges, deletion of sensitive data 120 stored by application 116, or other appropriate privacy control features.

[0070] In some implementations, application 116 requests access to data stored on a remote system (e.g., publisher system 124). For example, application 116 may be part of a navigation system. As part of the navigation system, application 116 may request access to location data 112 that the application will provide to publisher system 124 to obtain driving directions to another location.

[0071] When a request is made to use data on a remote (e.g., external) system, application 116 may use a data use token that is double-signed by the external system. For example, application 116 may provide a request to computing device 102 that includes a token having an identifier of the external system that is either an identifier for application 116 or an identifier for the external system.

[0072] When computing device 102 receives a request for data to be stored on an external system, token generation engine 114 processes the data in response to the request. Token generation engine 114 can generate a token that includes, for example, response data and an identifier from computing device 102 or a token. This token can be any suitable token. In some cases, the token can be a proof token, such as a proof token digitally signed by computing device 102. The proof token can be digitally signed to prove that the data included in the token has not been tampered with.

[0073] In addition to the data in response to the request, the token may also include data, such as location data 112. The token may include the type of response data. The token may include authorized use of the data, claimed use of the data, or both. The token may include an expiration date indicating the date the remote system will delete the data from the remote system. The token may include an identifier of the remote system, such as a publisher identifier. When processing the data, the external system may use the additional data in the token, for example, to ensure that the external system complies with claimed use or authorized use, or to determine how to process the data using the data type, or a combination of these.

[0074] The token generation engine 114 can encrypt the data in the token. For example, the token generation engine 114 can use, for example, data from two signatures to encrypt the data in the token using the token issuer's public key. The token generation engine 114 can use any appropriate method to encrypt the data in the token.

[0075] Computing device 102 provides a token to application 116. When the data in the token is encrypted, application 116 cannot access the encrypted data because application 116 does not have the publisher's private key. This increases data security by preventing applications from accessing data authorized to publisher system 124 (e.g., as an external system) but not authorized to application 116, even if application 116 requests data from computing device 102. This increases privacy by preventing unauthorized applications (e.g., application 116) from accessing data.

[0076] Application 116 at time T D Provide a token to publisher system 124, such as as a proof token. For example, application 116 may provide publisher system 124, which is part of a navigation system, with the approximate current physical location (e.g., GPS location) of computing device 102 (e.g., mobile device).

[0077] The publisher system 124 receives the token and processes the data within it. For example, the publisher system 124 can decrypt the token, extract location data 112 from the decrypted token, and process the location data 112. The publisher system 124 can use the token decryption engine 130 to decrypt the token. The token decryption engine 130 can use any appropriate method to decrypt the token, for example, using the publisher's private key. The publisher system 124 can provide data to the application 116 so that the application 116 can present driving instructions in the user interface based on the processing of the data.

[0078] The publisher system 124 can store data from the token in a database, which may include, for example, external sensitive data 132. For example, the publisher system 124, and the token decryption engine 130, can create entries in the external sensitive data 132. These entries include identifiers of the data extracted from the token. These identifiers may be identifiers of the computing device 102, such as identifiers of accounts associated with the computing device 102.

[0079] The identifier can be a token identifier, for example, it cannot be used to associate the token's payload with computing device 102. For example, the token generation engine 114 on computing device 102 can create a pseudonym token identifier specific to that token. The token generation engine 114 can generate the pseudonym token identifier using the token's content, a random number, the identifier of computing device 102, or other appropriate data.

[0080] Including an identifier in the entry for external sensitive data 132 enables computing device 102 to instruct publisher system 124 to perform actions related to a specific application, a specific token, or data of computing device 102, such as improving privacy, data security, or both. For example, when computing device 102 presents a user interface to a user of computing device 102 regarding data accessed by application 116, computing device 102 may receive data from a user request instructing application 116, publisher system 124, or both to delete sensitive data stored in memory by the corresponding application or system. Although this example involves deleting data, the user interface may include menu options for any other appropriate actions on the data. Other appropriate actions may include presenting at least some data or correcting at least some data.

[0081] When computing device 102 receives a request to delete data stored on publisher system 124, computing device 102 can access audit log 108. Computing device 102 can use audit log 108 to determine the token sent to publisher system 124. For example, when computing device 102 sends a token to publisher system 124, computing device 102 can create an audit entry in audit log 108 that identifies the requested data, application 116, publisher system 124, and token identifier. The audit entry may include the expiration date of the data sent to publisher system 124.

[0082] Computing device 102 uses data from application 116, publisher system 124, or both, such as identifiers, to determine audit entries in the publisher system's audit log 108. For each determined entry, computing device 102 determines a corresponding token identifier. Computing device 102 can generate a request to delete data on publisher system 124, including the token identifier of the token sent to publisher system 124. Computing device 102 can then send the request to publisher system 124. This allows control at computing device 102 over the continued storage of sensitive off-device data 132 originating from computing device 102, thereby improving privacy, data security, or both.

[0083] The publisher system 124 receives and processes deletion requests. For example, the publisher system 124 determines that the request is for deleting an entry from external sensitive data 132 and determines a token identifier based on the request. The publisher system uses the token identifier to identify the entry from external sensitive data 132 and deletes the identified entry. This allows the computing device 102 to control what data is stored on external systems while maintaining user privacy, for example, when using pseudonyms.

[0084] When the publisher system 124 is at time T DUpon receiving a token, the publisher system 124 can use the data type identified in the token to determine how to process the token. For example, when the publisher system 124 communicates with multiple different types of applications, receives multiple different types of data, or both, the publisher system 124 can determine how to process the data using the data type included in the token. For example, the publisher system 124 can communicate with a cardiac monitoring application that provides heart rate data and a blood pressure application that provides blood pressure data. When the publisher system 124 receives data from an application, it can use the data type from the token to determine the data type. The publisher system 124 can use the data type to determine how to process the data in the token. The publisher system 124 can perform a first processing step on the heart rate data, such as determining whether the heart rate is within an acceptable heart rate range, and a second processing step on the blood pressure data, such as determining whether the blood pressure is within an acceptable blood pressure range.

[0085] The publisher system 124 can use expiration data from the token to determine when to delete received data. For example, when the expiration data indicates that the data can only be temporarily stored, the publisher system 124 will not store the data from the token in long-term storage. The publisher system 124 may include expiration data in entries stored in external sensitive data 132. The publisher system 124 may periodically analyze the expiration data in external sensitive data 132 and delete expired entries.

[0086] In some implementations, application 116 may be associated with multiple different double-signed data use tokens. Each of the double-signed data use tokens may request a different category of data type. Each of the double-signed data use tokens may have a different claim of use. Each of the double-signed data use tokens may have a different publisher signature, a different authorization system signature, or both. For example, application 116 may have a non-advertising double-signed data use token 118 and an advertising double-signed data use token 122.

[0087] When application 116 requests data from computing device 102, application 116's request identification verification engine 106 should use which double-signed data usage token to verify the request. For example, the request may include a specific double-signed data usage token. The request may reference a memory location storing the specific double-signed data usage token.

[0088] Verification engine 106 can use a specific double-signed data usage token to verify application 116's request. For example, when application 116 requests access to heart rate data 110, verification engine 106 will allow application 116 to access heart rate data 110 based on a non-advertising double-signed data usage token 118, but will prevent application 116 from accessing heart rate data 110 based on an advertising double-signed data usage token 122. This can improve user privacy, reduce the possibility that sensitive data is used for specific purposes (e.g., advertising purposes), or both.

[0089] Publisher system 124 and data access authorization system 134 are examples of systems implemented as computer programs on one or more computers in one or more locations, wherein the systems, components and technologies described in this document are implemented. Computing device 102 may be a personal computer, a mobile communication device, or another device that can send and receive data via network 136. Networks such as local area networks (LANs), wide area networks (WANs), the Internet, or combinations thereof connect computing device 102, publisher system 124, and data access authorization system 134. Publisher system 124, data access authorization system 134, or both are examples of systems that can use a single server computer or multiple server computers operating in combination, including, for example, a group of remote computers deployed for cloud computing services.

[0090] Computing device 102 may include several different functional components, including verification engine 106 and token generation engine 114. Publisher system 124 may include several different functional components, including token decryption engine 130. Verification engine 106, token generation engine 114, token decryption engine 130, or combinations thereof may include one or more data processing devices. For example, each of verification engine 106, token generation engine 114, and token decryption engine 130 may include one or more data processors and instructions that cause the one or more data processors to perform the operations discussed herein.

[0091] Various functional components of computing device 102, publisher system 124, or both can be installed on one or more computers as independent functional components or as different modules of the same functional component. For example, verification engine 106, token generation engine 114, and token decryption engine 130 can be implemented as computer programs installed on one or more computers in one or more locations coupled to each other via a network. In, for example, cloud-based systems, these components can be implemented through various computing nodes of a distributed computing system.

[0092] Figure 2This is a swimlane diagram of process 200 used to restrict access to data. For example, various steps in process 200 can be used by computing device 102, such as operating system 104, application 116, or publisher system 124 from environment 100.

[0093] The publisher system or data access authorization system provides a double-signed token (202). For example, after the publisher system receives a double-signed data use token from the access authorization system, as part of a token update process, when the corresponding application is installed on the computing device, or at another appropriate time, the publisher system may provide a double-signed data use token. The publisher system may provide a double-signed data use token in response to a request for a token, for example, from an application or from the computing device.

[0094] The application receives and caches a double-signed token (204). For example, the application receives a double-signed data token from a publisher system. The application can cache the double-signed data token in the memory of the application's computing device. The application can cache the double-signed data token in memory at a location associated with the application, such as data containing the application.

[0095] In some examples, a double-signed data usage token stored on a computing device and associated with the application is updated. The application or computing device can perform the double-signed data usage token update process. The update process can occur periodically, such as monthly, yearly, or at another appropriate time.

[0096] In some implementations, the update process can occur when the double-signed data usage token expires or is close to its expiration date. For example, when an application determines that the publisher's expiration date, the authentication system's expiration date, or both have passed, the application can request a double-signed data usage token from the publisher system.

[0097] The application sends a request for sensitive data (206). The application may send the request to another component in the operating system or computing device. For example, the application may send a request to a sensor included in the computing device, such as a heart rate sensor.

[0098] The operating system receives a request for sensitive data (208). Any appropriate component or combination of components in the computing device may receive the request and perform one or more of steps 208 to 222, steps 226 and 232, or a combination of two or more of these.

[0099] The operating system determines the requesting application (210). For example, the operating system uses the requested data to determine an identifier for the application. For example, the request may include an identifier when it includes a token for data that has been signed twice. For example, the request may reference an identifier when it includes a reference to a memory location that stores the token for data that has been signed twice. The operating system may determine the identifier based on the request received from the application.

[0100] When the operating system receives a request for data used by an external system, the operating system can identify the external system making the request, for example, in addition to identifying the application making the request. For example, the operating system can use a token to determine the identifier of the external system using data included in the request and signed twice for the external system.

[0101] The operating system accesses the application's double-signed token (212). For example, the operating system accesses a double-signed data usage token included in the request, which is identified in the request in another way, for example, and is stored in memory. The memory location may be application-specific, part of a database of double-signed data usage tokens, or both.

[0102] When a request does not reference a double-signed data use token, or references an invalid double-signed data use token, the operating system can use data privilege settings included in the computing device to determine whether to allow the application to access the requested data. For example, the operating system can determine whether the request references a double-signed data use token, whether the token is valid, or both.

[0103] If the request does not reference a double-signed data use token, or if the token is invalid, the operating system can retrieve the computing device's data privilege settings. Data privilege settings may include settings indicating the types of data an application can access. These settings can be default settings, user-specified settings, or both. The operating system applies the data privilege settings to the request to control the application's access to the requested data.

[0104] In some examples, if the request does not reference a double-signed data use token, or if the token is invalid, the operating system may generate and render a user interface that requests user input specifying the data privilege settings for the application. For example, the operating system may determine that the data privilege settings on the computing device do not include any settings for the application, such as application-specific settings compared to the default settings, and generate a user interface in response.

[0105] The operating system uses a double-signed token to verify the request (214). For example, when the operating system has a double-signed data-using token for a request, the operating system verifies the request as described elsewhere in this document.

[0106] The operating system can validate a subset of requests received from an application. For example, when data signed twice by the application is updated using a token, or at another appropriate time, the operating system can periodically (e.g., weekly) validate requests for the same data type. The operating system can also validate requests based on the amount of data requested (e.g., payload size). For example, the operating system can validate the first request received from the application for a specific type of data, as well as all subsequent requests for data of at least a threshold amount.

[0107] For verification requests, the operating system can collect the requested data for the application. For example, the operating system can retrieve the requested data from memory. When the request is for data not currently stored in memory, such as sensor data, the operating system can receive that data.

[0108] The operating system creates and encrypts a proof token (216). For example, when the required data is for an external system, the operating system can create a token. The operating system creates a token that includes the requested data as a payload within the token. The operating system can, for example, use the public key of the requested external system to encrypt the data.

[0109] The operating system logs application access to sensitive data (218). When the access is directed to an external system, the operating system may log the external system's access to sensitive data. The external system record includes the external system's identifier. The external system record may include the application's identifier.

[0110] An operating system can log access to sensitive data by sending a request to an auditing system, thereby creating a database entry that includes information about the request. The entry can include either data from two signed data-using tokens. The entry can include information about the computing device, the time the data was provided, or both. In some examples, the auditing system can be a remote system. In some examples, the auditing system can reside on the computing device, such as computing device 102, or be part of the device's operating system.

[0111] The audit system creates log entries (220). Log entries can be entries in the database that include information about sensitive data, applications requesting sensitive data, external systems receiving data, or a combination of two or more of these.

[0112] The operating system provides sensitive data (222). For example, the operating system enables applications to access sensitive data.

[0113] The application receives sensitive data (224). When the sensitive data is included in an authentication token, the application can forward the token to an external system. The application can determine which external system to forward the data to based on the system on which the application provides services on the computing device, such as a navigation system, or by using another appropriate method, using an identifier of the external system included in the token.

[0114] The operating system requests the use of sensitive data (226). The operating system may receive user input that instructs the presentation of a user interface including information about the use of sensitive data. The operating system may send a request in response to the receipt of the user input. The request may be directed to a specific application on the computing device, all applications, or a subset of applications.

[0115] The audit system retrieves log entries (228). For example, the audit system receives a request and, in response to the request, determines log entries. The audit system retrieves the determined entries from the database.

[0116] The auditing system provides log entries (230). For example, the auditing system provides retrieved log entries to the operating system or to applications running on computing devices that request sensitive data usage information.

[0117] The operating system uses a user interface to present sensitive data (232). The operating system can generate instructions for presenting the user interface and provide these instructions to applications or other components in the computing device. For example, the operating system can provide instructions to a graphics processing unit included in the computing device.

[0118] The Sensitive Data Use User Interface (SUI) can describe any appropriate information about which applications accessed which data. The SUI can describe the application's claimed data usage. The SUI can describe the identity of the application's publisher. The SUI may include a link to the publisher's privacy policy, such as a data usage token based on double signatures. The privacy policy can be the current privacy policy, the privacy policy in effect when the data is accessed, or both.

[0119] The sensitive data access user interface can include customized options for enabling data privilege settings. For example, for each application accessing data or sensitive data, the sensitive data access user interface can include options for customizing the application's data privilege settings. When the sensitive data access user interface is presented, the operating system can receive user input indicating a request for customized data access settings for that application. In response, the operating system can update the application's data access settings using the request for customized data access settings for that application.

[0120] The sensitive data usage user interface may include options to enable deletion, correction, or other access to sensitive data accessed by an application, a subset of applications (e.g., all map applications), or all applications. Beyond data deletion, the examples here apply to other types of data access. For instance, for each application accessing data or sensitive data, the sensitive data usage user interface may include a menu option that, when selected, causes the operating system to send a request to the application instructing it to delete all data received from the computing device. In implementations where data is stored off-device, the menu option could cause an external system to delete data received from the computing device, for example, using a device identifier or token identifier.

[0121] In some implementations, the operating system may use an application's double-signed data usage token until it receives the application's data privilege settings. For example, the computing device may receive the application's double-signed data usage token when the application is first installed on a computing device, such as as part of a factory installation process, or after it has been sold to an end user. When the computing device uses the application's double-signed data usage token, it may include one or more default data privilege settings, such as those for that application or another application. The computing device may not use the application's default data privilege settings because it possesses the application's double-signed data usage token.

[0122] When a computing device receives a data access request from an application, the computing device can determine whether it includes the application's user-specified data privilege settings. If it determines that the computing device does not include the application's user-specified data privilege settings, the computing device (e.g., the operating system) can use the application's double-signed data access token to verify the application's data access.

[0123] If a computing device receives user input data instructing an application to set user-specified data privileges, for example, after or during the presentation of a sensitive data usage user interface, the computing device creates the application's user-specified data privilege settings. When the application requests access to data after creating the user-specified data privilege settings, the computing device applies those user-specified data privilege settings instead of using a double-signed data usage token.

[0124] The order of steps in process 200 above is illustrative only, and restrictions on data access can be performed in a different order. For example, the operating system may log an application's access to sensitive data before using the token to verify a request with data signed twice; for example, logging all requests, including those that are rejected. In some implementations, the operating system may log an application's access to sensitive data and then create and encrypt a proof token.

[0125] In some implementations, the computing device may provide the data access authorization system with data about data usage requests, such as anonymous data that only identifies the application identifier and the type of data requested, for later use. The data access authorization system can use the received data when verifying the application's future two-signature data usage tokens. The data access authorization system can authorize applications to access more limited types of data that these applications more frequently request from the corresponding two-signature data usage tokens, data beyond the declared type, the requested data type category, or both. The data access authorization system can also authorize applications to access more types of data that conform to the usage declared in the corresponding two-signature data usage tokens, the category of the requested data type, or both.

[0126] In some implementations, process 200 may include additional steps, fewer steps, or some steps may be divided into multiple steps. For example, the operating system may execute steps 208, 214, 218, and 222 without executing the other steps in process 200. The operating system may execute steps 208 to 218 and step 222 without executing the other steps in process 200. The operating system may execute steps 226 and 232 without executing the other steps in process 200.

[0127] Figure 3 This is a flowchart of a process 300 for controlling an application's access to data. For example, process 300 may be used by computing device 102 or data access authorization system 134 from environment 100, or a combination of both.

[0128] The data access authorization system receives a request to verify a single-signature data use token for an application, the request including the single-signature data use token (302). The single-signature data use token includes an identifier of the application requesting access to data from the computing device. The single-signature data use token includes a claim of use of data received from the computing device and by the application or by a remote system, and a first digital signature for the publisher of the application or for the remote system.

[0129] A data access authorization system can receive requests for publishers from a computer or system. For example, the publisher's system can generate a token that includes, for example, one or more requested data types as a payload, a claim of use of data received from a computing device and by an application or the publisher's system, a link to the publisher's privacy policy, the publisher's identifier, the publisher's public key, the application's identifier, time data indicating when the data use token expires after two signatures, or a combination of two or more of these. The publisher's system can generate a first digital signature for the data included in the token (e.g., the data included in the payload). The publisher's system can use, for example, a private key consistent with the public key to generate the first digital signature to authenticate that the data in the token originates from the publisher's computer. The publisher's system can include the first digital signature in the token. The publisher's system can provide a token to the data access authorization system, the token including the first digital signature and other data.

[0130] The data access authorization system verifies the single-signature data usage token (304). For example, the data access authorization system may verify the claimed use, the first digital signature, or both. In some examples, the data access authorization system may verify time data, for example, to ensure that the single-signature data usage token has not expired.

[0131] A data access authorization system can verify the use of a claimed statement by determining whether an application is allowed to use the data it receives from the device for that stated use. If the data access authorization system determines, for example, that the claimed use matches the application's permitted use using a whitelist of application types and claimed uses, then the system can verify the claimed use. For example, a whitelist could indicate that a health app is allowed access to heart rate information, and a navigation app is allowed access to location data, etc.

[0132] A data access authorization system can verify a first digital signature by determining whether the first digital signature was actually generated by the system for the publisher. For example, a data access authorization system can determine that a single-signature data use token is trustworthy and was generated by the publisher's system using the publisher's first digital signature, the publisher's public key, the content of the token, or a combination of two or more of these.

[0133] The data access authorization system uses a second digital signature for the data access authorization system and data from a single-signature data use token to generate a double-signature data use token (306). For example, the data access authorization system can append the second digital signature of the data access authorization system to the single-signature data use token. The data access authorization system can generate a new token that includes the second digital signature and data from the single-signature data use token, such as the payload and first digital signature from the single-signature data use token. The data access authorization system can add the second digital signature to the single-signature data use token to generate a double-signature data use token.

[0134] In some examples, a data access authorization system can add an expiration date to a single-signed data use token to generate a double-signed data use token. The expiration date can indicate the date on which data accessed using the double-signed data use token expires. For example, when an application or other system accessing data collected by a computing device determines that the current date matches the expiration date, the application or other system deletes the data collected by the computing device and received by the application or other system, for example, if the data had not been previously deleted. In some implementations, the publisher system includes the expiration date in the single-signed data use token.

[0135] The computing device receives a double-signed data usage token (308). For example, when the computing device includes a database of double-signed data usage tokens, the computing device can receive the double-signed data usage tokens from a data access authorization system. The computing device can store the double-signed data usage tokens in memory, for example, in a database or in the corresponding application's data storage.

[0136] In some implementations, the computing device receives a double-signed data usage token from the data access authorization system. This can occur either after the corresponding application is installed on the computing device, after the data access authorization system generates the double-signed data usage token, or in both cases.

[0137] In some examples, the data access authorization system provides a double-signed data usage token to the publisher's computer system. The publisher's computer system can then associate the double-signed data usage token with an application. For example, the publisher's computer system may include a database of entries that include the double-signed data usage token and the associated application identifier. The publisher's computer system can then add the received double-signed data usage token along with the corresponding application identifier to the database.

[0138] When an application is installed on a computing device, the publisher's computer system can retrieve a double-signed data usage token from a database and provide it to the computing device. In some examples, the application may maintain the double-signed data usage token on the computing device. The computing device may, for example, maintain the double-signed data usage token in a token database.

[0139] The computing device receives a request (310) from an application to access data collected by the computing device. This request may identify the application, reference a double-signed data use token, or both. For example, when the request includes a double-signed data use token, the token includes an identifier for the application. In some implementations, the computing device determines that the identifier from the token matches the identity of the calling application.

[0140] The computing device determines the application's identifier and the application's claim to use the data based on the contents of a double-signed data use token, which has been digitally signed by (i) a system possessing the application's data, such as the application's publisher or a remote system receiving sensitive data from the application, and (ii) a data access authorization system (312). For example, when the computing device receives a double-signed data use token in a request, the computing device can retrieve the identifier and the claim to use the data from the request.

[0141] When a computing device does not receive a token with two signatures, it can determine the identification information of the application from which it received the request. The computing device can use data in the request that identifies the application to determine its identity, whether it's an application identifier or other data such as a device-specific process identifier for the currently executing application.

[0142] A computing device can use identification information to retrieve a double-signed data usage token. For example, a computing device can use identification information to access a database to retrieve a double-signed data usage token from the database. In some examples, a computing device can use identification information to request a double-signed data usage token from another system (e.g., the publisher's computer system).

[0143] The computing device uses application identifiers, data claim usage, and data authorization usage to control application access to data (314). For example, the computing device authorizes an application to access data, provides data to an application, or otherwise controls an application's access to data.

[0144] The control may include enabling the application to access the data via a computing device when (i) either signature of the data use token that has been signed twice has been verified, and (ii) the claimed use of the data matches the authorized use of the data. The control may also include blocking the application from accessing the data when (i) neither signature of the data use token that has been signed twice has been verified, or (ii) the claimed use of the data does not match the authorized use of the data, or (iii) the requested data does not match the authorized data category, or (iii) either signature of the data use token that has been signed twice has expired.

[0145] A computing device can enable access by providing data to an application. Alternatively, it can enable access by sending a message to the corresponding component (e.g., a sensor or a software application, or both) instructing that component to provide the requested data to the application. Another method is to enable access, for example, by updating permission settings at the operating system level to indicate that the application can access the data.

[0146] A computing device can block access by determining to skip providing data to an application. A computing device can also block access by providing an application with a message instructing it not to be given the requested data. Alternatively, a computing device can block access by, for example, updating permission settings at the operating system level to instruct the application not to access data. In some examples, after the computing device blocks access, the application can explicitly request permission via the computing device's data access settings user interface. The application can then, for example, present a user interface to the user that includes user interface options to grant the application access to data.

[0147] The order of steps in process 300 above is illustrative only, and the control application's access to data can be executed in a different order. For example, the device may receive data using a token that has been signed twice as part of the request. The device may also receive data using a token that has been signed twice after the request has been received.

[0148] In some implementations, process 300 may include additional steps, fewer steps, or some steps may be divided into multiple steps. For example, process 300 may include only steps 308 to 314 or only steps 310 to 314.

[0149] In some implementations, the computing device may use the requested data type when controlling an application's access to data. For example, the computing device may determine one or more requested data types identified by a double-signed data usage token. Then, the computing device may enable the application to access the data when (i) both signatures of the double-signed data usage token have been verified, (ii) the claimed use of the data matches the authorized use of the data, and (iii) one or more requested data types include the data type of the requested data. When (i) either signature of the double-signed data usage token has not been verified, or (ii) the claimed use of the data does not match the authorized use of the data, or (iii) one or more requested data types do not include the data type of the requested data, the computing device may block the application from accessing the data.

[0150] An application's claimed use of data can come from a predefined set of data uses. For example, a predefined set of data uses could include a first use, a second use, and a third use. The publisher system can select one of the first, second, or third uses as the claimed use. In some examples, the publisher system can select multiple uses from a predefined set of data uses. One of the data uses can be any data use option; for example, this would instruct the publisher system to claim that the requested data can be used for any purpose.

[0151] The requested data type used by the application can be from a predefined set of data types. For example, the predefined set of data types may include a first data type, a second data type, and a third data type. The requested data type may include one or more data types from the predefined set of data types. In some examples, the requested data type may include all data types from the predefined set of data types.

[0152] In some implementations, the computing device may use application data access settings instead of double-signed data usage tokens to control application access to data. For example, when data access settings indicate that they will be used in place of an application's double-signed data usage token, the computing device may use the data access settings regardless of whether the request includes a token. For example, for a second application different from the first application, the computing device may receive a second request to access second data collected by the device. The computing device may determine that the device includes data access settings for the second application. In response to determining that the device includes data access settings for the second application, the computing device may determine to skip the analysis of any double-signed data usage tokens for the second application. The computing device may use the data access settings to control the second application's access to the second data, for example, as discussed above with reference to the first application.

[0153] In some examples, the computing device can determine that it does not possess a data usage token with dual signatures for the second application. In response to determining that the device does not possess a data usage token with dual signatures for the second application, the computing device can determine the default data access settings for the second application. The computing device can use the default data access settings to control the second application's access to the second data.

[0154] In situations where the systems discussed herein collect or may utilize personal information about users, users may be provided with the opportunity to control whether a program or feature collects personal information (e.g., information about the user's social networks, social actions or activities, occupation, user preferences, or the user's current location), or to control whether and / or how content that may be more relevant to the user is received from the content server. Additionally, some data may be anonymized in one or more ways before storage or use to remove personally identifiable information. For example, a user's identity may be anonymized so that the user's personally identifiable information cannot be determined, or the user's geographic location may be generalized (such as city, zip code, or state level) where location information is obtained, making it impossible to determine the user's specific location. Therefore, users can control how content servers collect and use information about them.

[0155] Many implementations have been described. However, it will be understood that various modifications can be made without departing from the spirit and scope of this disclosure. For example, various forms of processes shown above can be used, in which steps are reordered, added, or removed.

[0156] Embodiments of the subject matter and functional operation described in this specification can be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware (including the structures disclosed in this specification and their structural equivalents), or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier, for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions can be encoded on artificially generated propagated signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination thereof.

[0157] The term "data processing apparatus" refers to data processing hardware and includes all kinds of devices, apparatuses, and machines for processing data, such as programmable processors, computers, or multiple processors or computers. The apparatus may also be or include special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, the apparatus may optionally include code that generates an execution environment for computer programs, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, or combinations thereof.

[0158] Computer programs (also referred to or described as programs, software, software applications, modules, software modules, scripts, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. A computer program may (but does not need to) correspond to a file in a file system. A program may be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), as a single file dedicated to the program in question, or as a collection of coordinating files (e.g., files storing portions of one or more modules, subroutines, or code). Computer programs can be deployed to execute on one or more computers located at a single site or distributed across multiple sites and interconnected via a communications network.

[0159] The processes and logic flows described in this specification can be executed by one or more programmable computers that execute one or more computer programs, thereby performing functions by manipulating input data and generating outputs. The processes and logic flows can also be executed by dedicated logic circuitry, and the devices can be implemented as dedicated logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).

[0160] A computer suitable for executing computer programs includes, for example, a general-purpose or special-purpose microprocessor or both, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory or random access memory or both. The basic components of a computer are the central processing unit for executing or carrying out instructions and one or more memory devices for storing instructions and data. Typically, a computer also includes one or more mass storage devices (e.g., disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled to receive data from or transfer data to one or more mass storage devices or both. However, a computer does not necessarily need to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, smartphone, personal digital assistant (PDA), mobile audio or video player, game console, global positioning system (GPS) receiver, or portable storage device such as a universal serial bus (USB) flash drive.

[0161] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as: semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM optical disks. Processors and memory may be supplemented or incorporated into dedicated logic circuitry.

[0162] To provide interaction with the user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device (e.g., LCD (liquid crystal display), OLED (organic light-emitting diode) or other monitor) for displaying information to the user, and a keyboard and pointing device (e.g., mouse or trackball) by which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including acoustic, voice, or tactile input. Furthermore, the computer can interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a webpage to a web browser on the user's device in response to a request received from a web browser.

[0163] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes back-end components (e.g., as a data server), or middleware components (e.g., an application server), or front-end components (e.g., a client computer with a graphical user interface or a web browser), or any combination of one or more such back-end, middleware, or front-end components, which a user can interact with through an implementation of the subject matter described in this specification. The components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks (LANs) and wide area networks (WANs), such as the Internet.

[0164] A computing system may include clients and servers. Clients and servers are typically geographically separated and usually interact via a communication network. The relationship between a client and a server is generated by computer programs running on respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., Hypertext Markup Language (HTML) pages) to a user device, for example, to display data to a user interacting with the user device acting as a client and to receive user input from that user. Data generated at the user device (e.g., the result of user interaction) may be received from the user device at the server.

[0165] While this specification contains many specific implementation details, these details should not be construed as limiting the scope of the claims, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or any suitable sub-combination. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed in this way, in some cases, one or more features from the claimed combination may be removed from that combination, and the claimed combination may involve sub-combinations or variations thereof.

[0166] Similarly, although operations are depicted in a specific order in the diagrams, this should not be construed as requiring such operations to be performed in the specific order shown or sequentially, or to perform all the described operations to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged in multiple software products.

[0167] In each instance where an HTML file is mentioned, it can be replaced with other file types or formats. For example, an HTML file can be replaced with XML, JSON, plain text, or other file types. Furthermore, when a table or hash table is mentioned, other data structures (such as spreadsheets, relational databases, or structured files) can be used.

[0168] Specific embodiments of the invention have been described. Other embodiments are within the scope of the appended claims. For example, steps listed in the claims, described in the specification, or depicted in the drawings may be performed in a different order and still yield the desired results. In some cases, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method comprising: receiving, by a device, a request for an application to access data collected by the device; determining, by the device and based on contents of a twice-signed data usage token that has been digitally signed by both (i) a system having data of the application and (ii) a data access authorization system, an identifier of the application and a declared usage of the data by the application based on the twice-signed data usage token of the application; and controlling, by the device, access of the data by the application using the identifier of the application, the declared usage of the data, and an authorized usage of the data, including: enabling, by the device, access of the data by the application when (i) both signatures of the twice-signed data usage token have been verified and (ii) the declared usage of the data matches the authorized usage of the data; and preventing the application from accessing the data when (i) either signature of the twice-signed data usage token has not been verified or (ii) the declared usage of the data does not match the authorized usage of the data. Controlling access of the data by the application by the device includes controlling access of the data by the application by an operating system of the device. Receiving the request includes receiving a request that identifies the twice-signed data usage token.

2. The method of claim 1, wherein, 4. The method of claim 1, comprising:

3. The method of claim 1, wherein, determining the identifier of the application in response to receiving the request; and retrieving, by the device, the twice-signed data usage token from a token database using the identifier of the application.

5. The method of claim 1, wherein: Controlling access of the data by the application includes controlling access of the data by the application by the device using the identifier of the application, the declared usage of the data, one or more requested data types, and a data type of the requested data, including: enabling, by the device, access of the data by the application when (i) both signatures of the twice-signed data usage token have been verified, (ii) the declared usage of the data matches the authorized usage of the data, and (iii) neither signature has expired; and preventing the application from accessing the data when (i) either signature of the twice-signed data usage token has not been verified or (ii) the declared usage of the data does not match the authorized usage of the data or (iii) either signature has expired.

6. The method of claim 1, comprising: determining one or more requested data types identified by the twice-signed data usage token, wherein: Controlling access of the data by the application includes controlling access of the data by the application by the device using the identifier of the application, the declared usage of the data, the one or more requested data types, and a data type of the requested data, including: ​ ​ ​ enabling, by the device, access to the data for the application when (i) both signatures of the twice-signed data usage token have been verified, (ii) the declared usage of the data matches the authorized usage of the data, and (iii) the one or more requested data types include a data type of the requested data; and preventing, by the device, the application from accessing the data when (i) either signature of the twice-signed data usage token has not been verified, or (ii) the declared usage of the data does not match the authorized usage of the data, or (iii) the one or more requested data types do not include a data type of the requested data.

7. The method of claim 6, wherein: the declared usage of the data by the application is from a predetermined set of declared data usages; and the one or more requested data types are from a predetermined set of data types.

8. The method of claim 1, wherein, the twice-signed data usage token includes one or more of: a link to a privacy policy of a publisher of the application, an identifier of the publisher, a public key of the publisher, or time data indicating when the twice-signed data usage token expires.

9. The method of claim 8, wherein, the time data includes: (a) a signature date indicating when the publisher signed the twice-signed data usage token, after which the twice-signed data usage token will expire at the end of a predetermined time period, or (b) an expiration date indicating when the twice-signed data usage token expires.

10. The method of claim 8, wherein, the public key of the publisher indicates the declared usage of the data by the application, a system having data of the application, or both.

11. The method of claim 1, wherein, a first signature of the system having data of the application verifies content of a first portion of the twice-signed data usage token, and a second signature of the data access authorization system verifies content of the entire twice-signed data usage token.

12. The method of claim 11, wherein, the first signature of the system having data of the application verifies the identifier of the application and the declared usage of the data by the application.

13. The method of claim 1, comprising: receiving, by the device, a second request for access to second data collected by the device for a second application, the second application being a different application than the application; determining, by the device, that the device includes data access settings for the second application; responsive to determining that the device includes data access settings for the second application, determining, by the device, to skip analysis of any twice-signed data usage token for the second application; and controlling, by the device, access to the second data for the second application using the data access settings.

14. The method of claim 1, comprising: receiving, by the device, a second request for access to second data collected by the device for a second application, the second application being a different application than the application; determining, by the device, that the device does not have a twice-signed data usage token for the second application; in response to determining that the device does not have a twice-signed data usage token for the second application, determining, by the device, a default data access setting for the second application; and controlling, by the device, access to the second data by the second application using the default data access setting.

15. The method of claim 1, comprising: receiving, by the device, a first request for a second application, the first request: (a) for access to second data collected by the device, (b) identifying a first twice-signed data usage token for the second application using a first declared use of the second data by the second application, the second application being a different application than the application; determining, by the device, an authorized use of the second data; determining, by the device, that the first declared use of the second data by the second application does not match the authorized use of the second data; in response to determining that the first declared use of the second data by the second application does not match the authorized use of the second data, preventing the second application from accessing the second data; receiving, by the device, a second request for the second application, the second request: (a) for access to second data collected by the device, (b) identifying a second twice-signed data usage token for the second application using a second declared use of the second data by the second application; determining, by the device, that the second declared use of the second data by the second application matches the authorized use of the second data; in response to determining that the second declared use of the second data by the second application matches the authorized use of the second data, enabling, by the device, access to the second data for the second application.

16. The method of claim 15, wherein: the first declared use of the second data comprises using the second data for a particular purpose; and the second declared use of the second data comprises using the second data for a purpose different than the particular purpose.

17. The method of claim 1, comprising: when access to the data is enabled, by the device, for the application, creating, by the device, an entry in an access database, the entry identifying the application and data collected by the device that is accessed by the application; receiving, by the device, user input indicating that a user interface is requested to be presented, the user input identifying data collected by the device that is accessed by the application; and providing, by the device and using the access database, instructions to cause presentation of the user interface, the instructions identifying data collected by the device that is accessed by the application.

18. The method of claim 17, comprising: when the user interface is presented, receiving, by the device, second user input indicating a request for a customized data access setting for the application; and updating, by the device, the data access setting for the application using the request for a customized data access setting for the application.

19. The method of claim 18, comprising: receiving, by the device, a second request by the application to access data collected by the device; determining, by the device, that the device includes data access settings for the application; in response to determining that the device includes data access settings for the application, determining, by the device, to skip analysis of a twice-signed data usage token of the application; and controlling, by the device, access to the data by the application using the data access settings.

20. A system comprising: one or more computers; and one or more storage devices having stored thereon instructions that, when executed by the one or more computers, cause the one or more computers to perform operations comprising: receiving a request by an application to access data collected by the device; determining, based on contents of a twice-signed data usage token that has been digitally signed by both (i) a system having the data of the application and (ii) a data access authorization system, based on the twice-signed data usage token of the application, an identifier of the application and a declared use of the data by the application; and controlling access to the data by the application using the identifier of the application, the declared use of the data, and an authorized use of the data, including: enabling access to the data for the application when (i) both signatures of the twice-signed data usage token have been verified, and (ii) the declared use of the data matches the authorized use of the data; and preventing the application from accessing the data when (i) either signature of the twice-signed data usage token has not been verified, or (ii) the declared use of the data does not match the authorized use of the data.

21. One or more non-transitory computer-readable media storing instructions that, when executed by one or more data processing apparatuses, cause the one or more data processing apparatuses to perform operations comprising: receiving a request by an application to access data collected by the device; determining, based on contents of a twice-signed data usage token that has been digitally signed by both (i) a system having the data of the application and (ii) a data access authorization system, based on the twice-signed data usage token of the application, an identifier of the application and a declared use of the data by the application; and controlling access to the data by the application using the identifier of the application, the declared use of the data, and an authorized use of the data, including: enabling access to the data for the application when (i) both signatures of the twice-signed data usage token have been verified, and (ii) the declared use of the data matches the authorized use of the data; and preventing the application from accessing the data when (i) either signature of the twice-signed data usage token has not been verified, or (ii) the declared use of the data does not match the authorized use of the data.

Images