Secure network communications with restricted access to information

Abstract

The present disclosure describes systems and techniques for controlling access to user information using transient user identifiers. In one aspect, a method includes determining, for a given domain, a user's engagement with content provided by the given domain for display by an application at a client device of the user. Based on the user's engagement, a link between a user identifier of a user extending the application for the given domain is determined. In response to determining a link between the user identifier of the user extending the application for the given domain, one or more future domain-specific transient user identifiers for the user and the given domain are obtained. An attestation record including a current domain-specific transient user identifier and one or more future domain-specific user identifiers is generated, and the attestation record is sent to the given domain.

Description

Technical Field

[0001] This note deals with data security and encryption. Background Art

[0002] Client devices transmit requests and other data over public networks such as the Internet. These communications can be altered by other parties, such as parties that intercept the communications and / or intermediaries that receive the communications and forward them to other parties. Client devices are also vulnerable to malicious attacks, such as viruses and malware, which can send fraudulent requests without the user's knowledge or authorization. In addition, other parties can impersonate client devices to send requests that appear to originate from the client device but are actually from other parties' devices. Summary of the invention

[0003] In general, an innovative aspect of the subject matter described in this specification can be embodied in a method, the method comprising determining, for a given domain, a user's engagement with content provided by the given domain for display by an application at a user's client device. Determine a link between user identifiers of users who extend the application for the given domain based on the user's engagement. In response to determining a link between user identifiers of users who extend the application for the given domain, obtain one or more future domain-specific transient user identifiers for the user and the given domain. Each future domain-specific transient user identifier is a user identifier that the application will use during a future time period after the current time period has passed to identify the user to the given domain. Generate a certification record. The certification record includes: a data set including payload data, a digital signature of the data set, a current domain-specific transient user identifier for the user and the given domain, and one or more future domain-specific transient user identifiers for the user and the given domain. Send the certification record to the given domain. Other embodiments of this aspect include corresponding apparatus, systems, and computer programs encoded on a computer storage device configured to perform aspects of the method.

[0004] These and other embodiments can each optionally include one or more of the following features. In some aspects, the data set includes a timestamp indicating the time when the attestation record was generated and a signed redemption record. The payload data can include a user and one or more future domain-specific user identifiers for a given domain.

[0005] In some aspects, the user's engagement includes a level of user engagement with content provided by a given domain for display by an application at a client device of the user. Some aspects can include selecting a number of users and one or more future domain-specific user identifiers for a given domain based on the user's engagement level for the given domain.

[0006] In some aspects, the current domain-specific user identifier and one of the plurality of future domain-specific user identifiers are encrypted using an encryption key for the given domain. In some aspects, for each domain in the plurality of domains including the given domain, the attestation record includes a corresponding current user identifier for the domain.

[0007] In some aspects, the current domain-specific ephemeral user identifier for the user and the given domain includes the current public key for the user and the given domain. Each of the one or more future domain-specific user identifiers includes a future public key for the user and the given domain.

[0008] In some aspects, the given domain is a domain of a publisher of electronic resources.Determining, for the given domain, user engagement of a user with content provided by the given domain for display by an application at a user's client device can include determining a user engagement level based on the user navigating to the publisher's electronic resources.

[0009] In some aspects, the given domain is a domain of a content platform that distributes the digital component or a domain of a content platform that facilitates distribution of the digital component by another content platform. Determining, for the given domain, a user's engagement with content provided by the given domain for display by an application at a user's client device can include determining a user engagement level based on the content platform providing one or more digital components for presentation at the client device.

[0010] In some aspects, the given domain is a domain of a digital component provider that creates digital components that include content of the digital component provider. Determining, for the given domain, user engagement with content provided by the given domain for display by an application at a user's client device can include determining a user engagement level based on user interactions with a digital component created by the digital component provider.

[0011] Content providers can use user identifiers associated with users to provide customized content to users, for example, so that the content provided is more beneficial to users than non-customized content. For example, such content providers can use user identifiers to collect information about users over time. However, some entities can use stable identifiers to collect user data without providing any benefits to users. In order to prevent such collection of user data and improve user data security, the user identifier of the user can be changed regularly. However, such changes of content providers that provide customized content to users can suddenly reduce the benefits of users, because each time the user identifier is changed, the content provider will have to restart the process of collecting user information. In fact, when the user identifier is changed, any system that utilizes the ability to identify users over an extended period of time can suffer a negative impact, because the system then needs to collect data from the user again and loses any historical knowledge of the interaction of the user with at least some elements of the system. The regular change of the user identifier can therefore increase the amount of data transmission across the network due to the re-collection of the data previously obtained about the user, and prevent certain functionality that depends on the ability of the previous user of the identification system / service.

[0012] The technology described in this document enables content providers that contribute to selecting content for a user or from which a user has requested content to link multiple user identifiers of a user, so that even when the user identifier is changed, these content providers can also maintain user information across multiple user identifiers. The technology described in this document also enables data or service providers that provide data / content to a user or from which a user has requested data / content to link multiple user identifiers of a user, so that these data providers can also maintain user information across multiple user identifiers even when the user identifier is changed. For example, an application (e.g., a web browser) can provide a content provider that contributes to selecting content for a user with a current user identifier of the user and one or more future user identifiers that the application will use during a future time period to identify the user. In this way, the content provider can relate future communications including future user identifiers to the current user identifier, and continue to accumulate information about the user across multiple user identifiers of the user.

[0013] The subject matter described in this specification can be implemented in certain embodiments to achieve one or more of the following advantages. By selectively providing user identifier linkability only to entities that have contributed in some active way, the availability of user information for each user is greatly limited across the online ecosystem, while still enabling content providers that have actively contributed to provide beneficial content to users. These techniques prevent entities that would normally passively collect such information (e.g., to sell to other entities) from being able to relate to the user information of the user over a long period of time. Instead, these entities would have to start over each time a new user identifier is assigned to a user, resulting in minimal user information for each user.

[0014] User identifiers can be domain-specific and encrypted for each domain, so that only a single domain can use a given user identifier to be associated with data received in multiple communications with the same user. In this way, applications can selectively link user identifiers of domains that have made positive contributions, while preventing such links from being used for domains that have not made contributions. This also enables applications to provide user identifiers for multiple recipients in the same communication, thereby reducing the number of communications transmitted over the network and the amount of network bandwidth consumed. In addition, by selectively providing user identifier linkability to specific domains, the use of stable long-term user identifiers is avoided. This improves user data security and privacy because the temporary nature of user identifiers prevents malicious third parties from tracking or otherwise exploiting potentially sensitive data of specific users due to periodic changes in user identifiers. Current and future user identifiers can be encrypted and provided to dedicated intended domains, thereby greatly minimizing the risk of data theft and other security risks from malicious third parties.

[0015] The user identifier can be in the form of a public key. In order to reduce the data size of the user identifier, the user identifier can be an encrypted hash of the public key, and the encrypted hash can be truncated to a specific length or data size. This reduces the data storage requirements of the content provider that can store many user identifiers of each user for linking purposes. This also reduces the data size of the communication including the user identifier, resulting in faster data transmission, less network bandwidth consumption and less battery consumption when generating communications. Added up on thousands or millions of users, these savings are huge.

