Patent Description:
<CIT> describes a user making a request to access a protected resource identified by an URL, client-side code in a web browser is used to generate an authentication token, which is then sent to the server along with an identity cookie that was set by that server. The authenticated token is then used by the server to authenticate that the request is properly tied to a given identity contained in the identity cookie. If the authentication token can be validated at the server, an access control decision is then executed to determine whether to invoke the request for the protected resource. If the authentication token cannot be validated, an access denied request is returned to the requesting client.

<CIT> describes an authorization code response transmitted to a client, the client uses a parameter included in the authorization code response and a parameter included in the authorization code response transmitted by a transmitting unit to verify that the authorization code response corresponds to an authorization code request.

<CIT> describes an apparatus comprising a fuse controller coupled to an aggregator. The fuse controller include a plurality of fuses for storing a unique identifier of a device and a first secured value of a first password associated with the unique identifier. The aggregator is to receive the unique identifier and the first secured value from the fuse controller, send the unique identifier to an unlock host, receive a second password from the unlock host, compute a second secured value of the second password using a security function, and unlock one or more privileged features on the device based on the first secured value corresponding to the second secured value.

<CIT> describes a rule that may be applied to modify a token of a process. The rule may include an application-criterion set and changes to be made to the groups and/or privileges of the token. The rule may be set as a policy within a group policy objection where the group policy object is associated with one or more groups of computers or users. When a group policy object containing a rule is applied to a computer, a driver installed on the computer may access the rule anytime a logged-on user executes a process. If the executed process satisfies the criterion set of a rule, the changes contained within the rule are made to the process token, and the user has expanded and/or contracted access and/or privileges for only that process.

This specification describes technologies relating to updating user consent settings for user data collection and usage based on user input such that the user consent is technically verifiable.

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include receiving, from a client device, a request including an attestation token, the attestation token including: a set of data that includes at least: a user identifier that uniquely identifies a user of the client device; a token creation time that indicates a time at which the attestation token was created; user consent data specifying whether one or more entities that receive the attestation token are eligible to use data of the user; and an action to be performed in response to the request; and a digital signature of at least a portion of the set of data, including at least the user identifier and the token creation time; and verifying an integrity of the request using the attestation token, including: determining whether the token creation time is within a threshold duration of a time at which the request was received; determining, using the digital signature, whether the set of data was modified after the attestation token was created; and determining that the integrity of the request is valid based at least on determination that the token creation time is within the threshold duration of the time at which the request was received and a determination that the set of data has not been modified since the attestation token was created; and performing the action in response to determining that the integrity of the request is valid. Performing the action comprises: determining that the user consent data specifies one or more authorized actions that are authorized by the user to be performed by a given entity using the data of the user; and preventing the given entity from using the data of the user for actions other than the specified one or more authorized actions. Other implementations of this aspect include corresponding apparatus, systems, and computer programs, configured to perform the aspects of the methods, encoded on computer storage devices.

These and other implementations can each optionally include one or more of the following features. In some aspects, performing the action includes determining that the user consent data indicates that the data of the user is to be deleted and deleting the data of the user.

In some aspects, performing the action includes determining that the user consent data specifies one or more authorized actions that are authorized by the user to be performed by a given entity using the data of the user and preventing the given entity from using the data of the user for actions other than the specified one or more authorized actions.

In some aspects, the set of data includes payload data that includes the user consent data. The payload data can include a domain to which the action applies. Some aspects can include determining that the action is a user consent action to modify previous consent given by the user for the domain to use the data of the user.

In some aspects, the set of data includes payload data that includes the user consent data. The payload data can include a domain to which the action applies. Some aspects can include determining that the action is a request for one or more digital components, selecting the one or more digital components in accordance with the user consent data, and providing the one or more digital components to the client device.

In some aspects, the digital signature is a signature of the user identifier, the token creation time, and the payload. In some aspects, the set of data includes at least one of a device integrity token or a browser integrity token.

In some aspects, the one or more entities includes multiple recipient entities to which the request is provided and the user consent data includes, for each recipient entity, an encrypted consent element that includes user consent data specific to the recipient entity, wherein the encrypted consent element for each recipient entity is encrypted using a public key of the recipient entity.

Some aspects includes receiving a second request that includes a second user identifier and a second token creation time, determining that the second user identifier of the second request matches the user identifier of the request, determining that the second token creation time of the second request matches the token creation time of the request, and in response to determining that the second user identifier of the second request matches the user identifier of the request and that the second token creation time of the second request matches the token creation time of the request, determining that either the second request is a duplicate of the request or a replay attack has occurred.

The subject matter described in this specification can be implemented in particular embodiments so as to realize one or more of the following advantages. Using attestation tokens described in this document to communicate user consent settings to other entities ensures that the user consent settings were received from the user and enables the entities to technically verify the user's consent. The attestation tokens use digital signature schemes to prevent entities from falsifying users' consent, thereby preserving data security. The attestation tokens securely link user identifiers with user data and with user consent settings such that the entities that receive the user data can verify the user's consent to use the user data in accordance with the user consent. In this way, a user is provided with a mechanism in which they can manage their data in a secure way when dealing with multiple entities.

Client devices can send the attestation tokens with expiration dates each time user consent settings are modified and/or prior to expiration to establish a continuous chain of user consent settings. This prevents entities from ignoring user requests for entities to delete the user's data or stop using the data in specified ways. Client devices can require a response from recipients of the attestation tokens to further verify receipt of user consent settings and prevent the recipient entities from ignoring the user requests.

The use of attestation tokens as described in this document enable third-party auditors to verify that user data is only being used in accordance with the consent of the users. This gives users the ability to manage how other entities collect and use their data and prevents entities from using the data improperly. This also protects entities that use such data properly by giving the entities a means to verify in a trusted manner the consent that they were given to collect and use the data.

The use of attestation tokens as described in this document also enables users to easily and securely manage how their data is collected and used. For example, the techniques described in this document enable a user to change consent settings that apply to many different entities from a single user interface rather than having to manage consent settings individually for each entity.

Various features and advantages of the foregoing subject matter is described below with respect to the figures. Additional features and advantages are apparent from the subject matter described herein and the claims.

In general, systems and techniques described herein enable users to change consent settings that define whether their data can be collected or maintained by other entities, what data is collected, and/or how their data is used by the entities. For example, some publishers of electronic resources, e.g., web pages, use cookies to collect user data and use that data to customize content of the resources. The techniques described in this document provide technical mechanisms that enable the user to define, in a secure way, whether such data can be collected, and if so, how that data is used. The entities can store the user data with user identifiers that uniquely identify the users to which the data belongs.

The user consent settings can be sent from a client device of the user in the form of an attestation token. The attestation token can include the consent settings and a digital signature of the consent settings and other data such that any modification to the user consent settings after creation can be detected. The signed data can include a unique identifier for the user so that recipients of the attestation token can verify that the attestation token was sent from a device of the user. The attestation token can also include an integrity token, e.g., a device integrity token and/or a browser integrity token, so that recipients can verify that the attestation token was received from a trusted device or trusted web browser or other application.

