Processing requests to control information stored on multiple servers

Abstract

A method, system, and apparatus, including a computer program encoded on a computer storage medium, for sending / processing requests to control information stored on multiple content platforms / servers. In one aspect, a client device may send a request to a device trust server to verify the trustworthiness of the device. The client device may receive data from the device trust server indicating that the client device is trustworthy, and in response, the client device may send a request to an intermediary server to control user data stored on the multiple servers. The client device may receive responses from each of the multiple servers via the intermediary server. Based on the responses, the client device may determine that at least a subset of the multiple servers that contained the user data performed the action specified in the request to control the user data.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is an international application and claims the benefit of Israel Application No. 276868, filed August 23, 2020. The disclosures of the above applications are incorporated herein by reference in their entireties.

[0002] This specification relates generally to data processing, and the secure and efficient transmission and processing of requests to control information stored on multiple content platforms / servers. [Background technology]

[0003] A user of a client device may request control over the user's information stored at a particular content platform / server. Such requests to control user data may include, for example, requests to erase all or part of the user's information, to modify the user data, to access the user data, or to prevent the transmission of the user data to any other entity. Because the user's information may be stored at multiple different servers, the client device must generate and send a separate request to each such content platform / server. Summary of the Invention [Means for solving the problem]

[0004] In general, one inventive aspect of the subject matter described herein may be embodied in a method including the operations of: sending, by the client device, a request to a device trust server to verify the trustworthiness of the client device; receiving, by the client device, data from the device trust server indicating that the client device is trustworthy; sending, in response to receiving the data indicating that the client device is trustworthy, a request to control user data stored at a plurality of servers by the client device to an intermediary server, the intermediary server being a server that validates the request to control the user data before sending the request to control the user data to each of the plurality of servers, the request to control the user data specifying an action to be performed by the server with respect to the user data; receiving, by the client device, a response from each of the plurality of servers via the intermediary server; and determining, by the client device, based on the response, that at least a subset of the plurality of servers that contained the user data have performed the action specified in the request to control the user data. Other embodiments of this aspect include corresponding methods, apparatus, and computer programs encoded on a computer storage device and configured to perform the actions of the method. These and other embodiments may each optionally include one or more of the following features.

[0005] In some implementations, the method may further include generating, by the client device, a digital token including (1) a device identifier of the client device, (2) a first data parameter that is a timestamp specifying the time the digital token was created, (3) instructions specifying a type of action with respect to user data stored at the multiple servers, and (4) data identifying the multiple servers, and encrypting, by the client device, the digital token using a symmetric encryption algorithm to obtain an encrypted digital token.

[0006] In some implementations, encrypting, by the client device, the digital token using a symmetric encryption algorithm to obtain an encrypted digital token may include generating, by the client device, an encryption key based on data parameters including a current date, a first data string, and a device identifier, using a cryptographic pseudorandom function, and encrypting, by the client device, the digital token using the encryption key to obtain the encrypted digital token.

[0007] In some implementations, generating an encryption key based on data parameters including a current date, a first data string, and a device identifier using a cryptographic pseudorandom function may include generating the encryption key by (1) calculating a first message authentication code (MAC) using the current date and the first data string, and (2) generating a second MAC using the device identifier and the first MAC.

[0008] In some implementations, the request to verify the authenticity of the client device may include a first set of data, which may include (1) device authenticity data from which the authenticity of the client device is determined, and (2) a third MAC generated using the encrypted digital token and the first data parameters.

[0009] In some implementations, the request to control the user data may include a second set of data including (1) data indicating that the client device is trustworthy, (2) an encrypted digital token, (3) the first data parameter, (4) data identifying the plurality of servers, and (5) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter.

[0010] In some implementations, the second data parameter may include a current date, and the third data parameter includes a second string of data.

[0011] In some implementations, receiving, by the client device, from the device trust server, data indicating that the client device is trustworthy may include receiving, by the client device, from the device trust server, a digital signature by the device trust server of the third MAC.

[0012] In some implementations, with respect to user data, the action to be taken by the server may include one of: erasing the user data stored at the server, requesting that the user data stored at the server not be transmitted or given to any other entity, enabling access to the user data stored at the server to one or more entities, requesting disclosure of collected user data, or requesting export of collected user data.

[0013] Particular embodiments of the subject matter described herein can be implemented to realize one or more of the following advantages.

[0014] The techniques described herein provide resource-efficient techniques for processing multiple requests to content platforms / servers that store information about users of client devices. Generally, generating and sending multiple requests to various content platforms / servers can consume a large amount of the client device's computational resources (e.g., battery, processor cycles, bandwidth, etc.). The techniques described herein can significantly reduce the impact on the client device's computational resources in generating and sending such requests by using an intermediary server that receives a single request (as opposed to multiple requests) from the client device and generates and routes multiple requests to multiple content platforms / servers that store user data.

[0015] Moreover, the techniques described herein provide security mechanisms to prevent or at least reduce the likelihood of an attack against a relay server being propagated across a network to various content platforms / servers communicating with the relay server. For example, a Denial of Service (DoS) attack may be launched on a relay server, which may be propagated to various content platforms / servers communicating with the relay server. As a result, a DoS attack on the relay server may disrupt the operation of the relay server as well as the operation of various content platforms / servers communicating with the relay server. To prevent or reduce the spread / propagation of such attacks, the techniques described herein implement a device trust server that verifies the trustworthiness of a requesting client device and provides this trust indication to the relay server, which verifies the trustworthiness of the device before sending any requests / messages to the various content platforms / servers. As a result, when a device is deemed untrustworthy or when the reliability of the device cannot be verified, the relay server will not submit requests from such a device that may be a malicious or possibly compromised device.

[0016] Furthermore, the techniques described herein shield any user / device information provided to the relay server (e.g., identification information that can be used to fulfill requests to control user data stored at various servers), thus avoiding any intentional or unintentional disclosure / dissemination of such information from / by the relay server. In some implementations, the techniques described herein encrypt the device identifier (and / or other device / user identification information) in an encrypted token and apply other security measures to this token before sending it to the relay server. The techniques used to generate this token (described below) prevent the relay server from being able to decrypt / decrypt this token, thereby preventing the relay server from being able to access the device and / or user identification information stored in the token. These protection techniques do not interfere with the operation of the relay server. For example, even though the data in this token is inaccessible, the relay server can still send requests to control user data to various content platforms / servers. As a result, the techniques described herein enable the implementation / satisfaction of device requests to control user data at various servers while maintaining user / device privacy during the process of requesting control over the user data.

[0017] The details of one or more embodiments of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. [Brief description of the drawings]

[0018] [Figure 1] 1 is a block diagram of an example environment in which digital content is distributed and provided for display on a client device. [Diagram 2] FIG. 1 is a block diagram of an example environment in which client device requests to exercise control over user information stored on a content platform are received and processed. [Diagram 3] 4 is a flow diagram of an example process for generating and delivering variants of an audio digital component based on a template generated for the audio digital component. [Figure 4] FIG. 1 is a block diagram of an example computer system that can be used to perform the operations described. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] This specification relates generally to secure and efficient transmission and processing of requests to control user information, also referred to as user data, stored across multiple content platforms / servers.

[0020] As summarized below and described in more detail throughout this document, client devices operate in conjunction with relay servers and device reliability servers to generate and send requests to control user information stored in various servers.

[0021] In some implementations, a client device sends a request to a device trust server to verify the trustworthiness of the client device, the request may include device trust data including a set of signals obtained from the device's environment from which the trustworthiness of the client device can be determined.