[0016] The use of transient user identifiers with linkability enables applications (e.g., browsers) to block domains not directly involved in providing personalized content from tracking users over extended periods of time, while still enabling contributing publishers to identify users to infer their interests and store their preferences, and enabling contributing content platforms to collect such information across multiple publisher domains. Transient identifiers support these features while giving application developers (e.g., browser developers) control over the lifespan of transient identifiers and the degree of linkability per domain, enabling application developers to implement solutions that protect user privacy while enabling customized content that improves the user experience. The ability to block certain domains through the use of transient user identifiers provides a further security benefit because malicious domains can be prevented from obtaining the current user identifier.

[0017] Transmitting data from a client device using an attestation record (e.g., an attestation token) provides a secure communication channel between the client device and a recipient's computer or other device. Including a digital signature generated based on data included in the attestation record in the attestation record enables the recipient to verify that the data in the attestation record has not been modified after the attestation record was created (e.g., during transmission between the client device and the recipient). Including the token creation time in the attestation record enables the recipient to detect replay attacks and / or forged data transmissions.

[0018] Various features and advantages of the foregoing subject matter are described below with reference to the accompanying drawings. Additional features and advantages will be apparent from the subject matter described herein and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is a block diagram of an environment in which an application links user identifiers for domains that contribute to the selection of content displayed at a client device.

[0020] Figure 2 is a flow diagram of an example process for sending an attestation record that enables linking a user identifier for a domain.

[0021] Figure 3 is a flow chart of an example process for linking a user identifier for a domain.

[0022] Figure 4 is a block diagram of an example computer system.

[0023] Like reference numbers and names in the various drawings refer to like elements. DETAILED DESCRIPTION

[0024] In general, this document describes systems and techniques for controlling access to user information using transient user identifiers. An application (e.g., a web browser) can send communications to various domains. Communications sent to a domain can include transient user identifiers of users using the application and the domain. That is, the transient user identifier can be used by the domain to identify the user and be associated with information included in multiple communications with the user. The application can use each transient user identifier for a given period of time, and once the period of time has passed, a different transient user identifier is used for the user and the domain. The given period of time can be one hour, two hours, one day, one week, or another appropriate period of time.

[0025] In order to enable some domains to relate user information to users over a period of time longer than a given period of time, the application can enable these recipients to link multiple user identifiers of the same user. To this end, the application can send both the current user identifier of the user and one or more future user identifiers of the user to the domain. The future user identifiers can be transient user identifiers, each of which will be used by the application in a corresponding future time period occurring after the current time period. For example, assume that the time period for each transient user identifier is one day. During the day when the current user identifier is being used to identify the user to the domain, the application can also send the user identifier to be used the next day to the domain. In this way, the domain can link the two user identifiers and relate the information received in the communication including the current user identifier to the information received in the communication including the user identifier of the next day.

[0026] The application can provide future user identifiers to specific domains, such as those or other specific domains that contributed to the selection of content displayed at the user's client device, while not providing future user identifiers to certain other domains that did not contribute to the selection of content displayed at the client device or were otherwise deemed inappropriate / malicious. This selectively controls which domains can be associated with user information over a longer period of time, such as to establish a user profile that can be used to customize or provide certain content / data / functionality to the user, which reduces the number of domains with user information and better protects user privacy.

[0027] Figure 11 is a block diagram of an environment 100 in which an application 112 is a domain-linked user identifier that contributes to the selection of content displayed at a client device 110. The example environment 100 includes a data communication network 105, such as a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof. The network 105 connects the client devices 110, the content platforms 150, the websites 140, the publishers 130, and the trust token issuer system 180. The environment 100 can include many client devices 110, content platforms 150, websites 140, publishers 130, and trust token issuer systems 180.

[0028] A website 140 is one or more resources 145 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 140 is maintained by a publisher 130, which is an entity that controls, manages, and / or owns the website 140.

[0029] Resources 145 are any data that can be provided over network 105. Resources 145 are identified by a resource address (e.g., a uniform resource locator (URL)) associated with resource 145. Resources include HTML pages, word processing documents and portable document format (PDF) documents, images, videos, and feeds, to name a few. Resources can include content, such as words, phrases, images, and sounds, which can include embedded information (such as meta information in a hyperlink) and / or embedded instructions (such as scripts).

[0030] The client device 110 is an electronic device capable of communicating via the network 105. Example client devices 110 include personal computers, mobile communication devices (e.g., smart phones), and other devices capable of sending and receiving data via the network 105. The client device can also include a digital assistant device that accepts audio input via a microphone and outputs audio output via a speaker. When the digital assistant detects a "hot word" or "hot phrase" that activates the microphone to accept audio input, the digital assistant can be placed in a listening mode (e.g., ready to accept audio input). The digital assistant device can also include a camera and / or a display to capture images and present information visually. The digital assistant can be implemented in different forms of hardware devices, including wearable devices (e.g., watches or glasses), smart phones, speaker devices, tablet devices, or another hardware device. The client device can also include a digital media device, such as a streaming device that is inserted into a television or other display to stream video to a television, a gaming system, or a virtual reality system.

[0031] Client devices 110 typically include applications 112, such as a web browser and / or native applications, to facilitate sending and receiving data over network 105. Native applications are applications developed for a specific platform or a specific device (eg, a mobile device with a specific operating system).

[0032] The client device 110 can also include a trusted program 111. The trusted program 111 can include trusted code from a reliable source that is difficult to forge. For example, the trusted program 111 can be an operating system, a part of an operating system, a web browser, etc. In general, the trusted program 111 is difficult to penetrate, and the time and effort required for a malicious actor to tamper with the trusted program 111 is prohibitively high, for example, it is not economically feasible for the malicious actor. In addition, because the trusted program 111 is provided and maintained by a reliable source, any vulnerabilities that arise can be resolved by the source.

[0033] Trusted program 111 can be local to client device 110. For example, trusted program 111 can be a device driver for an operating system of client device 110. In some embodiments, trusted program 111 operates entirely locally to client device 110, thereby reducing the need to transmit user information. In some embodiments, trusted program 111 can operate locally to client device 110 and over a network, such as network 105. For example, trusted program 111 can be a web browser installed on client device 110 and transmits and receives information over network 105. As described in more detail below, trusted program 111 can maintain encryption keys in secure key storage 113.

[0034] Some resources, application pages or other electronic content can include a digital component slot for presenting a digital component with a resource 145 or application page. 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, an audio clip, a multimedia clip, an image, a text, or another content unit). A digital component can be stored electronically in a physical memory device as a single file or a collection of files, and the digital component can take the form of a video file, an audio file, a multimedia file, an image file, or a text file, and include advertising information, so that an advertisement is a type of digital component. For example, a digital component can be content that is intended to supplement the content of a web page or other resource presented by an application 112. More specifically, a digital component can include digital content related to resource content (e.g., a digital component can relate to the same subject as the web page content, or relate to a related subject). Therefore, the provision of a digital component can supplement and generally enhance the web page or application content.

[0035] When application 112 loads a resource (or application content) that includes one or more digital component slots, application 112 can request a digital component for each slot. In some implementations, a digital component slot can include code (e.g., a script) that enables application 112 to request a digital component from a digital component distribution system that selects the digital component and provides the digital component to application 112 for display to a user of client device 110. Application 112 can request a digital component from one or more content platforms 150.