<FIG> is a block diagram of an environment <NUM> in which a digital component system <NUM> distributes digital components <NUM>. The example environment <NUM> includes a data communication network <NUM>, such as a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof. The network <NUM> connects client devices <NUM>, publishers <NUM>, websites <NUM>, the digital component distribution system <NUM>, and an auditing system <NUM>. The example environment <NUM> may include many different client devices <NUM>, publishers <NUM>, and websites <NUM>. In some implementations, the environment <NUM> can also include multiple digital component distribution systems <NUM> and/or auditing system <NUM>.

A website <NUM> is one or more resources <NUM> associated with a domain name and hosted by one or more servers. An example website is a collection of web pages formatted in HTML that can contain text, images, multimedia content, and programming elements, such as scripts. Each website <NUM> is maintained by a publisher <NUM>, which is an entity that controls, manages and/or owns the website <NUM>.

A resource <NUM> is any data that can be provided over the network <NUM>. A resource <NUM> is identified by a resource address, e.g., a Universal Resource Locator (URL), that is associated with the resource <NUM>. Resources include HTML pages, word processing documents, and portable document format (PDF) documents, images, video, and feed sources, to name only a few. The resources can include content, such as words, phrases, images and sounds, that may include embedded information (such as meta-information in hyperlinks) and/or embedded instructions (such as scripts).

A client device <NUM> is an electronic device that is capable of communicating over the network <NUM>. Example client devices <NUM> include personal computers, mobile communication devices, e.g., smart phones, and other devices that can send and receive data over the network <NUM>. A client device can also include a digital assistant device that accepts audio input through a microphone and outputs audio output through speakers. The digital assistant can be placed into listen mode (e.g., ready to accept audio input) when the digital assistant detects a "hotword" or "hotphrase" that activates the microphone to accept audio input. The digital assistant device can also include a camera and/or display to capture images and visually present information. The digital assistant can be implemented in different forms of hardware devices including, a wearable device (e.g., watch or glasses), a smart phone, a speaker device, a tablet device, or another hardware device. A client device can also include a digital media device, e.g., a streaming device that plugs into a television or other display to stream videos to the television.

A client device <NUM> typically includes applications, such as a web browser <NUM> and/or native applications <NUM> to facilitate the sending and receiving of data over the network <NUM>. A native application <NUM> is an application developed for a particular platform or a particular device. Publishers <NUM> can develop and provide the native applications to the client devices <NUM>.

In some implementations, the client device <NUM> is a digital media device, e.g., a streaming device that plugs into a television or other display to stream videos to the television. The digital media device can also include a web browser and/or other applications that stream video and/or present resources.

The web browser <NUM> can request a resource <NUM> from a web server that hosts a website <NUM> of a publisher <NUM>, e.g., in response to the user of the client device <NUM> entering the resource address for the resource <NUM> in an address bar of the web browser <NUM> or selecting a link that references the resource address. When the web server (e.g., in a particular domain) provides a resource <NUM> to the web browser <NUM>, the web server can also provide a cookie <NUM> of the publisher <NUM> that the web browser <NUM> stores on the client device <NUM>. The cookie <NUM> is a small amount of data, e.g., a text file, that can be used for many purposes, including storing stateful information, recording browsing activity, and authenticating users. The cookies <NUM> can include a unique cookie identifier and the small amount of data (which can include a cookie value, attributes, etc.). This cookie is referred to as a first-party cookie as the cookie is created by a website that a user views directly, i.e., the website for which the domain is viewable in the address bar of the web browser <NUM>.

The web browser <NUM> can send the publisher's first-party cookie to the web server that hosts the website <NUM> when the web browser <NUM> subsequently navigates to the resource <NUM> and/or while the resource <NUM> is presented by the web browser <NUM>. The web server can use the data in the cookie <NUM>, for example, to customize content for the user.

In some cases, another web server that hosts another website (e.g., in a different domain than the particular domain) also stores a cookie <NUM> on the client device <NUM> while the resource <NUM> is presented in the web browser <NUM>, although that website's domain is not viewable in the address bar of the web browser <NUM> and the user did not navigate the web browser to that website. This cookie is referred to as a third-party cookie. A third-party cookie can be stored on the client device <NUM> when the resource <NUM> makes a call for content from the other web server.

Some resources <NUM>, application pages, or other application content can include digital component slots for presenting digital components with the resources <NUM> or application pages. As used throughout this document, the phrase "digital component" refers to a discrete unit of digital content or digital information (e.g., a video clip, audio clip, multimedia clip, image, text, or another unit of content). A digital component <NUM> can electronically be stored in a physical memory device as a single file or in a collection of files, and digital components can take the form of video files, audio files, multimedia files, image files, or text files and include advertising information, such that an advertisement is a type of digital component. For example, the digital component <NUM> may be content that is intended to supplement content of a web page or other resource presented by the web browser <NUM> or native application <NUM>. More specifically, the digital component <NUM> may include digital content that is relevant to the resource content (e.g., the digital component may relate to the same topic as the web page content, or to a related topic). The provision of digital components by the digital component distribution system <NUM> can thus supplement, and generally enhance, the web page or application content.

When the web browser <NUM> loads a resource <NUM> that includes one or more digital component slots, the web browser <NUM> can request a digital component <NUM> for each slot from the digital component distribution system <NUM>. The digital component distribution system <NUM> can, in turn request digital components from digital component providers <NUM>. The digital component providers <NUM> are entities that provide digital components for presentation with resources <NUM>. Native applications <NUM> can request and present digital components <NUM> in a similar manner.

In some cases, the digital component distribution system <NUM> can also request digital components from one or more digital component partners <NUM>. A digital component partner <NUM> is an entity that selects digital components <NUM> on behalf of digital component providers <NUM> in response to digital component requests.

The digital component distribution system <NUM> can select a digital component for each digital component slot based on various criteria. For example, the digital component distribution system <NUM> can select, from the digital components received from the digital component providers <NUM> and/or the digital component partners <NUM>, a digital component based on relatedness to the resource <NUM>, performance of the digital component (e.g., a rate at which users interact with the digital component), etc. The digital component distribution system <NUM> can then provide the selected digital component(s) to the client device <NUM> for presentation with the resource <NUM>.

In some cases, the digital component distribution system <NUM>, the digital component partner <NUM>, and/or the digital component provider <NUM> for which a digital component is provided can also store a third-party cookie <NUM> on the client device <NUM>. The web browser <NUM> can also provide the third-party cookie <NUM> to the entity that stored the third-party cookie on the client device <NUM>. In this way, the entity can use information stored in the third-party cookie <NUM> to select digital components for presentation at the client device <NUM>.

The web browser <NUM> and/or the native applications <NUM> can include tools that enable users to manage the data that is collected, stored, and used by other entities, such as publishers <NUM>, the digital component distribution system <NUM>, the digital component partner, and the digital component providers <NUM>. For example, the web browser <NUM> and/or the native applications <NUM> can include a user interface, e.g., in the form of a menu, web page, or application page, that enables the users to manage their user data.

Managing user data can include configuring and/or adjusting user consent settings. The user consent settings can specify which entities can receive user data from the client device <NUM>, whether and for how long the entities can store the user data, what types of user data the entities can obtain and store, and/or how the entities use the user data. The user data can include various data related to the user, such as resources requested by the user, browser history, digital components <NUM> presented to the user, digital components <NUM> with which the user interacted (e.g., selected), and/or other appropriate data collected using cookies. For digital media devices, the user data can include data specifying videos, movies, or shows viewed and/or recorded by the user, the favorite channels, movies, or shows of the user, sports teams viewed or followed by the user, resources requested using a web browser or other application of the device, and/or other appropriate data.