[0022] The device trust server uses the device trust data included in the request to verify the trustworthiness of the device. Based on this verification, the device trust server sends data to the client device indicating whether the client device is trusted.

[0023] Upon receiving data from the device trust server indicating whether the client device is trustworthy, the client device sends a request to the relay server to control the user information stored in various servers. The request to control the user information specifies the action to be performed by the server on the user information (e.g., erase the user information, modify the access rights to the user information, prevent the dissemination of the user information) and specifies the server on which the requested action should be performed. The request also includes data indicating whether the client device is trustworthy.

[0024] Upon receiving a request from a client device, the relay server determines that the device is trusted based on data received from the device trust server and validates the request. Once validated, the relay server sends requests to control the user information to the various servers specified in the request from the client device. Upon receiving a request from the relay server, the server validates the request and performs the appropriate action specified in the request to exercise control over the user information.

[0025] The server then sends responses to the relay server specifying whether the server fulfilled the request. The relay server sends these responses to the client device providing confirmation as to whether the request to control the user information was fulfilled.

[0026] These and additional features are further described in more detail below with reference to FIGS.

[0027] In addition to the descriptions throughout this specification, a user may be given controls that allow the user to choose both whether and when the systems, programs, or features described herein may enable the collection of user information (e.g., information about the user's social network, social actions or activities, occupation, the user's preferences, or the user's current location) and whether the user is sent content or communications from the server. Furthermore, certain data may be treated in one or more ways such that personally identifiable information is removed before it is stored or used. For example, the user's identity may be treated such that personally identifiable information cannot be determined about the user, or the user's geographic location may be generalized (e.g., to the city, zip code, or state level) such that location information is obtained such that the user's specific location cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, and what information is provided to the user.

[0028] FIG. 1 is a block diagram of an example environment 100 in which digital content is distributed and presented for viewing on client devices.

[0029] The exemplary environment 100 includes a network 104. The network 104 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof. The network 104 may also include any type of wired and / or wireless network, satellite network, cable network, Wi-Fi network, mobile communication network (e.g., 3G, 4G, etc.), or any combination thereof. The network 104 may use communication protocols including packet-based and / or datagram-based protocols, such as Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or other types of protocols. The network 104 may further include several devices that facilitate network communication and / or form the hardware infrastructure for the network, such as switches, routers, gateways, access points, firewalls, base stations, repeaters, or combinations thereof.

[0030] The network 104 connects the client devices 102, the content platforms 106, the device trust servers 110, and the relay servers 108. The example environment 100 may include many different content platforms 106, relay servers 108, client devices 102, and device trust servers 110.

[0031] A content platform 106 is a computing platform (e.g., a network server or another data processing device as described with respect to FIG. 4) that enables the distribution of content. Exemplary content platforms 106 include search engines, social media platforms, novelty platforms, data aggregator platforms, or other content sharing platforms. Each content platform 106 may be operated by a content platform service provider.

[0032] The content platform 106 may publish and make available its own content. For example, the content platform 106 may be a news platform that publishes its own news articles. The content platform 106 may also present content provided by one or more content providers 108 that are not part of the content platform 106. In the above example, the news platform may also present third-party content provided by one or more content providers 108. As another example, the content platform 106 may be a data aggregator platform that does not publish its own content but aggregates and presents third-party content provided by different content providers 108.

[0033] In some implementations, the content platform 106 may store certain information about client devices (e.g., device preference information, content consumption information, etc.). Such user information may be used by the content platform, for example, to tailor content provided to the client device 102 or to enable immediate access to certain content frequently accessed by the client device 102. In some implementations, the content platform 106 may not store such device information on the platform, but the content platform 106 may nevertheless provide such information for storage on a particular server (separate from the content platform). The content platform 106 (also referred to herein as the content platform / server 106 or simply a server) thus refers to the content platform that stores such device information or the server (separate from the content platform) that stores such device information.

[0034] The device trust server 110 is a server (or another data processing device, as described with respect to FIG. 4) that determines whether the client device 102 is trustworthy. In some implementations, the client device 102 provides a set of signals (e.g., the type of device used, the device's operating system, etc.), referred to herein as device trust data, to the device trust server 110. Based on the received device trust data, the device trust server 110 determines whether the client device is trustworthy. In some implementations (and as further described below with reference to FIGS. 2 and 3), the device trust server 110 provides an indication to the client device 102 as to whether the client device 102 is trustworthy.

[0035] The relay server 108 is a server (or another suitable data processing device as described with respect to FIG. 4) that stores user information about a user associated with the client device 102 and serves as an intermediary between the client device and the various content platforms / servers 106. The relay server 108 validates requests received from the client device 102 to control user information before transmitting such requests to each of the multiple servers (as described with reference to FIGS. 2 and 3). In some implementations (and as further described below with reference to FIGS. 2 and 3), the relay server receives a single request from the client device 102 to exercise user information stored at the multiple content platforms / servers 106, validates the request, and, if enabled, transmits the request to the multiple content platforms / servers 106.

[0036] Additional structural and operational aspects of these components of the exemplary environment 100 are described with reference to FIG.

[0037] FIG. 2 is a block diagram of an example environment 200 for transmitting and processing requests to control user information from a client device 102 to multiple content platforms 106.

[0038] 2, the client device 102 includes an operating system 204, a device trust client 210, and an application A 202. The operating system 204 is generally responsible for managing the hardware and software resources of the client device 102, such as, for example, application A 202. In some implementations, the operating system 204 includes a token generator 206 and a MAC generator 208, each of which is described below.

[0039] The token generator 206 generates a digital token using data and instructions for controlling user information stored on multiple content platforms / servers 106. In some implementations, the token generator 206 digitally signs the generated digital token using, for example, the private key of the client device 102.

[0040] In some implementations, the digitally signed token generated by the token generator 206 is an attestation token. As used herein, an attestation is a digital token that includes a set of data, which may include one or more of the following data items: (1) a unique identifier of the client device 102; (2) a timestamp indicating the creation time of the token (also referred to as a request timestamp); (3) a payload that includes data indicating a request to exercise control over user information; and (4) optionally, a device trust token previously generated by the device trust server 110 (i.e., the device trust token may, but need not, be included in the attestation token). The attestation token also includes a digital signature generated by the token generator 206 by signing the set of data included in the attestation token with the private key of the client device 102.

[0041] The following paragraphs describe each data item in the set of data contained in the attestation token, and the digital signature of this set of data.

[0042] The unique identifier of the client device 102 included in the authentication token may be or include the public key of the client device 102. For example, the client device 102 may generate and / or maintain one or more encryption key pairs including a device private key and a device public key. The device public key corresponds to and is mathematically linked to the device private key. Data that is digitally signed with a private key can only be verified with the corresponding public key. Similarly, data that is encrypted with a public key can only be decrypted with the corresponding private key. Alternatively, another suitable device identifier may be used rather than the device public key, such as, for example, the device's MAC address.

[0043] A timestamp included in the attestation token specifies / indicates the time the attestation token was created. In some implementations, the timestamp specifies the time (and in some cases the date) the attestation token was created. In some implementations, the timestamp can record the time with high resolution (e.g., so that the creation time can be recorded in microseconds or even nanoseconds) or with low resolution (e.g., so that the recorded creation time is in hours or minutes).

[0044] The payload included in the attestation token may include data indicating a request to control user information stored on one or more servers. This data may specify (1) the type of action the user is requesting with respect to the data (e.g., erase the data, modify access to the data, prevent further transmission of the data), and (2) the scope of the request, i.e., whether the requested action is to be performed on a particular content platform / server 106 or on a content platform / server in communication with the relay server 108 (which receives the request). If the scope of the request specifies a requested action on a particular content platform / server 106, the payload may also include the domain addresses or other types of identifiers of those platforms / servers 106.

[0045] A device trust token may optionally be included in the attestation token, allowing an entity to determine whether the attestation token was sent by a trusted client device 102. The device trust token may be issued by a third party device integrity system (such as the device trust server 110) that evaluates a set of signals corresponding to a particular client device and assigns a level of trust (e.g., a numerical score within a score limit, a binary determination of trust) to the client device 102 based on the evaluation.

[0046] In some implementations, a device reliability token for a client device 102 may include (1) a determination indicating the level of reliability (or integrity) of the client device 102 at the time the device reliability token was generated, (2) a device reliability token creation time indicating the time the device reliability token was generated, and (3) a unique identifier for the client device 102 (which may be, for example, the client device's device public key or a derivative thereof). The device reliability token may also include a digital signature of the data in the device reliability token. This digital signature may be generated using the private key of the device reliability server 110.

[0047] For example, the device trust server 110 may sign data using its private key, which the server 110 maintains in confidence. An entity receiving the device trust token may use the public key of the device trust server 110 to verify the signature of the device trust token. Moreover, including the device public key (or a derivative thereof, e.g., a digital digest) for the client device 102 in both the device trust token and the attestation token binds the two tokens together. In other words, including the device public key (or another suitable device identifier) ​​of the client device 102 in the device trust token allows the recipient of the attestation token to determine that the device trust token was generated for that client device 102. This prevents, for example, other parties from including the device trust token for a trusted device in a forged request from an emulator or compromised client device.

[0048] The digital signature included with the attestation token may be a digital signature of the set of data (or some variation thereof), as described above. This digital signature is generated using the client device's 102 device private key, which may be maintained securely and privately by the client device's 102 operating system 204. In some implementations, the digital signature may be a digital signature of the payload, a device identifier (e.g., a device public key), a timestamp, and a device authenticity token. In some implementations, the operating system 204 generates the digital signature using the Elliptic Curve Digital Signature Algorithm (ECDSA), although other signature techniques, such as RSA, may be used.

[0049] In some circumstances, another type of digitally signed token may be generated by the token generator 206, which may also be used to secure the communication of the request to control user information and any corresponding data. For example, in such an implementation, the data may be digitally signed using the private key of a third-party integrity system (such as the device trust server 110). An entity that subsequently receives the digitally signed token can request the corresponding public key from the third-party integrity system and then use this key to verify the signature and the included data.

[0050] The MAC generator 208 generates message authentication codes (MACs) for different sets of data (as described further below and with further reference to FIG. 3). In some implementations, the MAC generator 208 uses a MAC algorithm (which is a type of cryptographic pseudorandom function) to generate a hash-based message authentication code (HMAC), also referred to as a keyed-hash message authentication code. In such implementations, the MAC generator 208 generates an HMAC (e.g., using an HMAC SHA256 algorithm) for different sets of data / parameters. In some implementations, rather than using an HMAC or another MAC algorithm, the MAC generator 208 uses another suitable cryptographic pseudorandom function (PRF) that potentially uses parameters used by the MAC generator 208 in generating various digital digests, as described throughout this specification. For ease of reference, the remainder of this specification will be described as generating a MAC or an HMAC, although it will be appreciated that the same functions / computations described throughout this specification may alternatively be performed using another suitable cryptographic PRF.

[0051] The MAC generator 208 uses the operating system's 204 private encryption key (stored in a secure location in the client device) to generate an HMAC for a particular set of data. The MAC / HMAC generated by the system of Figure 2 is described further below.

[0052] The client device 102 also includes a device reliability client 210. In some implementations, the device reliability client 210 is invoked by the operating system 204 and collects signals from the environment of the client device 102, either alone or in cooperation with the operating system 204. Examples of signals collected by the device reliability client 210 include, but are not limited to, the type of device, the model number of the device, whether the device is rooted and / or jailbroken, the operating system running on the device, when the device was last updated, and the like. Alternatively, only the operating system 204, and not the device reliability client 210, may obtain device reliability data. These signals, collectively referred to as device reliability data, may be used by the device reliability server 110 to determine the reliability of the client device 102 (described further below and with reference to FIG. 3).

[0053] In some implementations, the client device 102 (e.g., via application A 202) generates a request 212 to verify the trustworthiness of the client device 102. The request may include (1) device trust data obtained by the device trust client 210, the operating system 204, or both, from which the trustworthiness of the client device is determined, and (2) a digital digest consisting of an encrypted attestation token and a request timestamp, also referred to herein as a “third MAC.”

[0054] In some implementations, this digital digest, consisting of the encrypted attestation token and the request timestamp, is generated using a MAC generator 208 operating alone or in conjunction with the operating system 204, as described in the operations below.

[0055] The MAC generator 208 generates a secret key by first generating an HMAC using the current date and a data string (e.g., a phrase such as "encrypt"), and then generating another HMAC using an HMAC consisting of the current date and data string and a unique identifier for the client device 102 (e.g., the device's public key). This operation can be expressed using the following formulation: HMAC(DeviceID,HMAC(current_date,"encrypt")

[0056] Alternatively, the above calculation may be modified to swap out any of the parameters (DeviceID, current_date, "encrypt") of the calculation to generate the secret key. For example, the MAC generator 208 may generate a secret key by generating an HMAC using the DeviceID and a data string (e.g., a phrase such as "encrypt"), then generating another HMAC using an HMAC consisting of the DeviceID and the data string and the current_date. As another example, the MAC generator 208 may generate a secret key by generating an HMAC using the DeviceID and the current_date, then generating another HMAC using an HMAC consisting of the DeviceID and the current_date and a data string ("encrypt").

[0057] Alternatively, rather than the above calculation, the MAC generator 208 can generate the secret key by calculating a MAC as follows: MAC(Device||current_date||"encrypt") In this example calculation, || can be any reversible way from simple messages, e.g., protocol buffers, concise binary object representation (CBOR), to assemble a compound message.

[0058] As another alternative, any other cryptographically significant pseudorandom function (other than MAC / HMAC) using three parameters may be used to generate data item (5) in the set of data included in request 216.

[0059] By using the current date in generating the HMAC (and therefore the resulting private key), the private key is ephemeral - in other words, it can only be used to decrypt proof tokens as of the current date (as explained further below).

[0060] Second, the MAC generator 208 (or the operating system 204 in general) uses a symmetric probabilistic encryption algorithm to encrypt the attestation token with the generated private key.

[0061] Third, the MAC generator 208 generates an HMAC using the encrypted proof token and a timestamp of the creation of the proof token to obtain a digital digest (also called a third MAC), for example, consisting of the encrypted proof token and a request timestamp that specifies when the proof token was created. This operation can be expressed using the following formulation: HMAC(encrypted_attestation_token,request_timestamp)

[0062] As mentioned above, the digital digest of the encrypted proof token and the request timestamp is an HMAC of two parameters: the encrypted proof token and the request_timestamp. In some implementations, rather than generating this digital digest / third MAC, only the encrypted proof token may be included in the request 212. It will be assumed hereinbelow that the digital digest of the encrypted proof token and the request timestamp is included in the request 212. However, it will be appreciated that if the encrypted proof token is included in the request 212, the following disclosure is equally applicable.

[0063] By using an HMAC algorithm or another PRF algorithm (on the encrypted attestation token and the request timestamp), the device trust server 110 does not receive the encrypted attestation token, and the device trust server 110 cannot infer the attestation token from the HMAC (or other PRF) on the encrypted attestation token and the request timestamp. As a result, the device trust server 110 cannot learn the nature of the client device's 102 request to control user information (e.g., whether the device is requesting erasure / modification of all user information) or the scope of the request (e.g., whether the request should be fulfilled by a particular content platform / server 106 or by a larger number of such servers / platforms 106).

[0064] Returning to Figure 2, the client device 102 sends a request 212 to the device trust server 110. Upon receiving the request 212, the device trust server 110 uses the device trust data included in the request 212 to determine whether the device is trustworthy. If the device trust server 110 determines that the client device 102 is trustworthy, the device trust server 110 digitally signs a digital digest consisting of the encrypted attestation token and the request timestamp with its private key. On the other hand, if the device trust server 110 determines that the client device 102 is not trustworthy, the device trust server does not digitally sign a digital digest consisting of the encrypted attestation token and the request timestamp.

[0065] In some situations, rather than (or in addition to) indicating trustworthiness by digitally signing a digital digest consisting of the encrypted attestation token and the request timestamp, the device trust server 110 may indicate the trustworthiness of the device using a flag (e.g., a one-bit flag where 0 indicates not trusted and 1 indicates trusted) or other data (e.g., a data message where "TRUST" indicates the device is trusted and "DON'T TRUST" indicates the device is not trusted). It is assumed hereinafter that the device trust server 110 indicates the trustworthiness of the device by digitally signing a digital digest consisting of the encrypted attestation token and the request timestamp.

[0066] The device trust server 110 sends a response 214 to the client device 102. This response includes a digital signature over a digital digest consisting of the encrypted attestation token and the request timestamp (if the device trust server 110 determines that the client device 102 is trusted) or an error code / empty response (if the device trust server 110 determines that the client device 102 is not trusted or if the device trust server 110 determines that it is unable to verify the authenticity of the client device 102).

[0067] Upon receiving the response 214 from the device trust server 110, the client device 102 sends a request 216 to the relay server 108 requesting control over the user information stored in the multiple content platforms / servers 106. In some implementations, when the client device 102 (e.g., the operating system 204) sends the request 216 to the relay server 108, the request 216 includes a set of data. This set of data may include one or more of the following data items: (1) a digitally signed third MAC / digital digest of the encrypted attestation token (or other digital token) and the request timestamp, (2) the encrypted attestation token (or other digital token), (3) a timestamp indicating when the attestation token (or other digital token) was created, (4) the scope of the request, as specified in the payload of the attestation token (and described above), or (5) an HMAC (or another suitable PRF) over a unique identifier of the device (e.g., the device's public key) and another HMAC over the current date and a data string (e.g., a phrase such as "challenge"). The HMAC in data item (5) can be expressed using the following formulation: HMAC(DeviceId,HMAC(current_date,"challenge")

[0068] Alternatively, the above calculation may be modified to swap any of the parameters of this calculation for generating the HMAC in data item 5 (DeviceID, current_date, "challenge"). For example, MAC generator 208 may generate this HMAC by generating an HMAC using the DeviceID and a data string ("challenge"), and then generating another HMAC using an HMAC consisting of the DeviceID, the data string, and the current_date. As another example, MAC generator 208 may generate an HMAC by generating an HMAC using the DeviceID and current_date, and then generating another HMAC using an HMAC consisting of the DeviceID, the current_date, and a data string ("challenge").

[0069] Alternatively, rather than the above calculation, the MAC generator 208 can generate the secret key by calculating a MAC as follows: MAC(Device||current_date||"challenge") In this example calculation, || can be any reversible way from simple messages, e.g., protocol buffers, concise binary object representation (CBOR), to assemble a compound message.

[0070] As another alternative, any cryptographically significant pseudorandom function using three parameters may be used to generate data item (5) in the set of data included in request 216.

[0071] Upon receiving the request 216 and the set of data contained therein, the relay server 108 determines whether the client device 102 has been determined to be trustworthy by the device trust server 110. In some implementations, the relay server 108 uses the public key of the device trust server 110 to verify the digital signature created by the device trust server 110. If the digital signature is verified, the relay server 108 determines that the client device is trustworthy. On the other hand, if the digital signature is not verified, the relay server 108 determines that the client device 102 is not trustworthy. In some implementations, the relay server 108 further verifies the freshness of the request, as indicated by a request timestamp (e.g., a request received within a certain threshold time after the time indicated by the request timestamp is likely to be a new request). Furthermore, the relay server validates the request by recalculating a digital digest consisting of the encrypted attestation token and the request timestamp, and matching the digital digest with the digital digest received in the request. A mismatch indicates that the request is invalid (which may indicate that the client device is not trustworthy).

[0072] If the relay server 108 determines that the client device 102 is not trustworthy or the request is invalid, the relay server 108 does not send any further requests to any of the content platforms / servers 106 with which it communicates. Thus, to the extent that the client device 102 is a malicious or compromised device attempting to launch an attack (e.g., a DoS attack) against the content platform / server with which it communicates, the relay server 108's (and the device trust server 110's) trust determination prevents such an attack. In some implementations, in addition to determining not to send any requests to the content platform / server 106, the relay server 108 may send a message to the client device 102 indicating that the request 216 was not satisfied.

[0073] On the other hand, if the relay server 108 determines that the client device 102 is trusted, the relay server 108 sends the request 218 to the content platforms / servers 106 specified in the request scope included in the request 216. For example, if the request scope included in the request 216 specifies only a select number of domains that correspond to particular content platforms / servers 106, the relay server 108 sends the request 218 to each of those content platforms / servers 106. On the other hand, if the request scope included in the request 218 does not specify a select number of domains that correspond to particular content platforms / servers 106, the relay server 108 infers that the request is global and therefore sends the request 218 to the various content platforms / servers 106 that communicate with the relay server 108.

[0074] In some implementations, the request 218 may include a set of data that may include one or more of the following data items extracted from the request 216 (i.e., a request from the client device 102 to the relay server 108): (1) a digitally signed digital digest of the encrypted attestation token (or other digitally signed token) and a request timestamp, (2) the encrypted attestation token (or other digital token), (3) a timestamp indicating when the attestation token (or other digital token) was created, and (4) an HMAC over a unique identifier of the device (e.g., the device's public key) and another HMAC over the current date and phrase (e.g., "challenge"). The HMAC operation of data item (4) may be expressed using the following formulation: HMAC(DeviceID,HMAC(current_date,"challenge")

[0075] As described with respect to data item (5) in request 216, the above calculation may be calculated in an alternative manner and may be calculated using another cryptographically significant pseudorandom function other than HMAC.

[0076] Upon receiving the request 218, the content platform / server 106 can verify the device trust server's 110 digital signature over a digital digest consisting of the encrypted attestation token and the request timestamp (in the same manner as described above with respect to the relay server 108 verifying the signature).

[0077] If the digital signature does not verify, the content platform / server 106 does not process the request 218 further and determines that the relay server 108 and / or the client device 102 have malfunctioned or are untrusted or compromised. In some implementations, the content platform / server 106 further verifies the freshness of the request, as indicated by the request timestamp. In addition, the content platform / server validates the request by recalculating a digital digest consisting of the encrypted proof token and the request timestamp, and matching the digital digest with the digital digest received in the request, in the same manner as described above with respect to the relay server 108 verifying the signature. A mismatch indicates that the request is invalid.

[0078] On the other hand, if the digital signature and request are verified (e.g., based on the same verification and digital digest comparison described above), the content platform / server 106 determines that the client device 102 is trusted. In such a case, the content platform / server 106 determines whether the content platform / server 106 includes user information that corresponds to the client device 102's unique device identifier (e.g., the device's public key).

[0079] It should be noted that in an implementation in which the relay server 108 merely provides the content platform / server 106 with a digital digest consisting of the encrypted attestation token and the request timestamp, the content platform / server 106 does not have access to the device's unique identifier (e.g., the device's public key) contained in the attestation token (or another digital token). In such an implementation, the content platform / server 106 includes a storage device that stores a lookup table (or another suitable data structure) that maintains a correlation between the device's unique identifier (DeviceID) and an HMAC value (or other digital digest value generated using another PRF), and the HMAC value is calculated (i.e., with the same parameters and based on the same calculations as described above with respect to request 218) over the device's unique identifier and another HMAC over the current date and a data string phrase (e.g., a phrase such as "challenge"). In other words, the resulting HMAC calculation is similar to the HMAC calculation performed to obtain data item (4) in request 218 above. HMAC(DeviceID,HMAC(current_date,"challenge")

[0080] As noted above, the above calculations may be calculated in alternative ways and may be calculated using another cryptographically significant pseudorandom function other than HMAC.

[0081] Since the "current_date" is used as a parameter in calculating the HMAC value, the content platform / server 106 updates the calculated HMAC value daily in the lookup table 224 using the current date of that day. Therefore, if the relay server 108 sends a calculated HMAC value that is calculated using a date other than the current date, the HMAC will not be found in the lookup table and the content platform / server 106 will not perform any further processing on the received request 218.

[0082] During operation, the content platform / server 106 compares the HMAC value received in the set of data included in the request 218 with the HMAC values ​​stored in the lookup table. If an exact match is not found, the content platform / server 106 determines that it cannot implement the request 218 to control the user information. This scenario can occur, for example, if the content platform / server 106 does not contain user information for a particular device identifier, if the relay server 108 sends an incorrect or stale HMAC with a date other than the current date (e.g., indicating that the relay server 108 has malfunctioned or been compromised by a malicious entity), or if the client device 102 sends a stale or incorrect HMAC (e.g., indicating that the client device 102 has malfunctioned or been compromised by a malicious entity).

[0083] On the other hand, if an exact match is found based on the comparison between the HMAC value received in the set of data included in the request 218 and the HMAC value stored in the lookup table 224, the content platform / server 106 retrieves the corresponding device identifier from the DeviceID field of the lookup table 224. Using the retrieved device identifier, the content platform / server 106 generates a private key in the same manner as the client device generated the private key prior to issuing the request 212 (as described above). Specifically, the content platform / server 106 generates a private key using the device identifier and an HMAC consisting of the current date and the same data string (e.g., the phrase "encrypt") used to generate the private key at the client device. The generation of the private key by the content platform / server 106 can be represented using the following operations: HMAC(DeviceID,HMAC(current_date,"encrypt")

[0084] As noted above, the above calculations may be calculated in alternative ways and may be calculated using another cryptographically significant pseudorandom function other than HMAC.

[0085] In this way, the client device 102 and the content platform / server 106 do not need to exchange the secret key used in encrypting / decrypting the proof token. That is, as long as each uses the same parameters (e.g., the current date, the same data string, and DeviceID) and the same calculation / formula / function, each can calculate the same secret key. Moreover, this secret key is short-lived in that the secret key is only valid for the current date. This short-lived secret key is also for only one purpose. A single-purpose short-lived secret key is unlikely to be used as an identifier corresponding to that of the client device and / or any data corresponding to the device. In other words, the content platform / server 106 cannot decrypt the encrypted proof token at the current date if the secret key was not generated at the current date. In this way, the content platform / server 106 can ensure that the request 218 (and the encrypted proof token contained therein) is new (current) and not subject to a replay attack, thereby providing the content platform / server 106 with a stale (but valid) encrypted proof token.

[0086] Using this generated private key, the content platform / server 106 decrypts the encrypted authentication token received in the request 218 from the relay server 108. As a result, a decrypted plaintext authentication token is obtained.

[0087] The content platform / server 106 can further validate the attestation token by verifying the digital signature contained within the attestation token. To verify the digital signature contained within the attestation token, the content platform / server 106 uses the device's public key to validate the digital signature protecting the contents of the attestation token (e.g., device identifier, request timestamp, request scope, and device authenticity token (when available)) whose corresponding data items are included within the attestation token.

[0088] If the digital signature is invalid, the content platform / provider 106 determines that the attestation token is not valid (which may further indicate that the relay server 108 and / or the client device 102 have malfunctioned or been compromised). In this scenario, the content platform / server 106 ignores the request 218 and does not process it further. In some implementations, the content platform / server 106 sends a response to the relay server 108 stating that the request 218 was not fulfilled.

[0089] On the other hand, if the digital signature is valid, the content platform / provider 106 determines that the attestation token is valid. In this scenario, the content platform / server 106 may perform further validation to verify that the request to control the information should be fulfilled by the content platform / server 106. To perform this validation, the content platform / server 106 obtains a value for the scope of the request contained in the attestation token (or other digital token). If the scope of the request identifies a particular content platform / server 106, then this content platform / server 106 determines that it must fulfill the request to control the information as specified in the attestation token (or other digital token). Similarly, if the scope of the request states that the request is global (i.e., must be fulfilled by the content platform / server 106 in communication with the relay server 108), then the particular content platform / server 106 determines that it must fulfill the request to control the information as specified in the attestation token (or other digital token). On the other hand, if the request does not identify a particular content platform / server 106 and is not global, the content platform 106 determines that it does not need to perform the requested action to control the user information corresponding to the client device 102.

[0090] If the content platform / server 106 determines that a request to control information must be performed, the content platform / server 106 obtains the type of action to be performed, which is specified in the payload of the proof token, and performs the appropriate action on the user information stored in the content platform 106 corresponding to the client device 102.

[0091] For example, if the request specifies that all or a portion of the user information be erased, the content platform / server 106 erases all or a portion of the user information. As another example, if the request specifies that access to the user information be modified for the client device 102, the content platform / server 106 adjusts the access settings for the user information to limit access only to the entities specified in the request of the client device 102. As another example, if the request specifies that transmission of the user information to any entity other than the user of the client device 102 be prevented, the content platform / server 106 adjusts the access settings for the user information and includes specific control instructions with the user information that prevent the content platform / server 106 from transmitting the user information to any entity other than the user.

[0092] After the content platform / server 106 performs the specified action (or after the content platform / server 106 determines that the request does not need to be fulfilled), it provides a response 220 to the relay server 108 stating whether the request has been fulfilled.

[0093] Upon receiving the response 220, the relay server 108 forwards the response 220 to the client device 102 as part of a response 222. In some implementations, the relay server 108 aggregates the responses 220 from the various content platforms / servers 106 and provides the aggregated response 222 to the client device 102. In some implementations, the relay server 108 sends each of the responses 220 from the various content platforms / servers 106 as a separate response 222 to the client device 102 on an ad-hoc basis, i.e., as these responses are received.

[0094] Thus, in view of the above description, the client device 102 does not need to send separate requests to multiple content platforms / servers 106 to control user information. Instead, the client device 102 may send a single request 216 to the relay server 108, which transmits the request to the various content platforms / servers 106. In this manner, computational resources (e.g., battery, network bandwidth) that would otherwise be consumed by the client device 102 when generating and transmitting multiple such requests (which may be hundreds of thousands or millions) are saved. Also, by verifying the authenticity of the device and validating the requests received at the relay server 108, the techniques described above prevent or at least reduce the likelihood of an attack (e.g., a DoS attack) against the relay server being propagated to the various content platforms / servers 106. Also, as further described above, all communications to the relay server 108, the device reliability server 110, and the content platforms / servers 106 shield the data contained therein, which thus preserves the privacy of the device information contained therein.

[0095] 3 is a flow diagram of an exemplary process 300 for transmitting and processing requests for controlling user information from a client device 102 to multiple servers. The operations of the process 300 are described below as being performed by components of the systems described and illustrated in FIGS. 1 and 2. The operations of the process 300 are described below for illustrative purposes only. The operations of the process 300 may be performed by any suitable device or system, for example, any suitable data processing apparatus. The operations of the process 300 may be implemented as instructions stored on a computer-readable medium, which may be non-transitory. Execution of the instructions causes one or more data processing apparatuses to perform the operations of the process 300.

[0096] The client device 102 sends (at 305) a request to the device trust server 110 to verify the authenticity of the client device 102. In some implementations (and as described with respect to FIG. 2), the request to verify the authenticity of the client device includes a first set of data including (1) device trust data from which the authenticity of the client device is determined, and (2) a third MAC generated using the encrypted digital token and a first data parameter, i.e., HMAC(encrypted_digital_token, request_timestamp), where the parameter may be a timestamp indicating the time the digital token was created (described in the next paragraph).

[0097] In some implementations, the client device 102 generates an encrypted digital token (as described above with reference to FIG. 2 and summarized below) using the following operations: First, the client device 102 generates a digital token. As described above with reference to FIG. 2, this digital token may be an attestation token that includes (1) a device identifier of the client device, (2) a first data parameter that may be a timestamp specifying the time when the digital token was created, (3) instructions specifying the type of action to be taken with respect to the user information stored at the multiple servers (e.g., erase the user information, prevent transmission of the information, modify who can access the information, request disclosure of the collected user information, request export of the collected user information, or other request regarding the user information), and (4) data identifying the multiple servers (e.g., a specific identification of the domain of the multiple servers, or a global instruction to send a request to a server in communication with the relay server 108). In some implementations (and as described above with reference to FIG. 2), the attestation token may also include a device trust token previously generated by a device trust server and provided to the client device 102.

[0098] Second, the client device 102 obtains an encrypted digital token using the encryption key to encrypt the digital token using a symmetric encryption algorithm. In some implementations, the symmetric encryption algorithm is probabilistic. In some implementations (and as described above with reference to FIG. 2), the client device 102 generates the encryption key by (1) calculating a first MAC using the current date and a first data string (e.g., the phrase "encrypt"), and (2) generating a second MAC using the device identifier and the first MAC. The operations for generating a symmetric encryption key can be represented using the following formulation: HMAC(DeviceID,HMAC(current_date,"encrypt")

[0099] As described above with reference to FIG. 2, the above calculations may be calculated in alternative ways and may be calculated using another cryptographically significant pseudorandom function other than HMAC.

[0100] Thus, in some implementations, the client device 102 sends a request to the device trust server 110 to verify the trust of the client device 102, the request including a first set of data, as described above.

[0101] As described above with reference to FIG. 2, the MAC generator 208 of the client device 102 generates message authentication codes (MACs) for different data sets. In some implementations, the MAC generator 208 uses a MAC algorithm (which is a type of cryptographic pseudorandom function) to generate a hash-based message authentication code (HMAC), also called a keyed-hash message authentication code. In such implementations, the MAC generator 208 generates the HMAC (e.g., using the HMAC SHA256 algorithm) for different sets of data / parameters. In some implementations, rather than using HMAC or another MAC algorithm, the MAC generator 208 uses another suitable cryptographic pseudorandom function (PRF), possibly using parameters used by the MAC generator 208 in generating various digital digests as described below. For ease of reference, the remainder of the description of the example process 300 of FIG. 3 will assume that the MAC generator 208 of the client device 102 generates a MAC or HMAC, although it will be appreciated that the same functions / computations described below may alternatively be performed using another suitable cryptographically significant PRF.

[0102] The device trust server 110 uses the device trust data included in the request to verify the trustworthiness of the device when determining whether the client device 102 is trustworthy. The device trust server 110 sends data to the client device 102 indicating that the client device is trustworthy.

[0103] The client device 102 receives (at 310) data from the device trust server indicating that the client device is trustworthy. In some implementations (and as described above with reference to FIG. 2), the device trust server 110 indicates that the client device 102 is trustworthy by digitally signing the third MAC value generated by the device using the encrypted digital token and the first data parameter with the device trust server's 110 private key. Because the third MAC is digitally signed by the device trust server 110, the client device 102 cannot modify the response from the device trust server 110. Alternatively, rather than indicating trust by digitally signing the third MAC, the device trust server 110 can indicate the trustworthiness of the device using a flag (e.g., a 1-bit flag where 0 indicates untrustworthy and 1 indicates trusted) or other data (e.g., a data message where "TRUST" indicates that the device is trustworthy and "DON'T TRUST" indicates that the device is not trustworthy). In the remainder of the process 300, it is assumed that the device trust server 110 has indicated the trustworthiness of the device by digitally signing the third MAC.

[0104] In response to receiving the data indicating that the client device is trustworthy, the client device 102 sends (at 315) to the relay server 108 a request to control the user information stored at the multiple servers. The request to control the user information specifies an action to be performed by the server with respect to the user information. For example, the action to be performed by the server may include (1) erasing the user information stored at the server, (2) requesting that the user information stored at the server not be transmitted or given to any other entity, (3) enabling access to the user information stored at the server to one or more entities, or (4) another appropriate action requested by the client device with respect to the user information stored at the server.

[0105] In some implementations, the request to control the user information includes a second set of data including: (1) data indicating that the client device is trustworthy (received from the device trust server 110 in operation 310); (2) an encrypted digital token previously generated by the client device 102; (3) a first data parameter included in the digital token; (4) data identifying multiple servers where appropriate action regarding the user information should be taken; and (5) a fourth MAC generated using the device identifier, the second data parameter (e.g., the current date), and the third data parameter, which may be a data string (e.g., the phrase "challenge"). The fourth MAC may be expressed using the following formulation: HMAC(DeviceID,HMAC(current_date,"challenge")

[0106] As described above with reference to FIG. 2, the above calculations may be calculated in alternative ways and may be calculated using another cryptographically significant pseudorandom function other than HMAC.

[0107] Upon receiving the request from the client device 102, the relay server 108 validates the request as described with respect to Figure 2. In response to validating the request from the client device 102, the relay server 108 transmits requests to control the user information to the various servers specified in the request from the client device 102 (as described with respect to Figure 2).

[0108] As described with respect to FIG. 2, when the server receives a request from the relay server 108, it validates the request. If the server determines that the request is valid, it performs the action specified in the request to control the user information stored at the server (as described with respect to FIG. 2). On the other hand, if the server determines that the request is not valid, it does not perform the action specified in the request to control the user information stored at the server (as described with respect to FIG. 2). The server sends a response to the relay server 108 specifying whether the server fulfilled the request or did not fulfill the request (as described with respect to FIG. 2).

[0109] The client device 102 receives (at 320) responses from each of the multiple servers via the relay server. In some implementations, and as described above with reference to FIGURE 2, upon receiving responses from the various servers, the relay server transmits these responses to the client device 102. The client device 102 receives these transmitted responses from the relay server 108 (as described with respect to FIGURE 2).

[0110] Based on the response received by the client device 102 in operation 320, the client device 102 determines (at 325) that at least a subset of the multiple servers that contained the user information performed the action specified in the request to control the user information. In some implementations, the client device 102 processes the received response to determine whether the respective server fulfilled the request or did not fulfill it. If the server responded that it fulfilled the request, the client device 102 determines that the server stored the user information and that the server performed the action specified in the client device's request to control the user information in operation 315.

[0111] Thus, in this manner, requests from client device 102 to control user information stored on multiple servers are generated, transmitted to the multiple servers that store this information, and processed and fulfilled by those servers.

[0112] 4 is a block diagram of an exemplary computer system 400 that may be used to perform the operations described above. The system 400 includes a processor 410, a memory 420, a storage device 430, and an input / output device 440. Each of the components 410, 420, 430, and 440 may be interconnected, for example, using a system bus 450. The processor 410 is capable of processing instructions for execution within the system 400. In some implementations, the processor 410 is a single-threaded processor. In another implementation, the processor 410 is a multi-threaded processor. The processor 410 is capable of processing instructions stored in the memory 420 or on the storage device 430.

[0113] The memory 420 stores information within the system 400. In one implementation, the memory 420 is a computer-readable medium. In some implementations, the memory 420 is a volatile memory unit. In another implementation, the memory 420 is a non-volatile memory unit.

[0114] The storage device 430 is capable of providing mass storage for the system 400. In some implementations, the storage device 430 is a computer-readable medium. In various different implementations, the storage device 430 may include, for example, a hard disk device, an optical disk device, a storage device shared by multiple computing devices over a network (e.g., a cloud storage device), or some other mass storage device.

[0115] The input / output devices 440 provide input / output operations for the system 400. In some implementations, the input / output devices 440 may include one or more of a network interface device, e.g., an Ethernet card, a serial communication device, e.g., an RS-232 port, and / or a wireless interface device, e.g., an 802.11 card. In another implementation, the input / output devices may include driver devices, e.g., keyboards, printers, and display devices, configured to receive input data and send output data to the peripheral devices 460. However, other implementations may be used, such as mobile computing devices, mobile communication devices, set-top boxes, television client devices, and the like.

[0116] Although an exemplary processing system is described in FIG. 4, implementations of the subject matter and functional operations described herein can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware including the structures disclosed herein and their structural equivalents, or in a combination of one or more of these.

[0117] The subject matter and embodiments of the operations described herein may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware including the structures disclosed herein and their structural equivalents, or in a combination of one or more of them. The subject matter described herein may be implemented as one or more computer programs, i.e., as one or more modules of computer program instructions encoded on a number of computer storage media (or one computer storage medium) for execution by or for controlling the operation of a data processing device. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to an appropriate receiver device for execution by the data processing device. The computer storage medium may be or be included in a computer readable storage device, a computer readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, the computer storage medium is not a propagating signal, and the computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagating signal. A computer storage medium may also be, or be contained in, one or more separate physical components or media (eg, multiple CDs, disks, or other storage devices).

[0118] The operations described herein may be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0119] The term "data processing apparatus" encompasses any kind of apparatus, device, and machine for processing data, including, by way of example, a programmable processor, a computer, a system on a chip, or a plurality or combination of the above. The apparatus may include special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, such as code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of these. The apparatus and execution environment may implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0120] A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may correspond to a file in a file system, but need not. A program may be stored in file portions that hold other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple cooperating files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers located at one location, or distributed across multiple locations and interconnected by a communication network.

[0121] The processes and logic flows described herein may be implemented by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be implemented by, and devices may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0122] Processors suitable for executing computer programs include, by way of example, both general-purpose and special-purpose microprocessors. In general, a processor will receive instructions and data from a read-only memory or a random access memory, or both. The essential elements of a computer are a processor for performing actions according to instructions, and one or more memory devices for storing instructions and data. In general, a computer also includes one or more mass storage devices, e.g., magnetic, magneto-optical, or optical disks, for storing data, or is operatively coupled to a mass storage device to receive data from or transfer data to the mass storage device, or both. However, a computer need not have such devices. Moreover, a computer can be incorporated in another device, e.g., a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few examples. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices, magnetic disks, e.g., internal hard disks or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0123] To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on a computer having a display device, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user, and a keyboard and a pointing device, such as, for example, a 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, for example, visual feedback, auditory feedback, or tactile feedback, and input from the user can be received in any form, including acoustic, speech, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from a device used by the user, for example, by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

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

[0125] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server sends data (e.g., HTML pages) to a client device (e.g., for purposes of displaying the data to a user interacting with the client device and receiving user input from the user). Data generated at the client device (e.g., the result of a user interaction) may be received at the server from the client device.

[0126] Although this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or what may be claimed, but as descriptions of features specific to certain embodiments of a particular invention. Also, some features described in the context of separate embodiments can be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features are described above as working in some combinations and may even be initially claimed as such, one or more features from a claimed combination may, in some cases, be deleted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0127] Similarly, although operations are shown in the figures in a particular order, this should not be understood as requiring that such operations be performed in the particular order or sequence shown, or that all of the illustrated operations be performed, to achieve desirable results. In some situations, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the program components and systems described may generally be integrated together in a single software product or packaged in multiple software products.

[0128] Above, specific embodiments of the present subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Moreover, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequence, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous. [Explanation of symbols]

[0129] 102 client devices 104 Network 106 Content Platforms, Servers, Providers 108 Relay servers, content providers 110 Device Reliability Server 202 Application A 204 Operating Systems 206 Token Generator 208 MAC Generator 210 Device Trust Client 224 Lookup Table 400 Computer system, system 410 Processor, component 420 Memory, components 430 Storage devices, components 440 Input / Output Devices, Components 450 System Bus 460 Peripheral Devices

Claims

1. 1. A computer-implemented method, comprising: sending, by a client device, a request to a device trust server to verify the trust of said client device; receiving, by the client device, data from the device trust server indicating that the client device is trustworthy; sending, by the client device to an intermediary server, a request to control user data stored at a plurality of servers in response to receiving the data indicating that the client device is trustworthy; the relay server is a server that determines that the client device has been determined to be trustworthy by the device trust server based on the data indicating that the client device is trustworthy, and validates the request to control user data before transmitting the request to control user data to each of the plurality of servers; the request to control user data includes the data indicating that the client device is trustworthy and specifies an action to be taken by at least a subset of the plurality of servers with respect to the user data; receiving, by the client device, a response from each of the plurality of servers via the relay server; and determining, by the client device, based on the response, that at least a subset of the plurality of servers that contained the user data have performed the action specified in the request to control the user data.

2. A step of sending a request to a relay server by the client device to control user data stored in a plurality of servers, generating, by the client device, a digital token including: (1) a device identifier of the client device; (2) a first data parameter, the first data parameter being a timestamp specifying a time at which the digital token was created; (3) instructions specifying a type of action with respect to user data stored at a plurality of servers; and (4) data identifying the plurality of servers; 2. The computer-implemented method of claim 1, further comprising: encrypting, by the client device, the digital token using a symmetric encryption algorithm to obtain the encrypted digital token, wherein the request to control user data further includes the encrypted digital token.

3. encrypting, by the client device, the digital token using the symmetric encryption algorithm to obtain the encrypted digital token, generating an encryption key based on a current date, a first data string, and data parameters including the device identifier using a cryptographic pseudorandom function; and encrypting, by the client device, the digital token with the encryption key to obtain the encrypted digital token.

4. generating the encryption key based on data parameters including a current date, a first data string, and the device identifier using the cryptographic pseudorandom function, the step of:

4. The computer-implemented method of claim 3, comprising generating the encryption key by (1) calculating a first message authentication code (MAC) using the current date and the first string of data, and (2) generating a second MAC using the device identifier and the first MAC.

5. the request to verify the authenticity of the client device includes a first set of data including: (1) device authenticity data from which the authenticity of the client device is determined; and (2) a third MAC generated using the encrypted digital token and the first data parameter; 5. The computer-implemented method of claim 2, 3, or 4, wherein the request to control user data further includes (1) the first data parameter, (2) data identifying the plurality of servers, and (3) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter.

6. 6. The computer-implemented method of claim 5, wherein the second data parameter comprises a current date and the third data parameter comprises a second string of data.

7. The step of receiving, by the client device, data from the device trust server indicating that the client device is trustworthy, 7. The computer-implemented method of claim 6, further comprising receiving, by the client device, from the device trust server, a digital signature by the device trust server of the third MAC.

8. The action to be performed by at least a subset of the plurality of servers with respect to the user data includes: erasing the user data stored on at least a subset of the plurality of servers; adjusting access settings for the user data stored in at least a subset of the plurality of servers such that the user data is not transmitted or provided to any other entity; adjusting access settings for the user data stored on at least a subset of the plurality of servers to enable access to the user data for one or more entities; Disclose any collected user data; or and exporting the collected user data.

9. one or more memory devices for storing instructions; and a client device configured to interact with the one or more memory devices and, when the instructions are executed, to perform operations including a computer-implemented method, the method comprising: sending, by the client device, a request to a device trust server to verify the trust of the client device; receiving, by the client device, data from the device trust server indicating that the client device is trustworthy; sending, by the client device to an intermediary server, a request to control user data stored at a plurality of servers in response to receiving the data indicating that the client device is trustworthy; the relay server is a server that determines that the client device has been determined to be trustworthy by the device trust server based on the data indicating that the client device is trustworthy, and validates the request to control user data before transmitting the request to control user data to each of the plurality of servers; sending the request to control user data, the request including the data indicating that the client device is trustworthy and specifying an action to be taken by at least a subset of the plurality of servers with respect to the user data; receiving, by the client device, a response from each of the plurality of servers via the relay server; and determining, by the client device, based on the response, that at least a subset of the plurality of servers that contained the user data performed the action specified in the request to control the user data.

10. The method of claim 1, further comprising: sending, by the client device, to a relay server, a request for controlling user data stored at a plurality of servers; generating, by the client device, a digital token that includes: (1) a device identifier of the client device; (2) a first data parameter, the first data parameter being a timestamp specifying a time at which the digital token was created; (3) instructions specifying a type of action with respect to user data stored at a plurality of servers; and (4) data identifying the plurality of servers; 10. The system of claim 9, further comprising: encrypting, by the client device, the digital token using a symmetric encryption algorithm to obtain the encrypted digital token, and wherein the request to control user data further includes the encrypted digital token.

11. encrypting, by the client device, the digital token using the symmetric encryption algorithm to obtain the encrypted digital token, generating an encryption key based on a current date, a first data string, and data parameters including the device identifier using a cryptographic pseudorandom function; and encrypting, by the client device, the digital token with the encryption key to obtain the encrypted digital token.

12. generating the encryption key based on data parameters including a current date, a first data string, and the device identifier using the cryptographic pseudorandom function; 12. The system of claim 11, comprising: (1) calculating a first message authentication code (MAC) using the current date and the first string of data; and (2) generating the encryption key by generating a second MAC using the device identifier and the first MAC.

13. the request to verify the authenticity of the client device includes a first set of data including: (1) device authenticity data from which the authenticity of the client device is determined; and (2) a third MAC generated using the encrypted digital token and the first data parameter; 13. The system of claim 10, 11, or 12, wherein the request to control user data further includes: (1) the first data parameter; (2) data identifying the plurality of servers; and (3) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter.

14. 14. The system of claim 13, wherein the second data parameter comprises a current date and the third data parameter comprises a second string of data.

15. Receiving, by the client device, data from the device trust server indicating that the client device is trustworthy, 15. The system of claim 14, further comprising receiving, by the client device, from the device trust server, a digital signature by the device trust server of the third MAC.

16. The action to be performed by at least a subset of the plurality of servers with respect to the user data includes: erasing the user data stored on at least a subset of the plurality of servers; adjusting access settings for the user data stored in at least a subset of the plurality of servers such that the user data is not transmitted or provided to any other entity; adjusting access settings for the user data stored on at least a subset of the plurality of servers to enable access to the user data for one or more entities; Disclose any collected user data; or and exporting the collected user data.

17. A computer-readable storage medium storing instructions that, when executed by a client device, cause the client device to perform an operation, the operation comprising: sending, by the client device, a request to a device trust server to verify the trust of the client device; receiving, by the client device, data from the device trust server indicating that the client device is trustworthy; sending, by the client device to an intermediary server, a request to control user data stored at a plurality of servers in response to receiving the data indicating that the client device is trustworthy; the relay server is a server that determines that the client device has been determined to be trustworthy by the device trust server based on the data indicating that the client device is trustworthy, and validates the request to control user data before transmitting the request to control user data to each of the plurality of servers; sending the request to control user data, the request including the data indicating that the client device is trustworthy and specifying an action to be taken by at least a subset of the plurality of servers with respect to the user data; receiving, by the client device, a response from each of the plurality of servers via the relay server; and determining, by the client device, based on the response, that at least a subset of the plurality of servers that contained the user data performed the action specified in the request to control the user data.

18. The method of claim 17, further comprising: sending, by the client device, to a relay server a request for controlling user data stored at a plurality of servers; generating, by the client device, a digital token that includes: (1) a device identifier of the client device; (2) a first data parameter, the first data parameter being a timestamp specifying a time at which the digital token was created; (3) instructions specifying a type of action with respect to user data stored at a plurality of servers; and (4) data identifying the plurality of servers; and encrypting, by the client device, the digital token using a symmetric encryption algorithm to obtain the encrypted digital token, wherein the request to control user data further includes the encrypted digital token.

19. encrypting, by the client device, the digital token using the symmetric encryption algorithm to obtain the encrypted digital token, generating an encryption key based on a current date, a first data string, and data parameters including the device identifier using a cryptographic pseudorandom function; and encrypting, by the client device, the digital token with the encryption key to obtain the encrypted digital token.

20. generating the encryption key based on data parameters including a current date, a first data string, and the device identifier using the cryptographic pseudorandom function; 20. The computer-readable storage medium of claim 19, comprising: (1) calculating a first message authentication code (MAC) using the current date and the first string of data; and (2) generating the encryption key by generating a second MAC using the device identifier and the first MAC.

21. the request to verify the authenticity of the client device includes a first set of data including: (1) device authenticity data from which the authenticity of the client device is determined; and (2) a third MAC generated using the encrypted digital token and the first data parameter; 21. The computer-readable storage medium of claim 18, 19, or 20, wherein the request to control user data further includes: (1) the first data parameter; (2) data identifying the plurality of servers; and (3) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter.

Images