[0036] The content platform 150 can select and distribute digital components for display with web pages, native application content and / or other electronic resources or content. The content platform can include a supply-side platform (SSP) and / or a demand-side platform (DSP). Some publishers 130 use SSPs to manage the process of obtaining digital components for the digital component slots of their resources and / or applications. SSPs are technology platforms implemented in hardware and / or software that automate the process of obtaining digital components for resources and / or applications. Each publisher 130 can have a corresponding SSP or multiple SSPs. Some publishers 130 can use the same SSP.

[0037] A digital component provider 160 is capable of creating (or otherwise publishing) digital components that are displayed in digital component slots of a publisher's resources and applications. A digital component provider 160 is capable of using a DSP to manage the provision of its digital components for display in a digital component slot. A DSP is a technology platform implemented in hardware and / or software that automates the process of distributing digital components for display with resources and / or applications. A DSP is capable of interacting with multiple supply-side platforms SSPs on behalf of a digital component provider 160 to provide digital components for display with resources and / or applications of multiple different publishers 130. In general, a DSP is capable of receiving a request for a digital component (e.g., from an SSP), generating (or selecting) selection values ​​for one or more digital components created by one or more digital component providers based on the request, and providing data related to the digital component (e.g., the digital component itself) and selection parameters to the SSP. The selection value is capable of indicating the amount that a digital component provider 160 is willing to provide for display or user interaction of the digital component. The SSP can then select a digital component to display at the client device 110 and provide data to the client device 110 that causes the client device 110 to display the digital component.

[0038] Each publisher 140, content platform 150, and digital component provider 160 can be associated with a corresponding network domain (also referred to as a domain for brevity) identified by a domain name. A network domain is a group of one or more computers associated with the same infrastructure. For example, the domain of publisher 130 can include a web server that provides electronic resources (e.g., web pages) of publisher 130 to a browser in response to a request received from the browser.

[0039] When the client device 110 sends a communication 120 to a recipient (e.g., to a content platform 150 or a domain of a publisher 130 hosting a website), the client device 110 can send a certification record 122 with the communication 120, or send the communication 120 in the form of a certification record 122. The certification record 122 can be in the form of a certification token, which can be a composite message including a digital signature. The trusted program 111 can generate the certification record 122 for the communication 120 in response to a request from the application 112.

[0040] The attestation record 122 can include a data set 126 and a digital signature 128 of the data set 126. The data set 126 can include a public key, a timestamp, payload data, and / or a signed redemption record (SRR). The public key can be a public key embedded in or otherwise linked to the SRR (e.g., when the communication 120 is sent by a browser) or a device public key of the client device 110 (e.g., when the communication 120 is sent by a native application). In either case, the public key can have a corresponding private key that is cryptographically linked to the public key. The private key can be used to generate a digital signature for the data set, and the corresponding public key can be used to verify the signature using the data set. The public key can be used to encrypt the data set, and the corresponding private key can be used to decrypt the encrypted data set.

[0041] The timestamp indicates the time when the attestation record was generated. The timestamp can be a high-resolution timestamp, such as millisecond resolution. The payload data can vary based on the use case. For example, when communication 120 is used to request a digital component, the payload data can include context data related to the digital component slot for which the digital component is being requested. When communication 120 is used to report an event, the payload data can include data describing the event.

[0042] The trust token issuer system 180 is capable of issuing trust tokens and redeeming trust tokens to obtain SRRs. In order to issue a trust token to a client device 110, the trust token issuer system 180 is capable of evaluating a fraud detection signal received from the client device 110 to determine whether the client device 110 is trustworthy. If so, the trust token issuer system 180 is capable of issuing one or more trust tokens to the client device 110. The client device 110 is then capable of redeeming the trust tokens to obtain SRRs. Each SRR is capable of being used for an individual communication 120 and is capable of including a network location (e.g., a uniform resource locator (URL)) to which the communication 120 is being sent. The SRR is also capable of including: an encrypted hash of an application 112 or client device user identifier, which can be in the form of a public key; and a digital signature of a data set including at least an encrypted hash of a network location and a user identifier of the application 112 or client device. The digital signature can be generated using the private key of the trust token issuer system 180, enabling the recipient of the communication 120 to verify that the contents of the SRR have not been modified since being signed by the trust token issuer system 180, and enabling the recipient to confirm that the SRR was generated by the trust token issuer system 180. The SRR is an optional component of the attestation record. The SRR provides increased fraud / abuse detection capabilities by proving that the trust token issuer 180 has some knowledge about the application and / or device and considers the application and / or device to be trustworthy.

[0043] Trusted program 111 can generate a data structure, such as a composite message, including data set 126. Trusted program 111 can then generate a digital signature for data set 126 using a private key corresponding to an application or device public key included in the data set (e.g., a device private key corresponding to a device public key).

[0044] The attestation record 122 can also include one or more user identifiers 124 for users of the application 112. For example, for each recipient domain that will receive the communication 120, the attestation record 122 can include the current user identifier for the user and the domain. In order to prevent unintended domains from tracking users and selectively limit the ability of domains to track users, different user identifiers can be used for each domain. Each user identifier can be encrypted using the public key of the owner domain of the user identifier. In this way, only the intended domain can decrypt its user identifier for the user using its corresponding private key. When encrypting the user identifier, the application 112 or trusted program 111 can use the digital signature 128 of the attestation record as an initialization record for the encryption algorithm to cryptographically link the user identifier to the signature 128 and the attestation record 122 of the data.

[0045] In some implementations, the user identifier can be separated from the data set 126 that is signed to generate the digital signature 128. In this way, the user identifier can be separated from the certification record 122 without destroying the digital signature 128, e.g., without causing verification of the digital signature 128 to fail due to changes to the data set 126.

[0046] In some embodiments, each user identifier is in the form of a public key. Application 112 (or trusted program 111) can generate a public key and a private key pair for each of a plurality of domains that may be recipients of communications sent from application 112. Application 112 can use the public key generated for a domain as a user identifier that identifies the user to that domain. Although primarily described in the document as a user's public key, the public key used to identify the user can be a public key of application 112, a publisher of application 112, or a user's client device 110.

[0047] To control the ability of a domain to track a user over a long period of time, application 112 can periodically change (e.g., rotate) the user identifier. When application 112 changes the user identifier that identifies a user to a domain, subsequent communications sent by application 112 to the domain will include the new user identifier instead of the previous user identifier. If application 112 does not provide the ability to link two user identifiers to a domain, the domain will not be able to correlate the two user identifiers, and therefore will not be able to determine that the new user identifier is for the same user as the previous user identifier.

[0048] When a public key is used at the user identifier, the application 112 can make the public key for a domain available only to that domain. The application 112 can keep the private key corresponding to the public key strictly confidential, such as in the key storage 113, so that the application 112 can prove its ownership of the public key by signing outgoing communications with the private key, so that the digital signature can be verified using the public key and / or by using the private key to decrypt incoming communications encrypted using the public key.