The user can specify different consent settings for different entities. For example, the user can specify that the digital component distribution system <NUM> (or the entity that operates the system) can collect and store user data and use the user data to select digital components for the user. The user can also specify that the digital component partner <NUM> (or another digital component distribution system) can collect and store the user data, but can only use the data to measure the performance of digital components provided to the user by the digital component partner <NUM> without using the user data to select digital components. The user can also specify that the digital component provider <NUM>-<NUM> is not allowed to collect or store user data of the user. These tools enable the users to manage their data and therefore their privacy across the online ecosystem. By implementing the functionality in a web browser <NUM> or native application <NUM>, an improved user interface is provided in which a user can manage their data across the ecosystem from a single interface rather than providing various consent to each entity individually.

The client device <NUM> of a user can send requests <NUM> for various purposes. The client device <NUM> can send a request <NUM> to update user consent settings in response to the user changing the settings at the client device <NUM>. The client device <NUM> can also send a request <NUM> for a digital component to the digital component distribution system <NUM>, e.g., in response to the web browser <NUM> or native application <NUM> loading a resource that includes a digital component slot.

When the user modifies user consent settings, the web browser <NUM> or native application <NUM> that was used to update the user consent settings can generate the request <NUM> and send the request to one or more entities. These entities can include a set of entities in a registry. The registry can include entities that have agreed to follow a user consent and privacy data management policy. The entities can include publishers <NUM>, digital component distribution systems <NUM> (e.g., ad tech companies), digital component partners <NUM>, and/or digital component providers <NUM>.

In another example, the one or more entities can include entities for which the user has allowed to collect and use the user data of the user. In another example, the one or more entities can include only the entities for which the settings were changed by the user. The web browser <NUM> or native application <NUM> can identify the recipient entities and send, to the recipient entities, a request <NUM> that includes data specifying the user consent settings, e.g., the modified user consent settings.

A request <NUM> can include an attestation token <NUM>. For example, requests to change user consent settings and requests for digital components can include an attestation token <NUM>. When the web browser <NUM> sends a request <NUM>, the web browser <NUM> or an operating system of the client device <NUM> or another trusted program running on the client device <NUM>) can generate the attestation token <NUM> for the request <NUM>. When a native application <NUM> sends a request <NUM>, the native application or the operating system can generate the attestation token <NUM>. However, it may be more secure to use trusted code of the operating system or of the browser binary of the web browser to generate the attestation token <NUM> than using a native application <NUM>.

The structure of and/or data included in an attestation token <NUM> for requests sent by a web browser <NUM> can differ from the structure of and/or data included in an attestation token <NUM> for requests sent by a native application <NUM>. However, the attestation tokens <NUM> can have similar data, including a set of data <NUM> and a digital signature <NUM> of the set of data <NUM>. In some implementations, the structure and data of the attestation token <NUM> are the same or similar for both web browsers <NUM> and native applications <NUM>.

The set of data <NUM> can include, for both web browsers <NUM> and native applications <NUM>, data specifying the purpose or operation of the request (e.g., to change user consent settings or request a digital component), a user identifier that uniquely identifies the user (e.g., a public key), an attestation token creation time that that indicates a time at which the attestation token <NUM> was created, an integrity token (e.g., a device integrity token and/or a browser integrity token), and a digital signature <NUM> of at least a portion of the other data of the attestation token <NUM>.

For a native application <NUM>, the set of data <NUM> in the attestation token <NUM> can include the user identifier, the attestation token creation time, a payload, and a device integrity token. The user identifier can be a public key of the client device <NUM>. For example, the client device <NUM> can generate and/or maintain one or more pairs of cryptographic keys including a device private key 113A and a device public key 113B that corresponds to, and is mathematically linked to, the device private key 113A. Data that is digitally signed using a private key can only be verified using the corresponding public key. Similarly, data that is encrypted using the public key can only be decrypted using the corresponding private key.

The native application <NUM> can generate the digital signature <NUM> of the set of data <NUM> (or of a pre-processing, e.g., a hash, of the data <NUM>) using the device private key 113A that corresponds to the device public key 113B that serves as the user identifier. In some implementations, the native application <NUM> uses an Elliptic Curve Digital Signature Algorithm (ECDSA) to generate the digital signature <NUM>, but other digital signature techniques can be used, such as RSA. As the attestation token <NUM> can be sent from mobile devices and many attestation tokens may be stored by an entity, signature techniques that result in signatures with smaller data sizes (e.g., ECDSA) may be preferable for reducing bandwidth consumption and data storage requirements. By including the device public key 113B in the attestation token <NUM>, the entities that receive the attestation token <NUM> can verify the digital signature <NUM>.

The device private key 113A and the device public key 113B of the client device <NUM> can be replaced. For example, the keys 113A and 113B can be replaced periodically based on a specified time period to prevent entities from tracking users using the device public key 113B included in the attestation tokens <NUM>. In another example, the user can initiate the key replacement and, in response, a new pair of private and public keys can be generated by the client device <NUM>.

The device private key 113A can be maintained securely and confidentially by the operating system (or other trusted program) of the client device <NUM>. The use of the digital signature <NUM> using the device private key 113A in this manner prevents other entities from forging the payload of the attestation token <NUM> or generating falsified requests <NUM> to seem like they originate from the client device <NUM> as any change to the signed data can result in a completely different digital signature.

The payload in the set of data <NUM> can include data related to the request <NUM>. For example, the payload can include the purpose or operation of the request (e.g., to change user consent settings or request a digital component). For requests to change user consent settings, the payload can include data identifying the entities affected by the settings, e.g., the domains affected by the settings, and the user consent settings for each entity. For example, the payload can include a domain name for an entity and the consent to use the user's data granted to that domain by the user (e.g., measure digital component performance, select personalized digital components).

The payload can also include an expiration time (e.g., a date and time or a time duration) for the user consent settings. Each entity can have the same or a different expiration time. The user consent settings expire when the expiration time lapses. In some implementations, if an entity does not receive updated user consent data prior to the expiration time, the entity is required to delete the user's data or at least stop using the user's data. In some implementations, the native application <NUM> can periodically send the requests <NUM> with user consent settings if the user consent settings have not been modified and the user has specified that the user consent settings should not expire until modified. In this way, the user data may not be deleted unless the user has taken action to delete the user data. In some implementations, the native application <NUM> may require that the user actively agree to continue with the user consent settings, e.g., by prompting the user when the user consent settings are close to expiring.

The native application <NUM> can send a different attestation token <NUM> to each entity. For example, when the user modifies user consent settings, the native application <NUM> can send a different attestation token <NUM> to each entity for which the user consent settings have been modified by the user in cases in which the user changes the settings for multiple entities. This keeps the user consent settings for each entity confidential and prevents entities from aggregating information for other entities.

For requests for digital components, the payload can include data that can be used to select a digital component. This payload could include the native application <NUM> that is sending the request <NUM>, information about the native application <NUM> (e.g., topic of the application <NUM>), information about the digital component slot (e.g., the number of slots, the type of slots, the size of the slots, etc.), information about the client device <NUM> (e.g., type of device, IP address of the device, geographic location of the client device <NUM>) if the user has enabled this feature, and/or other appropriate information.

As described above, the token creation time indicates a time at which the attestation token <NUM> was created. The native application <NUM> or operating system that creates the attestation token <NUM> can record the creation time when the attestation token <NUM> is created. This token creation time can be a high resolution timestamp (e.g., accurate to the second, to the millisecond, or to the microsecond). The token creation time can be used to determine whether a request <NUM> that includes the attestation token <NUM> is new or recent request. For example, the entity that receives the attestation token <NUM> can compare the token creation time to a current time or a time at which the attestation token <NUM> was received. If the difference between the two times exceeds a threshold, the entity can determine that the request is not new, or invalid.

The token creation time can also be used to detect replay attacks. For example, if multiple requests having the same set of data <NUM>, including the same token creation time, are received, the entity that receives the requests can determine that the requests are duplicates and/or that the requests are part of a replay attack.

In another example, a combination of the token creation time with the user identifier (e.g., public key) can be used to detect duplicate requests or replay attacks. This combination can act as a unique identifier for the request and the attestation token of the request. For example, if two requests include the same user identifier and have token creation times that match, the requests may be duplicates and/or part of a replay attack.

The set of data <NUM> can also include an integrity token to enhance the fraud detection capabilities of the attestation token <NUM>. The integrity token can be a device integrity token that enables an entity to determine whether a request <NUM> was sent by a trusted client device <NUM>. For example, the device integrity token can be issued by a third-party device integrity system that evaluates fraud signals of client devices and assigns a level of trustworthiness to the client devices based on the evaluation.

The device integrity token for a client device <NUM> can include a verdict that indicates the level of trustworthiness (or integrity) of the client device <NUM> at the time that the device integrity token was generated, a device integrity token creation time that indicates a time at which the device integrity token was generated, and a unique identifier for the client device <NUM> (e.g., the device public key 113B of the client device or its derivative). The device integrity token can also include a digital signature of the data in the device integrity token using a private key of the device integrity system. For example, the device integrity system can sign the data using its private key, which the system maintains confidentially. The entities that receive the attestation token <NUM> can use a public key of the device integrity system to verify the signature of the device integrity token. As the integrity of a client device <NUM> can change over time, each client device <NUM> can request a new device integrity token periodically.

The digital signature <NUM> of the attestation token <NUM> can be a digital signature of the set of data <NUM> (or a pre-processing of the data <NUM>) using the device private key 113A. For example, the digital signature <NUM> can be a digital signature of the payload, the user identifier (e.g., device public key 113B), the attestation token creation time, and the integrity token. In this way, the entities that receive the request <NUM> can verify that none of this data has changed or been forged by verifying the digital signature <NUM> using the public key 113B.

For a web browser <NUM>, the attestation token <NUM> can include similar data and a similar structure as the attestation token <NUM> for the native application <NUM>. For example, the attestation token <NUM> can include a set of data <NUM> that includes a user identifier, an attestation token creation time, an integrity token, and a payload. The attestation token <NUM> can also include a digital signature <NUM> of the set of data <NUM>.

The integrity token can be the same device integrity token described above for attestation tokens <NUM> included in requests from native applications. In another example, the integrity token can be a browser integrity token that indicates the integrity of the web browser <NUM>, or whether the user's interactions with websites are genuine. Examples of non-genuine user interactions include interactions initiated by bots, etc. rather than the user. A browser integrity token can be issued by a third-party browser integrity system based on fraud detection signals sent to the third browser integrity system. The fraud signals can include, for example, mouse movement speed, direction, intermission and other patterns, click patterns, etc..

Similar to the device integrity token, the browser integrity token for a web browser <NUM> can include a verdict that indicates the level of trustworthiness (or integrity) of the web browser <NUM>, or the level of genuineness of user interactions with websites, at the time that the browser integrity token was generated, a browser integrity creation time that indicates a time at which the browser integrity token was generated, and a unique identifier for the client device <NUM> (e.g., the public key 113B of the client device or web browser or its derivative). The browser integrity token can also include a digital signature of the data in the browser integrity token using a private key of the browser integrity system. For example, the browser integrity system can digitally sign the data using its private key, which the system maintains confidentially. The entities that receive the attestation token <NUM> can use a public key of the browser integrity system to verify the signature of the browser integrity token. The client device <NUM> can store integrity tokens <NUM> (e.g., a device integrity token and/or a browser integrity token) for inclusion in attestation tokens <NUM>.

The public key used as the user identifier in attestation tokens <NUM> sent by the web browser <NUM> can vary in different implementations. In some implementations, the user identifier is the device public key 113B similar to the user identifier in attestation tokens for native applications <NUM>.

In some implementations, the user can be associated with multiple user identifiers that have limited scope. For example, the web browser <NUM> can generate, for each first-party domain, a domain private key 118A and a domain public key 118B that corresponds to, e.g., that is mathematically linked to, the domain private key 118A. For example, the web browser <NUM> can generate a public/private key pair for each domain that the web browser <NUM> navigates to on the client device <NUM>. This domain public key 118B for a particular domain can serve as the user identifier for the user for requests <NUM> sent in response to the web browser <NUM> navigating to the particular domain.

In this way, for a particular domain, the domain public key 118B will be the user identifier in the third-party context. As the user identifier seen by the third parties will be different for each first-party domain, the scope of the user data for that user identifier will be limited to the data for that first-party domain. Thus, the third parties will not be able to aggregate the user data across all first-party domains. Instead, the third parties will treat each user identifier as a unique user. By using a public key for each domain as the user identifier for that domain, the user consent can be verified at the domain level.

In another example, the web browser <NUM> can also generate, for each third-party that has a third-party cookie on the client device <NUM>, a third-party private key 119A and a corresponding third-party public key 119B. For example, the web browser <NUM> can generate a public/private key pair for each third-party domain that stores a cookie on the client device <NUM> while the web browser <NUM> was presenting a resource of a first party domain. In this example, the user identifier in the attestation token <NUM> sent to a third-party entity is the third-party public key for the third-party entity.

In examples in which a user is associated with multiple user identifiers, e.g., multiple domain public keys 118B for multiple first-party domains or multiple third-party public keys 119B for multiple third-party entities, the web browser <NUM> can send a respective request <NUM> to update the user consent settings for each user identifier. For example, the web browser <NUM> can send a first request that includes, as the user identifier, the domain public key for a first domain, a second request that includes, as the user identifier, the domain public key for a second domain, and so on for each first-party domain for which the web browser <NUM> created a public/private pair. The web browser <NUM> can do this each time the user updates the user consent settings for the various entities.

In some implementations, the user identifier is a cryptographic hash of a public key. When the public key is sent as the payload, the public key can be checked against the identity of a user using the hashing operation used to generate the hash of the public key. In some implementations, the an entity that receives attestation tokens <NUM> from client devices <NUM> can explicitly link the identity of the user with the user data for the user so that the entity can recognize a new request from a user and associate the request (and its data) with the user's identity. In this context, attestation can be associated with signing a request with a public key which is part of the user identify in the given setting (e.g., as the given device, browser, etc.).