[0049] Assume that the parameter "unit_of_time" represents the useful life of a short-lived public key used as a user identifier to identify a user to a domain. For each combination of a duration in a unit of time since a reference time and a domain name, the application 112 can create a public and private key pair for the domain using the duration and the domain name of each domain. For example, if the unit of time is one day, the application 112 can use a combination of the number of days since the reference time and the domain name of each domain to create a daily key pair for the domain. The duration can be represented as "unit_of_time_since_ref" and the owner domain name of the key can be represented as "owner_domain". In some embodiments, the reference time is an epoch time. The public key for a specific domain and a specific duration can be represented as PublicKey unit_of_time_since_ref,owner_domainSimilarly, the corresponding private key can be represented as PrivateKey unit_of_time_since_ref,owner_domain .

[0050] In some embodiments, the application 112 or a trusted program can generate a master private key for all domains. In some embodiments, the application 112 can use the Elliptic Curve Digital Signature Algorithm (ECDSA) and / or Diffie-Hellman Public Key (DHPK), which are cryptographic based on elliptic curve versions based on exponentiation (i.e., curve multiplication). Using such techniques, multiple keys can be concisely pseudo-randomly represented, each associated with a different domain, by exploiting the fact that the private key is a random element in a field.

[0051] Assume that the ephemeral private key X (where the corresponding public key is g x and is the private key X to the power of the base g in the group) and domain D, assuming that application 112 has a pseudo-random MAC key S. For domain D, assume that Yd=MAC(S,X||D), where MAC is a message authentication code. As used herein, the symbol || represents a composite message. Therefore, X||D is a composite message of key S and domain name D. If more bits are needed, two MAC keys S1 and S2 can be used. In this example, Yd=MAC(S1,X||D)||MAC(S2,X||D). In either example, the domain-specific private key of a domain is YD=MAP(Yd) for that domain. The ephemeral private key X is a master key used to generate domain-specific keys for various domains.

[0052] In particular, HMAC-SHA256 can be a pseudo-random MAC function, and the MAP function can take the generated string and map it into a shorter field. This mapping can be a modular simplification, starting with a 512-bit pseudo-random string output by the MAC function and reducing it modulo a 256-bit prime number, which gives a random-looking number in the field. This generates appropriate scalars for curve multiplication, such as mapping the extended string to the field to make the selection almost uniform. For example, Yd can be 512 bits, the field can be based on a 256-bit prime number (other numbers of bits can also be used), and the domain-specific private key Yd will be a pseudo-random element modulo a prime number of 256 bits in length.

[0053] Assuming the pseudo-random MAC key S is secure and is the key of a pseudo-random function, all domain keys are pseudo-randomly generated and appear as if they were randomly generated per domain. During the period of time during which the ephemeral private key X is valid, the corresponding public key of the domain can be g YD(For example, using modular exponentiation on number theoretic groups or curve multiplication on elliptic curve groups, g raised to the private key power.) When a new user identifier is generated for a user, the ephemeral private key X is changed (S may also be changed), and thus the domain specific key YD used as the user identifier will also be changed.

[0054] The application 112 can periodically change the user identifier for each domain based on a specified time period. For example, the application 112 can change the user identifier every hour, every two hours, every 12 hours, every day, every two days, every week, or based on another appropriate time period. Using the above master key example, the application 112 can generate a domain-specific key YD for each domain each time a time period passes. In some embodiments, the application 112 can generate a key when the key is to be changed or in a short period of time before the key is to be changed, rather than storing many keys for many different domains.

[0055] As referenced below Figure 2 As described, application 112 can enable a domain to link user identifiers across multiple time periods by providing one or more future user identifiers that application 112 will use to identify the user for the domain in one or more corresponding future time periods. In this case, attestation record 122 can include, for example, one or more future user identifiers for the domain encrypted with an encryption key for the domain, which is typically a public key for the domain. Similar to the current user identifier, the future user identifier can be included in the payload data of attestation record 122 or separate from the signed data set 126. The current domain-specific user identifier and one or more future domain-specific user identifiers for the domain can be encrypted together, for example as one encrypted element, or separately as individual encrypted user identifiers.

[0056] The application 112 can enable the user to reset all user identifiers for all domains or for users of a specific domain. For example, the application 112 can provide a user interface that enables the user to reset the user identifiers of the domains and / or block one or more domains from receiving any user identifiers. If the user chooses to reset the user identifiers of all domains, the application 112 can reset the ephemeral private key X and the HMAC key S. Alternatively, the application 112 can reset the user identifiers periodically by resetting the ephemeral private key X and the HMAC key S.

[0057] In some embodiments, it can be beneficial to offset the validity time periods of user identifiers for various domains so that all domains do not lose the ability to utilize data collected over multiple time periods simultaneously. To prevent this, each instance of the application 112 on the various client devices 110 can generate a random or pseudo-random floating point number, which can be represented as an "era_value", to start a new data collection era at a different time. An era can be the maximum duration in which a domain can collect data for a user and associate the user's data with a linked ephemeral user identifier. For simplicity, an era can be defined as a multiple of unit_of_time. For example, if the unit of time is one hour, and the era is 2160 hours, then a domain will not be able to collect data for a user for more than 90 consecutive days.

[0058] For a given instance of application 112, the era identifier "era_id" can be defined as Assuming a domain "owner_domain" and an application-specific secret ephemeral private key X and a pseudo-random HMAC key S, assume that Yd = HMAC(X, era id, era_id, unit_of_time_since_epoch, owner_domain). That is, Yd is a message code calculated based on the application-specific secret ephemeral private key X, the era identifier "era_id", the unit of time since a reference time (in this example, the epoch), and the domain name of the owner domain. As described above, the application 112 is able to calculate the domain's public key based on Yd.

[0059] When the application 112 uses the unit_of_time_since_epoch before the current time to calculate the public key for a future time period, as long as the future time indicated by the unit_of_time_since_epoch shares the same epoch identifier as the current time, the application 112 will actually use the public key of the owner domain when the time arrives. However, if the future time period indicated by the unit_of_time_since_epoch belongs to a different epoch, then when the time of the new era arrives, the application 112 will use a different public key for the owner domain. Therefore, when a new era of the instance of the application 112 begins, this method automatically disconnects the linkability of all domains.

[0060] In addition to the description in this document, controls (e.g., user interface elements with which the user can interact) may be provided to the user to allow the user to select 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, user preferences, or the user's current location), and whether to send content or communications from a server to the user. In addition, certain data may be processed in one or more ways before it is stored or used so that personally identifiable information is removed. For example, the user's identity may be processed so that personally identifiable information about the user cannot be determined, or the user's geographic location may be summarized where location information (such as city, zip code, or state level) is obtained so that the user's specific location cannot be determined. Thus, the user can control what information is collected about the user, how the information is used, and what information is provided to the user.

[0061] Figure 2 is a flow chart of an example process 200 for sending an attestation record that enables linking a user identifier for a domain. The example process 200 can be performed by an application 112 of a client device 110. The operations of the process 200 can also be implemented as instructions stored on one or more computer-readable media, which can be non-transitory, and execution of the instructions by one or more data processing devices can cause the one or more data processing devices to perform the operations of the process 200. For brevity and ease of description, the process 200 is described as being performed by the application 112.

[0062] The application 112 determines user engagement for a given domain (202). For example, the application 112 can determine the user engagement level for a user and a given domain. The user engagement level can be based on the user's engagement with content provided by the given domain for display by the application 112 running on the user's client device 110 or the client device 110 to which the user is logged in. In general, the user engagement level can represent the user's intent to view and / or interact with content provided by the given domain. Various user interactions or contributions by the domain to the selection of content for display by the application 112 can be used to determine the user engagement level. In addition, the user engagement level can be determined based on different events for different types of domains, such as domains that provide first-party content (e.g., web pages) and content platforms that provide third-party content (e.g., digital components) for display with the first-party content.