The same request <NUM>, or at least the same attestation token <NUM>, can be sent to multiple entities from the web browser <NUM>. Such requests can include the same payload in the set of data <NUM>, e.g., general data related to the request <NUM>. Examples of payload data include, but are not limited to, the intention or intended operation of the attestation token, e.g. update user consent, request digital component <NUM>, additional parameters relevant to the intention or intended operation, e.g. the domain to which the updated user consent applies, the size of the slot in which digital component <NUM> will be rendered, and/or a billing/account ID that uniquely identifies the publisher <NUM> that owns the website <NUM>.

However, some of the data of the request <NUM> or attestation token <NUM> can be specific to each entity to which the request <NUM> is being sent, e.g., each entity in the registry or each entity for which user consent settings are being modified. As this data may be confidential for each entity, the attestation token <NUM> can include an encrypted consent element <NUM> for each entity to which the request is being sent.

An encrypted consent element <NUM> for an entity includes the data that is specific to that entity. This data can include a similar payload as the payload for requests sent from the native applications <NUM>. For example, the payload can include the purpose or operation of the request (e.g., to change user consent settings or request a digital component). For requests to change user consent settings, the payload of an encrypted consent element <NUM> for an entity can include the user consent settings that the user specified for that entity. The payload can also include an expiration time (e.g., a date and time or time duration) for the user consent settings, similar to the expiration time described above.

For requests for digital components, the payload of the encrypted consent element <NUM> for an entity can include data that can be used to select a digital component. This data can vary for different entities as the user may have consented to different types of data, or to whether data can be sent at all, to the different entities. For example, this payload data could include the resource <NUM> that has the digital component slot (or a URL for the resource <NUM>), information about the resource <NUM> (e.g., topic of the resource), information about the digital component slot (e.g., the number of slots, the type of slots, the size of the slots, the restriction of the slots, e.g., only support digital components of a video type, etc.), information about the client device <NUM> (e.g., type of device, IP address of the device, geographic location of the client device <NUM>) if the user has enabled this feature, and/or other appropriate information. The payload of the encrypted consent element <NUM> for an entity can also include a third-party cookie of the entity that is stored at the client device <NUM>.

The payload of the encrypted consent element <NUM> for each third-party entity can also include the user identifier for the user, e.g., a public key. The user identifier in each encrypted consent element <NUM> can be the same as the user identifier in the set of data <NUM> of the attestation token <NUM>. For example, depending on the implementation, this user identifier can be the device public key 113B, the domain public key 118B for the first-party domain for which the web browser <NUM> is presenting a resource, or a third-party public key 119B for the third-party for which the attestation token <NUM> is generated. This inclusion of the user identifier in each encrypted consent element <NUM> binds the encrypted consent elements to the user identifier and to the attestation token <NUM>.

In implementations in which the user identifier of the encrypted consent elements matches the user identifier of the attestation token <NUM> and a public key is used as the user identifier, the user identifier in each encrypted consent element <NUM> can be the public key itself or a derivative of the public key. For example, the user identifier of each encrypted consent element <NUM> can be a hash of the public key generated using a cryptographic hash function, e.g., SHA256. Using a hash of the public key can reduce the data size of the user identifier relative to using the public key itself (e.g., from <NUM> bytes for ECDSA using NIST P-<NUM> to <NUM> bytes for RSA-<NUM> to <NUM> bytes for SHA <NUM> followed by a truncation operation), which can reduce consumed bandwidth and battery life for mobile devices in sending requests <NUM>, and memory required to store attestation tokens <NUM>. As some entities may store attestation tokens <NUM> for many, e.g., thousands or millions, of users, this can result in substantial data storage savings.

The encrypted consent element <NUM> can also include a digital signature of the other data of the encrypted consent element <NUM>. For example, the encrypted consent element <NUM> can include a digital signature of the user identifier, the payload, and the third-party cookie of the entity if the cookie is included in the encrypted consent element <NUM>. The web browser can generate the digital signature for the encrypted consent element <NUM> for a third-party entity using the private key that corresponds to the public key used as the user identifier.

The web browser <NUM> can generate the encrypted consent element <NUM> for each entity by encrypting the data and digital signature for each entity. For a particular entity, the web browser <NUM> can generate a consent element that includes the user identifier, the payload for the entity, and optionally the third-party cookie for the entity. The web browser <NUM> can generate the digital signature of this data using the private key that corresponds to the public key used as the user identifier. The web browser <NUM> can then encrypt the consent element for the entity using a public key created and published by the entity. The web browser <NUM> can retrieve, from each third-party entity's website, the third-party public key for that entity after the entity generates the public/private key pair. The entity can maintain the private key confidentially so that the entity is the only one that can decrypt its encrypted consent element <NUM>. In some implementations, this encryption uses the digital signature <NUM> of the other data of the set of data <NUM> of the attestation token <NUM> as the encryption Initialization Vector (IV).

The attestation token <NUM> sent by the web browser <NUM> when presenting a resource of a particular domain can include the set of data <NUM> that includes the user identifier (e.g., the domain public key), the attestation token creation time, the payload, and the integrity token. The attestation token <NUM> also includes a digital signature <NUM> of the set of data <NUM> that is generated using the domain private key 118A that corresponds to the domain public key 118B for the particular domain. The attestation token <NUM> can also include, for each third-party entity that has a third-party cookie at the client device <NUM> or a portion thereof, an encrypted consent element for that third-party entity.

In some implementations, attestation tokens <NUM> sent by native applications <NUM> can include encrypted consent elements <NUM>, similar to the attestation tokens <NUM> sent by the web browser <NUM>. In some implementations, the web browser <NUM> can send requests <NUM> without encrypted consent elements <NUM>. For example, if user consent data is only updated for one entity, the web browser <NUM> can send the user consent data for that one entity in the payload or otherwise in unencrypted form. In some implementations, the encrypted consent elements <NUM> are included in attestation tokens <NUM> when the attestation token <NUM> is being sent to multiple entities, e.g., either by the web browser <NUM> or the native application <NUM>.

The client device <NUM> can send the requests <NUM> generated by the web browser <NUM> and the native applications <NUM> to one or more recipient entities. The native applications <NUM> can send a respective request <NUM> to each entity as the payload of the attestation tokens <NUM> generated for the native applications can be specific to each entity, as described above. Each entity can verify the integrity of the request <NUM> by verifying the digital signature <NUM> using the device public key 113B in the attestation token <NUM>. This verification can also include verifying the integrity of the client device <NUM> using the device integrity token.

The web browser <NUM> can send the request to multiple entities or to the digital component distribution system <NUM>, which can send corresponding requests to other entities such as the digital component partner <NUM> and the digital component providers <NUM>. These entities can verify the integrity of the requests by verifying the digital signature <NUM> and verifying the integrity of the client device <NUM> and/or the web browser <NUM> using the integrity token(s). Each entity can also decrypt its encrypted consent element <NUM> using its confidential private key to access the payload sent to that entity.

In either case, if the request <NUM> is verified, the entity can perform an action in response to the request. If the request is to change the user consent settings for the user with respect to the entity, the entity can comply with the request. For example, if the user changed the settings such that the entity cannot collect the user's data, the entity can comply by deleting the user's data. If the user changed the settings to only use the user's data to perform one or more particular actions, the entity can only use the user's data for those actions after receiving the request <NUM>.

If the request <NUM> is for a digital component, the entity can select one or more digital components based on the payload and in accordance with the user's consent settings for that entity. For example, if the user has consented to the entity using the user's data for selecting a digital component, the entity can select a digital component using the user's data to which the entity has access, e.g., in combination with the data in the payload and/or the request <NUM>. If the user has not consented to the entity using the user's data for selecting a digital component, the entity can select a digital component based on the data in the payload and/or the request <NUM> that is not specific to the user.

In some implementations, the user consent settings are sent with each request <NUM>, even if the request is for a digital component <NUM>. In this way, the entities can verify the current user consent settings and store the user consent settings with the request so that the entity can verify the user consent settings, if necessary. By including the user identifier, the user data (e.g., a cookie with the user's data), and the user consent settings together in a digitally signed request, the integrity of the user consent settings for that entity and that request can be technically verified.

Each entity can store user consent settings received from users. The entities can also store the user data to which the users have consented. For example, the digital component distribution system <NUM> includes a user data storage unit <NUM> for storing user data and a user consent data storage unit <NUM> for storing the user consent settings for the user. The digital component partner <NUM>, the digital component providers <NUM>, and/or other entities can include similar data storage units.

The entities can store the user consent settings in a manner that is technically verifiable. For example, the entities can store, for each user, the attestation tokens <NUM> that include the user consent settings for the user. As the attestation tokens <NUM> include digital signatures of the user identifier, the user consent settings, and an expiration date for the user consent settings, the user consent settings for each point in time can be verified. The digital signature of this data ensures that the data cannot be modified by the entity or another party.

The auditing system <NUM> can audit entities to ensure that the entities are storing and using the user data of the users in accordance with the user consent settings. The auditing system <NUM> can be maintained by an independent third-party, such as an industry or regulatory body. The auditing system <NUM> can check the digital signatures of the attestation tokens <NUM> for each user record maintained by an entity. The audit system <NUM> can also compare the user data of each record against the user consent to ensure that the entity has been given proper consent to store such data. Such auditing can occur periodically or randomly.

As described above, a web browser <NUM> or native application <NUM> can send attestation tokens <NUM> with user consent settings periodically to ensure that the previous user consent settings do not expire. In some implementations, the web browser <NUM> or native application <NUM> can require a confirmation response from the entity in response to receiving the attestation token <NUM> each time the entity receives an attestation token <NUM> from the client device <NUM>, including in non-periodic requests for digital components. The confirmation can be stored at the client device <NUM> and/or sent to the auditing system <NUM>. In this way, the auditing system <NUM> can verify that the entity received the user consent settings and prevent entities from fraudulently deleting user consent settings. For example, if the entity confirms that it received a request to delete the user's data then the entity deletes the request while maintaining the user's data, the confirmation can be used to show that the entity did receive the request but failed to comply with the request. If the confirmation is not received, the web browser <NUM> or native application <NUM> an issue an alert, e.g., to the auditing system <NUM>.

In some implementations, some requests <NUM> can be sent without user consent settings, e.g., without an attestation token <NUM>. For example, the web browser <NUM> or native application <NUM> can send a digital component request that includes the user identifier (e.g., a public key) and the payload for the digital component request. The entities that receive the request can use the user identifier to store the data with the appropriate user. The attestation token(s) received from the client device <NUM> in previous requests can be used to verify the user consent settings at the time of the requests that do not have user consent settings.

In some implementations, the auditing system <NUM> can evaluate user data stored by each entity (e.g., the digital component distribution system <NUM>, each digital component partner <NUM>, each digital component provider <NUM>, and/or each publisher <NUM>) that receives user data to ensure that the entities are storing and/or using the user data in accordance with each user's user consent settings. This evaluation also includes verifying the signatures of the attestation tokens and/or the encrypted consent elements that include the user consent settings. As the public keys that are used to verify the digital signatures are included in the attestation tokens, the auditing system <NUM> can access the public keys and use the public keys to verify the signatures of the attestation tokens and the encrypted consent elements. If a digital signature cannot be verified, then the content of the attestation token or the encrypted consent element has been modified, e.g., fraudulently.

<FIG> is a flow diagram that illustrates an example process <NUM> for updating user consent settings. The process <NUM> can be implemented, for example, by a recipient of a request to update a user's user consent settings, such as a publisher <NUM>, a digital component distribution system <NUM>, a digital component partner <NUM>, or a digital component provider <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on non-transitory computer readable media, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

Updated user consent data is received (<NUM>). The updated user consent data can be received by a web browser or native application running on a client device. For example, the web browser or native application can present a user interface that enables the user to configure, e.g., select or input, user consent settings for one or more entities. The updated user consent data can include updated user consent settings that define whether the user's data can be collected or maintained by other entities, what data is collected, and/or how their data is used by the entities. As described above, the user consent settings can be included in an attestation token.

An attestation token is generated (<NUM>). As described above, a web browser, operating system, or other trusted program of a client device can generate an attestation token. The attestation token can include a set of data that includes the updated user consent data. The set of data can also include a user identifier (e.g., a public key), an attestation token creation time, a payload, an integrity token (e.g., a device integrity token). The attestation token can also include a digital signature of the set of data. The digital signature of the set of data can be generated using a private key that corresponds to the public key that serves as the user identifier.

For situations in which the user consent data is updated using a native application, a respective attestation token can be generated for each entity that will receive updated user consent data. The user consent data for each entity can be included in the payload of the attestation token generated for that entity.

For situations in which the user consent data is updated using a web browser, the attestation token can include an encrypted consent element for each entity. As described above, the encrypted consent element for an entity can include the user consent data for that entity and can be encrypted using a public key obtained, e.g., fetched, from the entity. In this way, the same attestation token can be sent to multiple entities, but each entity can only decrypt the encrypted consent element for that entity as that entity is the only entity with the private key that can decrypt its encrypted consent element. This ensures that no other entity can access the user consent settings for other entities and that entities cannot track other entities.

The attestation token(s) are sent to one or more entities (<NUM>). For example, if the user updated the user consent data using a native application, the native application can send a respective attestation token to each entity for which an attestation token was generated. If the user updated the user consent data using a web browser, the web browser can send the same attestation token with multiple encrypted consent elements to multiple entities.

A determination is made, for each entity, whether confirmation is received from the entity (<NUM>). For example, each entity can be required to confirm receipt of updated user consent data for each user. The web browser or native application that sends the attestation token to an entity can monitor for confirmation from that entity. If the confirmation is not received within a specified time duration, the web browser or native application can request confirmation one or more times.

If confirmation is not received from an entity, an alert can be generated (<NUM>). For example, the web browser or native application that sent the attestation token can generate and send an alert to an auditing system in response to determining that confirmation was not received from an entity, e.g., after a specified time duration. The alert can specify the entity that did not confirm receipt of the attestation token. In some implementations, the alert can include the attestation token sent to the entity. An auditor that maintains the auditing system can follow up with the entity in response to the alert, e.g., to confirm that the entity is in compliance with the updated user consent settings.

If confirmation is received, the confirmation is stored (<NUM>). The confirmation can be stored at the client device and/or sent to an auditing system for storage. In this way, the confirmation can be used to audit the entity from which the confirmation was received, if appropriate.

<FIG> is a flow diagram that illustrates an example process <NUM> for validating the integrity of a request and performing an action in response to the request. The process <NUM> can be implemented, for example, by a recipient of the request, such as a publisher <NUM>, a digital component distribution system <NUM>, a digital component partner <NUM>, or a digital component provider <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on non-transitory computer readable media, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

A request is received (<NUM>). The request can include an attestation token. As described above, the attestation token can include a payload that specifies an operation of the request. In another example, the request can specify the operation of the request and include the attestation token for verification and/or security purposes.

A determination is made whether the integrity of the request is valid (<NUM>). The integrity of the request can be invalid if any data in the set of data changed between the time at which the attestation token was created, a duration of time between the token creation time and the time at which the request was received exceeds a threshold, the integrity token is invalid, or the attestation token does not include an encrypted consent element of the recipient. Example processes for determining whether the integrity of a request is valid are illustrated in <FIG> and described below.

If the integrity of the request is not valid, the request is ignored (<NUM>). For example, the entity that receives the request can delete the request and/or not respond to the request. The entity can also send a response to the client device that specifies that the request was not valid. In this way, the client device can retry the request as the previous request may have been fraudulently tampered with during transmission to the entity.

If the request is to update user consent settings, the entity that receives the request can determine to not change the user consent settings for the user identifier included in the attestation token in response to determining that the request is invalid. If the request is for a digital component, the entity may not provide a digital component in response to the request.

If the integrity of the request is valid, an action is performed in response to the request (<NUM>). The computer system can extract the operation to be performed from the attestation token to determine the operation to perform. For example, the computer system can extract the operation from the payload of the attestation token. In another example, the computer system can decrypt the encrypted consent element for the entity using the private key of the entity, as described below with reference to <FIG> and <FIG>. The computer system can then extract the operation from the decrypted consent element.

If the operation specified by the request is to update user consent settings for the user identifier included in the attestation token, the entity can update the user consent settings for the user identifier. In a particular example, if the updated user consent settings indicate that the user's data is to be deleted, the entity can delete the user's data in order to comply with the updated user consent settings. For user consent setting updates, the entity can also store the attestation token for verification purposes, as described above.

If the operation specified by the request is requesting a digital component, the entity can select a digital component, e.g., based on information included in the request or the payload and/or stored user data to the extent the user's consent settings allow. The entity can then provide the digital component to the client device for presentation to the user.

<FIG> is a flow diagram that illustrates an example process <NUM> for determining whether the integrity of a request is valid using an attestation token. The process <NUM> can be implemented, for example, by a recipient of the request, such as a publisher <NUM>, a digital component distribution system <NUM>, a digital component partner <NUM>, or a digital component provider <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on non-transitory computer readable media, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

An attestation token is accessed (<NUM>). The attestation token can be included with a request received from a web browser or native application. In another example, the attestation token can serve as the request. As described above, the attestation token includes a set of data, a digital signature of the set of data, and optionally one or more encrypted consent elements. The set of data can include a payload (e.g., an operation and data related to the operation), an attestation token creation time that indicates a time at which the attestation token was created, and an integrity token, e.g., a device integrity token.

The set of data can also include a user identifier for the user. The user identifier can be in the form of a public key. For example, the user identifier can be a device public key of the client device, a domain public key generated for the first-party domain of the resource for which the request is sent (e.g., in response to the web browser navigating to the first-party domain and loading a resource from the first-party domain), or a third-party public key for the recipient of the request.

A determination is made whether the token creation time is within a threshold time duration of a time at which the request was received or within a threshold time duration of a current time (<NUM>). For example, a determination can be made of the difference between the time at which the request was received (or the current time) and the token creation time. If the difference is less than or equal to the threshold time duration, the token creation time is within the threshold time duration. If the token creation time is not within the threshold time duration, e.g., meaning that the request is old, the integrity of the request can be classified at invalid (<NUM>).

In addition, the combination of token creation time and the public key in the attestation token may uniquely identify the attestation token and request carrying the token. The recipient can rely on the combination to recognize duplicate request or potential replay attack.

If the token creation time is within the threshold time duration, e.g., meaning that the request is new or recent, a determination is made whether data in the set of data of the attestation token has been modified after the digital signature of the attestation token was generated (<NUM>). For example, the public key of the attestation token can be used to verify the digital signature of the attestation token. If the signature cannot be verified using the public key, a determination is made than the data in the set of data has been modified. For example, such data may have been modified by an entity that intercepted the request or an intermediary. If the digital signature is verified using the public key, a determination is made that the data in the set of data of the attestation token has not been modified.

If a determination is made that the data in the set of data has been modified, the integrity of the request is classified as being invalid (<NUM>). If a determination is made that the data in the set of data of the attestation token has not been modified, a determination is made whether the integrity token is valid (<NUM>). The integrity token can be a device integrity token. This determination can include determining whether the verdict of the device integrity token indicates that the client device is valid. If the verdict is invalid, a determination is made that the device integrity token is invalid and the integrity of the request is classified as invalid. If the verdict is valid, a determination can be made that the device integrity token in valid.

This determination can also include verifying the digital signature of the device integrity token. As described above, the device integrity system can digitally sign the data of the device integrity token using a private key of the device integrity system. The device integrity system can provide a public key that corresponds to this private key to recipients that may receive device integrity tokens generated by the device integrity system. Each recipient of the request can use this public key to verify the signature of the device integrity token which, if successful, indicates that the data of the device integrity token has not been modified since it was created. In this example, if the verdict is valid and the digital signature of the device integrity token is verified successfully, a determination can be made that the device integrity token in valid.

For attestation tokens that do not include encrypted consent elements or even user consent settings, the request would be considered valid if it has been determined that the attestation token creation time is within the threshold, the data of the attestation token has not been modified, and the integrity token is valid. For attestation tokens that include encrypted consent elements, optional operation <NUM> can be used to ensure that the request is valid.

In operation <NUM>, a determination is made whether the attestation token includes the recipient's encrypted consent element. As described above, the attestation token can include, for each of one or more of the recipients of the request, an encrypted consent element. The encrypted consent element for a recipient can include an encrypted version of a set of data that has been encrypted using a public key of the recipient. This set of data can include a payload that includes the user consent settings for the recipient, the same public key as the attestation token (or a hash or other derivative thereof), optionally a third-party cookie of the recipient that has been stored on the client device, and a digital signature of the rest of the set of data. This digital signature can be generated using the same public key included in the encrypted consent element and the attestation token. Example processes for determining whether an attestation token includes a recipient's encrypted consent element are illustrated in <FIG> and <FIG> and described below.

In some implementations, if the attestation token includes the recipient's encrypted consent element, the integrity of the request can be classified as valid (<NUM>). If not, the integrity of the request can be classified as invalid. Consent elements for entities do not always need to be encrypted. For example, in some implementations, when user changes consent, the web browser, native application or the operating system of the device may send a dedicated request to one entity over Hypertext Transfer Protocol Secure (HTTPS). Within the request, the attestation token carries the user consent element applicable only to the entity.

<FIG> and <FIG> illustrate processes for determining the integrity of requests that include encrypted consent elements for entities. If the encrypted consent element for a recipient only contains the recipient's encrypted consent element, the encryption result is stable. Intermediaries or others that may gain access to the requests can rely on the encrypted consent element as a stable identifier to track a user. To prevent such tracking, randomness can be introduced to the encryption process such that the encryption consent element for a given recipient and a given client device is specific to each request. The processes <NUM> and <NUM> are two example ways of introducing such randomness.

<FIG> is a flow diagram that illustrates another example process <NUM> for determining whether the integrity of a request is valid using an attestation token. The process <NUM> can be implemented, for example, by a recipient of the request, such as a publisher <NUM>, a digital component distribution system <NUM>, a digital component partner <NUM>, or a digital component provider <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on non-transitory computer readable media, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

In this example process <NUM>, a request includes an attestation token that has a group of encrypted consent elements, e.g., one for each of multiple recipients. The encrypted consent element for each recipient is an encrypted version of a combination of the recipient's consent element (e.g., the public key, the payload, and the optional third-party cookie) and a cryptographic hash of the digital signature of the set of data included in the attestation token. That is, the web browser that sends the request can use a given recipient's public key to encrypt a combination of the recipient's consent element and the cryptographic hash of the digital signature. The cryptographic hash of the digital signature for each recipient can be calculated by applying a cryptographic algorithm or hash function, e.g., SHA256, over the digital signature. This cryptographic hash introduces the randomness that makes the encrypted consent element specific to each request and also cryptographically binds the encrypted consent element to the rest of the attestation token.

A cryptographic hash of a digital signature of a set of data in an attestation token of a request is calculated (<NUM>). The cryptographic hash of the digital signature can be calculated using a cryptographic hash algorithm adopted by the browser, operating system, or other trusted program.

A first encrypted consent element in the group of encrypted consent elements is accessed (<NUM>). In this example, each encrypted consent element is accessed one by one. In other implementations, multiple encrypted consent elements can be accessed and processed in parallel, e.g., using multiple threads or multiple processors.

The encrypted consent element is decrypted (<NUM>). The encrypted consent element can be decrypted using the recipient's private key that corresponds to the recipient's public key used to encrypt its consent element.

A determination is made whether the decrypted consent element includes a portion that matches the cryptographic hash of the digital signature calculated in operation <NUM> (<NUM>). For example, the cryptographic hash of the digital signature can be compared to the decrypted consent element to determine whether there is a match between the cryptographic hash and a portion of the decrypted consent element.

If there is no match, a determination is made whether the currently accessed consent element is the last encrypted consent element included in the group (<NUM>). If the currently accessed consent element is not the last encrypted consent element in the group, the next encrypted consent element is accessed (<NUM>). Operations <NUM> and <NUM> are then performed on this consent element.

For each decrypted consent element that includes a portion that matches the cryptographic hash of the digital signature, a determination can be made whether the decrypted consent element includes a portion that matches a cookie identifier of the recipient. For example, the recipient can perform a lookup operation on its stored user data using the data in the encrypted consent element to determine if there is a match to a stored cookie identifier in the user data. If so, the recipient can determine that the cookie in the consent element is for that cookie identifier. If not, the recipient can store the new cookie identifier and start collecting user data using the cookie identifier in accordance with the user consent settings for the user.

If a decrypted consent element includes a portion that matches the cryptographic hash of the digital signature in operation <NUM>, the request is classified as valid (<NUM>). If none of the decrypted consent elements include a portion that matches the cryptographic hash of the digital signature in operation <NUM>, the request is classified as invalid (<NUM>).

In this example process <NUM>, a request includes an attestation token that has a group of encrypted consent elements, e.g., one for each of multiple recipients. The encrypted consent element for each recipient is an encrypted version of the recipient's consent element using the digital signature, or the cryptographic hash of the digital signature, of the set of data included in the attestation token as an encryption initialization vector. The use of the encryption initialization vector introduces the randomness that makes the encrypted consent element specific to each request and also cryptographically binds the encrypted consent element to the rest of the attestation token.

A cryptohash of a digital signature of a set of data in an attestation token of a request is calculated (<NUM>). The cryptohash of the digital signature can be calculated using the same cryptographic hash algorithm adopted by the browser.

A first encrypted consent element in the group of encrypted consent elements is accessed (<NUM>). In this example, each encrypted consent element is accessed one by one. In other implementations, multiple cookie elements can be accessed and processed in parallel, e.g., using multiple threads or multiple processors.

The encrypted consent element is decrypted (<NUM>). The encrypted consent element can be decrypted using the recipient's private key that corresponds to the recipient's public key used to encrypt its consent element and the digital signature, or the cryptographic hash of the digital signature, included in the attestation token as the encryption initialization vector.

A determination is made whether the decrypted consent element matches an identifier of the recipient (<NUM>). If not, a determination is made whether the currently accessed consent element is the last encrypted consent element included in the group (<NUM>). If the currently accessed consent element is not the last encrypted consent element in the group, the next encrypted consent element is accessed (<NUM>). Operations <NUM> and <NUM> are then performed on this consent element.

If a decrypted consent element matches a valid identifier of the recipient, the request is classified as valid (<NUM>). If none of the decrypted consent elements match a valid consent identifier of the recipient, the request is classified as invalid (<NUM>).

<FIG> is a block diagram of an example computer system <NUM> that can be used to perform operations described above. The system <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, and an input/output device <NUM>. Each of the components <NUM>, <NUM>, <NUM>, and <NUM> can be interconnected, for example, using a system bus <NUM>. The processor <NUM> is capable of processing instructions for execution within the system <NUM>. In some implementations, the processor <NUM> is a single-threaded processor. In another implementation, the processor <NUM> is a multi-threaded processor. The processor <NUM> is capable of processing instructions stored in the memory <NUM> or on the storage device <NUM>.

Although an example processing system has been described in <FIG>, implementations of the subject matter and the functional operations described in this specification can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification, or in combinations of one or more of them.

Embodiments of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification, or in combinations of one or more of them.

Claim 1:
A computer-implemented method comprising:
receiving, from a client device (<NUM>), a request (<NUM>) including an attestation token (<NUM>), the attestation token (<NUM>) including:
a set of data (<NUM>) that includes at least:
a user identifier that uniquely identifies a user of the client device (<NUM>);
a token creation time that indicates a time at which the attestation token (<NUM>) was created;
user consent data specifying whether one or more entities that receive the attestation token (<NUM>) are eligible to use data of the user; and
an action to be performed in response to the request; and
a digital signature (<NUM>) of at least a portion of the set of data (<NUM>), including at least the user identifier and the token creation time; and
verifying an integrity of the request (<NUM>) using the attestation token (<NUM>), including:
determining whether the token creation time is within a threshold duration of a time at which the request (<NUM>) was received;
determining, using the digital signature (<NUM>), whether the set of data (<NUM>) was modified after the attestation token (<NUM>) was created; and
determining that the integrity of the request (<NUM>) is valid based at least on determination that the token creation time is within the threshold duration of the time at which the request (<NUM>) was received and a determination that the set of data (<NUM>) has not been modified since the attestation token (<NUM>) was created; and
performing the action in response to determining that the integrity of the request (<NUM>) is valid, wherein performing the action comprises:
determining that the user consent data specifies one or more authorized actions that are authorized by the user to be performed by a given entity using the data of the user; and
preventing the given entity from using the data of the user for actions other than the specified one or more authorized actions.