[0063] The application 112 can use a set of rules or logic to determine the user engagement level of a domain. In some embodiments, the application 112 can determine a score as a user engagement level based on one or more events of the domain. These events can include a user request for content, displaying content to a user, a user selecting a link or digital component pointing to content, etc. Each type of event can have a corresponding value. The application 112 can determine the score by aggregating the values ​​of the events of the domain within a given time period, such as the time period during which the current transient user identifier of the domain is valid. As described below, in order to determine whether to enable links between user identifiers for a domain, the application 112 can compare the user engagement level of the domain with a specified threshold. In another example, the application 112 can determine when certain events occur, and if they occur, enable links, such as without calculating scores based on multiple events.

[0064] The user engagement level for a given domain can be based on one or more requests by the user for content from that domain. For example, if a user navigates a browser to a publisher domain's website, this indicates that the user has an intent to view the publisher domain's content. Thus, determining a sufficient user engagement level for a user with content provided by a particular domain can simply be a determination that the user has interacted with the content provided by that particular domain. In another example, if a user interacts with a link that is part of organic content from a publisher, such as selecting the link, and the link points to a web page within the same publisher domain, then the user has a meaningful interaction with the publisher domain. The application 112, which can be a browser, can detect the domains to which the user navigates and determine the user engagement level for those domains based on these events.

[0065] The user engagement level for a given domain can be based on providing customized content for display with other content for the given domain. For example, the content platform 150 can provide a digital component personalized for the user based on the current transient user identifier received by the content platform 150 in the request for the digital component. When the digital component is received or rendered, the digital component can include information, such as metadata, indicating which content platforms 150 participated in the selection of the content and a link to the domain of the digital component provider 160 to which the content of the digital component corresponds. The application 112 can use this information to determine the user engagement level of each participating content platform 150 domain and digital component provider 150 domain. For example, the rendering of the digital component can be an event for determining a score for each domain, and / or can be used to determine that the user engagement level for each domain meets a threshold for enabling user identifier linking.

[0066] The level of user engagement for a given domain can be based on the given domain assisting or otherwise facilitating the distribution of customized content for display with other content. For example, a content platform can contribute to the process of distributing digital components, or otherwise facilitate other content platforms to distribute digital components. Domains that distribute digital components directly to applications 112 can notify applications 112 of such helper domains. Such knowledge can also enable applications 112 to give credit to helper domains, allowing the helper domains to store information about the user for an extended period of time based on user identifier linkage, similar to how user identifier linkage is enabled for domains that provide digital components directly to applications 112.

[0067] The user engagement level for a given domain can be based on user interactions with a digital component. User interactions with a digital component indicate a user's intent to view additional content related to the digital component, such as additional content of a digital component provider 160 that created the digital component. For example, when the user interaction level is a score, the value of the user interaction can be greater than the value of the rendering of the digital component. For user interactions with a digital component, the application 112 can determine the user engagement level for each content platform 150 and digital component provider that participated in the selection of the digital component, similar to that of the rendering of the digital component. Other events can also be used to determine the user engagement level for a domain.

[0068] The application 112 determines whether to extend the link between the user identifiers of the user for the given domain based on the user engagement level (204). In order to reward the given domain for selecting content for the user and / or providing content to the user, the application 112 can enable the given domain to link the current transient user identifier that identifies the user to the given domain with one or more future transient user identifiers that the application 112 will later use to identify the user to the given domain.

[0069] During each of the plurality of time periods, the application 112 can identify the user to a given domain using a corresponding user identifier. As described above, the user identifier can be a public key. At the end of each time period, the application 112 can change the transient user identifier from the current transient user identifier for the current time period to the next transient user identifier for the next time period. If linking is not enabled, the given domain will not be able to determine that the current transient user identifier and the next transient user identifier correspond to the same user.

[0070] To determine whether to enable a link for a given domain, the application 112 can determine whether the user engagement level for the given domain meets (e.g., meets or exceeds) a specified threshold. If so, the application 112 can enable the link. If a score is used for the user engagement level, the application 112 can compare the score to the specified threshold. In another example, the application 112 can compare the type of event (e.g., a user's request for rendering of content or a digital component) to a list of events that meet the threshold (e.g., events that are considered meaningful).

[0071] The application 112 can determine whether to enable the link in response to an event. For example, if a user navigates to a web page of a given domain, the application 112 can determine that the event represents a user engagement level that meets a threshold, and enable the link in response to detecting the event. In some embodiments, the application 112 can determine whether to enable the link periodically. For example, at or near the end of each time period during which the user identifier is valid, the application 112 can determine whether to enable the link based on events that occurred during the time period.

[0072] If application 112 determines not to extend the link between the ephemeral user identifiers for the given domain, application 112 can generate an attestation record that includes the current user identifier of the user and the given domain but does not include any future user identifiers of the user and the given domain, as described below with reference to operation 208 .

[0073] If the application 112 determines to extend the link between the short-term user identifier for a given domain, the application 112 can obtain one or more future domain-specific short-term user identifiers for the user and the given domain. Each future short-term user identifier can be a user identifier that the application 112 will use during a corresponding future time period to identify the user to the given domain, and the corresponding future time period will occur after the current time period during which the current short-term user identifier of the user and the given domain is valid. For example, if the time unit of the user identifier is one day, the current short-term user identifier is that of the day (e.g., Monday). Future short-term user identifiers can include future short-term user identifiers for the second day (e.g., Tuesday) and future short-term user identifiers for the third day (e.g., Wednesday). Although in this example, the time unit in which the short-term user identifier is valid is described as one day, the time unit can also be of any length and can actually be different for different user identifiers and / or different users. A first user identifier can have a first time period during which the first user identifier is valid, and a second user identifier of the same user can have a different or the same second time period. Beneficially, as previously described, using future short-term user identifiers in this manner avoids using persistent, stable user identifiers over an extended time period. Since user identifiers are constantly changing, this improves user data security.

[0074] The application 112 can determine the duration of the link to be extended based on the user engagement level (e.g., based on the number and / or type of events), and therefore determine the number of future transient user identifiers to be provided to a given domain. For example, a higher user engagement level can correspond to a longer duration, and therefore to a greater number of future transient user identifiers. In a specific example, the application 112 can include a rule set that specifies the duration of each type of event or each user engagement level. For example, navigating to a domain can correspond to four time units (e.g., four days if each user identifier is valid for one day), and rendering of a digital component can correspond to three time units.

[0075] The application 112 can generate or obtain from storage (e.g., key storage 113) a future domain-specific transient user identifier for the user and a given domain for each time unit for which the link has been enabled. For example, if the application 112 determines to extend the link for four time units, the application 112 can generate or obtain four future domain-specific transient user identifiers, one transient user identifier in each time period corresponding to four time units.

[0076] In a specific example, if a public key is used as a user identifier, the application 112 can generate a public key and a private key pair for each of the future time periods. If the link is extended by four time units, the application 112 can generate four public keys (and their corresponding private keys): PublicKey unit_of_time_since_ref+1,owner_domain 、PublicKey unit_of_time_since_ref+2,owner_domain 、PublicKey unit_of_time_since_ref+3,owner_domain and PublicKey unit_of_time_since_ref+4,owner_domain .

[0077] The application 112 (or a trusted program) generates a certification record (208). As described above, the certification record can include a data set (e.g., a public key, a timestamp, payload data, and / or an SRR) and a digital signature of the data set. For each recipient domain of the certification record, the certification record can also include a current domain-specific transient user identifier for the recipient domain, which can be a public key. If the application 112 determines to extend the link for a given domain, the certification record can include each of one or more future domain-specific user identifiers for the given domain. As described above, the user identifier of each domain can be encrypted using the encryption key of the domain so that only the domain can access the user identifier in plain text. As described above, the future domain-specific user identifier can be included in the payload data or separated from the data set. Although a certification record is used in this example, other types of messages and / or data structures can be used to send the user identifier.

[0078] The attestation record can be included in, or used in, a communication sent to one or more recipient domains. For example, the attestation record can be included in a request for a digital component. In such a request, the attestation record can include a future domain-specific transient user identifier of the publisher of the web page for which the digital component is being requested. In this example, the application 112 can extend the user identifier link for the publisher based on the user navigating to the web page.

[0079] In another example, the attestation record can be included in a communication reporting the rendering of the digital component to the content platform. In this example, the attestation record can include the future domain-specific transient user identifier of each content platform involved in the selection of the digital component and / or the digital component provider 160 that created the digital component.

[0080] In another example, the attestation record can be included in a communication for reporting the user's interaction with the digital component to the content platform. In this example, the attestation record can include a future domain-specific transient user identifier for each content platform involved in the selection of the digital component and / or the digital component provider 160 that created the digital component.

[0081] Application 112 sends the certification record to a given domain (210). Application 112 can send the certification record to a given domain via a network (e.g., Figure 1 The network 105) transmits the certification record to the given domain.

[0082] A domain that receives one or more future domain-specific transient user identifiers for a user can store the user identifier with reference to the user's current and / or previous user identifiers. For example, the domain can maintain a table that includes an entry for each of the one or more users. For each user, the table can include the oldest user identifier used to identify the user to the domain and each other user identifier used to identify the user to the domain. The oldest user identifier can be referred to as a nominal user identifier. An example table, Table 1, is shown below.

[0083] Secret key (i.e., ephemeral user identifier) Value (i.e., nominal user identifier) <![CDATA[PublicKey unit_of_time_since_ref+1 ]]> <![CDATA[PublicKey unit_of_time_since_ref ]]> <![CDATA[PublicKey unit_of_time_since_ref+2 ]]> <![CDATA[PublicKey unit_of_time_since_ref ]]>

[0084] Table 1

[0085] In Table 1, when the domain receives a communication with the domain's current user identifier, the domain can compare the current user identifier to the key of Table 1. If there is a match, the domain can determine that the user is the same user as the user corresponding to the nominal user identifier in the value column.

[0086] As an example, consider that application 112 enables linking of a given domain and a user identifier for a user within two time units, as shown in Table 1. At linking time, the current domain-specific user identifier of the user and the given domain is PublicKey unit_of_time_since_refIn the attestation records received during the current time period, the domain receives two future domain-specific user identifiers for the user and the given domain, namely PublicKey unit_of_time_since_ref+1 andPublicKey unit_of_time_since_ref+2 After the current time period has elapsed and the next time period begins, the application 112 can send a PublicKey containing the user's next user identifier. unit_of_time_since_ref+1 The given domain can use this user identifier to query Table 1 and determine the user corresponding to the attestation record and the received domain name including the previous user identifier PublicKey unit_of_time_since_ref The user of the communication is the same user.

[0087] Thus, a given domain can include a PublicKey unit_of_time_since_ref The communication information includes the user identifier PublicKey unit_of_time_since_ref+1 The information included in the communication is related to the same user. If the corresponding PublicKey unit_of_time_since_ref+2 If the link is extended again during a second future period of communication, the given domain will receive a PublicKey unit_of_time_since_ref+2 As an attestation record for the user's current user identifier. The attestation record will also include one or more future domain-specific user identifiers for the user and a given domain. This will enable the given domain to use the user identifier PublicKey unit_of_time_since_ref+2 to link these future domain-specific user identifiers to the nominal user identifiers in Table 1.

[0088] Figure 3 is a flow chart of an example process 300 for linking a user identifier for a domain. The example process 300 can be performed by a server of a domain, such as a server of a publisher 130, a server of a content platform 150, or a server of a digital component provider 160. The operations of process 300 can also be implemented as instructions stored on one or more computer-readable media, which can be non-transitory, and execution of the instructions by one or more data processing devices can cause the one or more data processing devices to perform the operations of process 300. For brevity and ease of description, process 300 is described as being performed by a server of a domain.

[0089] The server receives a communication including the attestation record (302).The application 112 executing on the user's client device 110 can send a communication to the server.

[0090] The server uses the attestation record to determine whether the integrity of the communication is valid (304). This can include attempting to verify the digital signature using the data set of the attestation record and the public key included in the attestation record. This can also include determining whether a timestamp included in the attestation record is within a threshold duration of the current time. This can also include verifying the SRR, such as verifying a digital signature of the SRR, and if the SRR includes a timestamp, determining whether the timestamp is within a threshold duration of the current time. In some embodiments, the server determines that the integrity of the communication is valid only in response to all verifications being successful.

[0091] If the server determines that the integrity of the communication is invalid, the server does not respond to the communication (306). For example, the server can ignore the communication and / or delete the communication.

[0092] If the server determines that the integrity of the communication is valid, the server responds to the communication 308. For example, if the communication is a request for content, the server can select and provide content in response to the communication. If the communication is to report an incident, the server can respond by storing data related to the incident (e.g., payload data of the attestation record).

[0093] The server can determine whether the attestation record includes any future domain-specific ephemeral user identifiers for the domain (310). For example, the server can attempt to decrypt an ephemeral user identifier included in the payload data of the attestation record or included as an attachment or otherwise part of the attestation record but separate from the signed data set.

[0094] If the server successfully decrypts any future domain-specific transient user identifiers for the domain using its decryption key (which can be the domain's private key), the server can store a link between the current domain-specific user identifier for the user and domain (or the nominal user identifier for the user and domain) and each future domain-specific transient user identifier. For example, the server can add rows to a table similar to Table 1. Each added row can include the nominal user identifier for the user and domain and future domain-specific transient user identifiers for the user and domain. Because the server can store a link between the current domain-specific user identifier for the user and domain and each future domain-specific transient user identifier, the server can identify a specific user over multiple communications and extended time periods without the need for a permanent user identifier. This means that transient user identifiers can be used while still allowing the server to identify the same user over time, thereby providing a more secure method of identifying users over time.

[0095] Figure 44 is a block diagram of an example computer system 400 that can be used to perform the above operations. System 400 includes a processor 410, a memory 420, a storage device 430, and an input / output device 440. Each of components 410, 420, 430, and 440 can be interconnected, for example, using a system bus 450. Processor 410 can process instructions executed within system 400. In some embodiments, processor 410 is a single-threaded processor. In another embodiment, processor 410 is a multi-threaded processor. Processor 410 can process instructions stored in memory 420 or on storage device 430.

[0096] Memory 420 stores information within system 400. In one embodiment, memory 420 is a computer readable medium. In some embodiments, memory 420 is a volatile memory unit. In another embodiment, memory 420 is a non-volatile memory unit.

[0097] The storage device 430 can provide mass storage for the system 400. In some embodiments, the storage device 430 is a computer-readable medium. In various embodiments, the storage device 430 can 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.

[0098] Input / output device 440 provides input / output operation for system 400.In some embodiments, input / output device 440 can include one or more in network interface device, for example Ethernet card, serial communication device (for example RS-232 port) and / or wireless interface device, for example 802.11 card.In another embodiment, input / output device can include the driver device that is configured to receive input data and output data is sent to external device 460 (for example, keyboard, printer and display device).But, also can use other embodiments, such as mobile computing device, mobile communication device, set-top box TV client device etc.

[0099] Although already Figure 4 An example processing system is described in the specification, but the subject matter and implementation of the functional operations described in this specification can be implemented in other types of digital electronic circuits or in computer software, firmware, or hardware including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them.

[0100] The subject matter and the embodiment of operation described in this specification can be implemented in digital electronic circuit or implemented with computer software, firmware or hardware including the structure disclosed in this specification and its structural equivalent or one or more combinations thereof. The embodiment of the subject matter described in this specification can be implemented as one or more computer programs encoded on a computer storage medium (or medium) for a data processing device to execute or control the operation of the data processing device, i.e., one or more modules of computer program instructions. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagation signal (e.g., a machine-generated electrical, optical or electromagnetic signal), which is generated to encode information for transmission to a suitable receiver device for execution by a data processing device. The computer storage medium can 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 thereof. In addition, although the computer storage medium is not a propagation signal, the computer storage medium can be the source or destination of the computer program instructions encoded in the artificially generated propagation signal. The computer storage medium can also be or be included in one or more separate physical components or media (e.g., multiple CDs, disks or other storage devices).

[0101] The operations described in this specification can 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.

[0102] The term "data processing apparatus" encompasses all kinds of apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip, or a plurality or combination of the foregoing. The apparatus can include dedicated logic circuits, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the apparatus can also include code that creates an execution environment for the computer program in question, such as code that constitutes 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 them. The apparatus and execution environment can implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0103] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds 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 collaborative files (e.g., files storing one or more modules, subroutines, or code portions). A computer program can be deployed to execute on a single computer or on multiple computers located at a site or distributed across multiple sites and interconnected by a communication network.

[0104] The processes and logic flows described in this specification can be performed by one or more programmable processors that execute one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuits, and the apparatus can also be implemented as special purpose logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application specific integrated circuits).

[0105] Processors suitable for executing computer programs include, for example, both general-purpose microprocessors and special-purpose microprocessors. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for performing actions according to instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as a magnetic disk, a magneto-optical disk, or an optical disk, or be operably coupled to receive data from or transfer data to the mass storage device, or both. However, a computer does not need to have such devices. In addition, a computer can be embedded in another device, such as 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), etc. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0106] To provide interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound, voice, or tactile input. In addition, 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 in response to a request received from the web browser on the user's client device.

[0107] The embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, for example, as a data server, or includes a middleware component, for example, an application server, or includes a front-end component, for example, a client computer with a graphical user interface or a Web browser, through which a user can interact with the implementation of the subject matter described in this specification, or includes any combination of one or more such back-end components, middleware components, or front-end components. The components of the system can be interconnected by digital data communication (for example, a communication network) of any form or medium. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), interconnected networks (for example, the Internet), and peer-to-peer networks (for example, self-organizing peer-to-peer networks).

[0108] A computing system can include a client and a server. The client and the server are usually remote from each other and usually interact through a communication network. The relationship between the client and the server is generated by computer programs running on the respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., an HTML page) to the client device (e.g., for displaying data to a user interacting with the client device and receiving user input from the user interacting with the client device). Data generated at the client device (e.g., the result of a user interaction) can be received from the client device at the server.

[0109] In addition to the above embodiments, the following embodiments are also innovative:

[0110] Embodiment 1 is a method comprising: determining, for a given domain, a user's engagement with content provided by the given domain for display by an application at a client device of the user; determining, based on the user's engagement, to extend a link between a user identifier of the user of the application for the given domain; in response to determining to extend the link between the user identifier of the user of the application for the given domain: obtaining one or more future domain-specific transient user identifiers for the user and the given domain, wherein each future domain-specific transient user identifier is a user identifier that the application will use to identify the user to the given domain during a future time period after a current time period has passed; generating a certification record comprising: a data set comprising payload data; a digital signature of the data set; a current domain-specific transient user identifier for the user and the given domain; and the one or more future domain-specific transient user identifiers for the user and the given domain; and sending the certification record to the given domain.

[0111] Embodiment 2 is the method of embodiment 1, wherein the data set includes a timestamp indicating the time when the certification record was generated and a signed redemption record.

[0112] Embodiment 3 is the method of embodiment 1 or 2, wherein the payload data includes the user and the one or more future domain-specific user identifiers for the given domain.

[0113] Embodiment 4 is the method of any one of embodiments 1 to 3, wherein the engagement of the user comprises a level of user engagement of the user with the content provided by the given domain for display by the application at the client device of the user, the method further comprising selecting the number of the one or more future domain-specific user identifiers of the user and the given domain based on the user engagement level of the given domain.

[0114] Embodiment 5 is the method of any one of embodiments 1 to 4, wherein the current domain-specific user identifier and one of the plurality of future domain-specific user identifiers are encrypted using an encryption key of the given domain.

[0115] Embodiment 6 is the method of any one of embodiments 1 to 5, wherein, for each domain of a plurality of domains including the given domain, the attestation record includes a corresponding current user identifier for the domain.

[0116] Embodiment 7 is the method described in any one of embodiments 1 to 6, wherein: the current domain-specific transient user identifier of the user and the given domain includes the current public key of the user and the given domain; and each of the one or more future domain-specific user identifiers includes the future public key of the user and the given domain.

[0117] Embodiment 8 is the method of any one of embodiments 1 to 7, wherein: the given domain is the domain of a publisher of an electronic resource; and determining, for the given domain, the user's engagement with content provided by the given domain for display by the application at the user's client device includes determining the user engagement level based on the user navigating to the publisher's electronic resources.

[0118] Embodiment 9 is the method of any one of embodiments 1 to 7, wherein: the given domain is the domain of a content platform that distributes digital components or the domain of a content platform that facilitates distribution of digital components by another content platform; and determining, for the given domain, the user's engagement with content provided by the given domain for display by the application at the user's client device includes determining the user engagement level based on the content platform providing one or more digital components for presentation at the client device.

[0119] Embodiment 10 is the method of any one of Embodiments 1 to 7, wherein: the given domain is the domain of a digital component provider that creates digital components that include content of the digital component provider; and determining, for the given domain, the user's engagement with content provided by the given domain for display by the application at the user's client device includes determining a user engagement level based on the user's interaction with the digital component created by the digital component provider.

[0120] Embodiment 11 is a system comprising: one or more processors; and one or more storage devices storing instructions, wherein when the instructions are executed by the one or more processors, the one or more processors execute the method described in any one of embodiments 1 to 10.

[0121] Embodiment 12 is a computer-readable storage medium carrying instructions, which, when executed by one or more processors, causes the one or more processors to perform the method described in any one of Embodiments 1 to 10.

[0122] Embodiment 13 is a computer program product comprising instructions, which, when executed by a computer, cause the computer to perform the steps of any one of the methods of embodiments 1 to 10.

[0123] Although this specification contains many specific implementation details, these should not be regarded as limitations on the scope of any invention or content that may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment can also be implemented individually or in any suitable sub-combination in multiple embodiments. In addition, although features may be described above as working in certain combinations, and even initially claimed as such, one or more features from the claimed combination can be deleted from the combination in some cases, and the claimed combination may involve a sub-combination or a variation of a sub-combination.

[0124] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring such operations to be performed in the particular order shown or in a sequential order, or requiring all of the operations shown to be performed to achieve the desired result. In some cases, multitasking and parallel processing can be advantageous. In addition, 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 described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0125] Thus, specific embodiments of the 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 the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing can be advantageous.

Claims

1. A computer-implemented method comprising: determining, for a given domain, a user's engagement with content provided by the given domain for display by an application at a client device of the user; determining, based on the engagement of the user, to extend, for the given domain, a link between different user identifiers of users of the application for a duration such that the given domain can identify the user using any one of the different user identifiers during the duration; In response to determining to extend the link between the different user identifiers of the users of the application for the given domain for the duration: Get the user and one or more future domain-specific transient users for the given domain Identifier, where each future domain-specific transient user identifier is a Used during a future time period after the previous time period has passed to identify the given domain User identifier of the user; Generate a certification record, the certification record comprising: A data set including payload data; a digital signature of the data set; a current domain-specific transient user identifier for the user and the given domain; and the one or more future domain-specific ephemeral user identifiers for the user and the given domain; and The certification record is sent to the given domain.

2. The computer-implemented method of claim 1 , wherein: The data set includes a timestamp indicating the time when the attestation record was generated and a signed redemption record.

3. The computer-implemented method of claim 1 , wherein: The payload data comprises the user and the one or more future domain-specific user identifiers for the given domain.

4. The computer-implemented method of claim 1 , wherein: The engagement of the user comprises a level of user engagement of the user with the content, the content being provided by the given domain for display by the application at the client device of the user, the method further comprising: selecting the user and a number of the one or more future domain-specific user identifiers for the given domain based on the user engagement level for the given domain.

5. The computer-implemented method of claim 1 , wherein: The current domain-specific user identifier and one of the plurality of future domain-specific user identifiers are encrypted using an encryption key for the given domain.

6. The computer-implemented method of claim 1 , wherein: For each domain of a plurality of domains including the given domain, the certification record includes a corresponding current user identifier for the domain.

7. The computer-implemented method of claim 1 , wherein: The current domain-specific ephemeral user identifier for the user and the given domain comprises current public keys for the user and the given domain; as well as Each of the one or more future domain-specific user identifiers comprises a future public key for the user and the given domain.

8. The computer-implemented method of claim 1 , wherein: The given domain is the domain of the publisher of the electronic resource; as well as Determining, for the given domain, user engagement of the user with content provided by the given domain for display by an application at a client device of the user includes determining a user engagement level based on navigation of the user to an electronic resource of the publisher.

9. The computer-implemented method of claim 1 , wherein: The given domain is the domain of the content platform that distributes the digital component or is the domain of the content platform that facilitates distribution of the digital component by another content platform; as well as Determining the user's engagement with content for the given domain, the content provided by the given domain for display by an application at the user's client device includes determining the user engagement level based on the content platform providing one or more digital components for presentation at the client device.

10. The computer-implemented method of claim 1, wherein: The given domain is the domain of a digital component provider that creates digital components that include content of the digital component provider; as well as Determining the user's engagement with content for the given domain, the content provided by the given domain for display by an application at the user's client device includes determining a user engagement level based on the user interacting with a digital component created by the digital component provider.

11. A system for controlling access to user information, comprising: one or more processors; as well as One or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: determining, for a given domain, a user's engagement with content provided by the given domain for display by an application at a client device of the user; determining, based on the engagement of the user, to extend, for the given domain, a link between different user identifiers of users of the application for a duration such that the given domain can identify the user using any one of the different user identifiers during the duration; In response to determining to extend the link between the different user identifiers of the users of the application for the given domain for the duration: obtaining one or more future domain-specific transient user identifiers for the user and the given domain, wherein each future domain-specific transient user identifier is a user identifier that the application will use to identify the user to the given domain during a future time period after a current time period has elapsed; Generate a certification record, the certification record comprising: A data set including payload data; a digital signature of the data set; a current domain-specific transient user identifier for the user and the given domain; and the one or more future domain-specific ephemeral user identifiers for the user and the given domain; and The certification record is sent to the given domain.

12. The system according to claim 11, wherein: The data set includes a timestamp indicating the time when the attestation record was generated and a signed redemption record.

13. The system according to claim 11, wherein: The payload data comprises the user and the one or more future domain-specific user identifiers for the given domain.

14. The system according to claim 11, wherein: The engagement of the user comprises a level of user engagement of the user with the content, the content being provided by the given domain for display by the application at the client device of the user, the operations further comprising: selecting the user and a number of the one or more future domain-specific user identifiers for the given domain based on the user engagement level for the given domain.

15. The system according to claim 11, wherein: The current domain-specific user identifier and one of the plurality of future domain-specific user identifiers are encrypted using an encryption key for the given domain.

16. The system according to claim 11, wherein: For each domain of a plurality of domains including the given domain, the certification record includes a corresponding current user identifier for the domain.

17. The system of claim 11, wherein: The current domain-specific ephemeral user identifier for the user and the given domain comprises current public keys for the user and the given domain; as well as Each of the one or more future domain-specific user identifiers comprises a future public key for the user and the given domain.

18. The system of claim 11, wherein: The given domain is the domain of the publisher of the electronic resource; as well as Determining, for the given domain, user engagement of the user with content provided by the given domain for display by an application at a client device of the user includes determining a user engagement level based on navigation of the user to an electronic resource of the publisher.

19. The system according to claim 11, wherein: The given domain is the domain of the content platform that distributes the digital component or is the domain of the content platform that facilitates distribution of the digital component by another content platform; as well as Determining the user's engagement with content for the given domain, the content provided by the given domain for display by an application at the user's client device includes determining the user engagement level based on the content platform providing one or more digital components for presentation at the client device.

20. A non-transitory computer-readable storage medium carrying instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: determining, for a given domain, a user's engagement with content provided by the given domain for display by an application at a client device of the user; determining, based on the engagement of the user, to extend, for the given domain, a link between different user identifiers of users of the application for a duration such that the given domain can identify the user using any one of the different user identifiers during the duration; In response to determining to extend the link between the different user identifiers of the users of the application for the given domain for the duration: obtaining one or more future domain-specific transient user identifiers for the user and the given domain, wherein each future domain-specific transient user identifier is a user identifier that the application will use to identify the user to the given domain during a future time period after a current time period has elapsed; Generate a certification record, the certification record comprising: A data set including payload data; a digital signature of the data set; a current domain-specific transient user identifier for the user and the given domain; and the one or more future domain-specific ephemeral user identifiers for the user and the given domain; and The certification record is sent to the given domain.

Images