Method, system and medium for improving data integrity using trusted code attestation tokens

Abstract

Method, system and computer-readable medium for verifying an interaction with a digital component. The method includes: receiving input indicating an interaction associated with a digital component provided by a content provider and presented by a user interface of a user device; determining, by a trusted program of the user device, that the interaction is valid; generating, by the trusted program and based on the determination that the interaction is valid according to a validity assessment, a digital signature token that proves the validity of the interaction with the digital component; and providing, by the trusted program, the digital signature token to a third party as an indication of the validity of the interaction.

Description

[0001] This case is a divisional application of the invention patent application with the application date of April 23, 2020, application number 202080002974.7, and invention name "Improving Data Integrity Using Trusted Code Proof Tokens". Technical Field

[0002] This document deals with the use of trusted code attestation tokens to improve data integrity. Background Art

[0003] Users who interact with content on the Internet generate interaction data that can be easily manipulated. The manipulated interaction data can be used for fraudulent schemes or to disrupt online systems. Summary of the invention

[0004] In general, an innovative aspect of the subject matter described in this specification can be embodied in a method that includes receiving, at a user device and at a specific time, input indicating an interaction associated with a digital component that is (i) provided by a content provider and (ii) presented by a user interface of the user device. The method includes determining, by a trusted program of the user device, whether the interaction is valid by: detecting, by the trusted program, that the user interface of the user device is active and actively presenting the digital component at the specific time; determining, by the trusted program and in response to detecting that the user interface of the user device is active and actively presenting the digital component at the specific time, a set of attributes of the digital component, the set of attributes including a location within the user interface where the digital component is actively presented; comparing, by the trusted program, each attribute of the determined set of attributes with a corresponding attribute in a reference set of attributes of the digital component provided by the content provider; evaluating, based on the comparison and by the trusted program, the validity of the interaction, wherein, in response to (i) the comparison indicating a match between the determined set of attributes and the reference set of attributes, and (ii) detecting that the user interface of the user device is active and actively presenting the digital component at the specific time, the interaction is deemed valid. The method includes generating, by a trusted program and based on a determination that the interaction is valid according to a validity assessment, a digital signature token that proves the validity of an interaction with a digital component; and providing, by the trusted program, the digital signature token to a third party as an indication of the validity of the interaction.

[0005] These and other embodiments may each optionally include one or more of the following features. The method may also include: detecting, by a trusted program, a trigger event at a first time before a specific time, the trigger event indicating an interaction of a specific user with a display of a user device. The method may also include detecting, by the trusted program, a target event after the first time of the specific time, the target event indicating a different user interaction with the display of the user device. The method may also include: identifying, by a trusted program and based on the detection of the trigger event at the first time before the specific time and the detection of the target event at the specific time, a digital component time slot in which a digital component associated with the trigger event and the target event is presented. The method may also include: determining, by a trusted program and based on (i) detecting the trigger event at the first time before the specific time and detecting the target event at the specific time, and (ii) identifying the digital component time slot associated with the trigger event and the target event, (a) a time period between the first time and the specific time, and (b) an unverified user interaction with the digital component occurred. Receiving input indicating interaction with the digital component may be performed in response to determining that: (a) a time period between a first time and a specific time; and (b) an unverified user interaction with the digital component has occurred. The unverified user interaction may be an interaction indicated by the input.

[0006] In some implementations, the determined set of properties of the digital component includes an application in which the digital component is presented.

[0007] In some implementations, the determined set of attributes of the digital component includes one of a size, a type, and a content of the digital component.

[0008] In some implementations, the interaction associated with the digital component is an impression of the digital component on a user of the user device.

[0009] In some implementations, the interaction associated with the digital component is a click of the digital component by a user of the user device.

[0010] In some implementations, the interaction associated with the digital component includes: providing, by the user device, a request for the digital component to the third-party device.

[0011] In some embodiments, the digitally signed token certifies that the user device generated (i) the request and (ii) the token.

[0012] In some implementations, the digitally signed token certifies that the request for the digital component has not been modified.

[0013] In some embodiments, the digitally signed token proves that: (i) the request was generated by the user device; and (ii) the user device has not been modified or is a device emulator.

[0014] Other embodiments of this aspect include corresponding systems, apparatus, and computer programs configured to perform the actions of the method as encoded on a computer storage device.

[0015] Specifically, an innovative aspect of the subject matter described in this specification can be embodied in a method, the method comprising: receiving, at a user device of a user and at a specific time, input indicating an interaction associated with a digital component, the digital component being (i) provided by a content provider and (ii) presented by a user interface of the user device; determining whether the interaction is valid through a trusted program of the user device through the following steps: detecting, through a trusted program, that the user interface of the user device is active and actively presenting the digital component at a specific time; in response to determining that the user interface of the user device is active and actively presenting the digital component at a specific time, providing a set of attributes of the digital component as input to a machine learning model, the model being trained to output data indicating whether the interaction is valid based on the attributes of the digital component; receiving data indicating that the interaction is valid as an output of the machine learning model; and; generating, by the trusted program and based on the determination that the interaction is valid, a digital signature token that proves the validity of the interaction with the digital component; and providing the digital signature token to a third party through the trusted program as an indication of the validity of the interaction.

[0016] An innovative aspect of the subject matter described in this specification may also be embodied in a system, the system comprising: one or more processors of a user device; and one or more storage devices storing instructions, which, when executed by the one or more processors, cause the one or more processors to perform operations, the operations comprising: receiving input at a user device of a user and at a specific time indicating an interaction associated with a digital component, the digital component being (i) provided by a content provider and (ii) presented by a user interface of the user device; determining whether the interaction is valid through a trusted program of the user device by following the steps of: detecting through a trusted program that the user interface of the user device is active and actively presenting the digital component at a specific time; in response to determining that the user interface of the user device is active and actively presenting the digital component at a specific time, providing a set of attributes of the digital component as input to a machine learning model, the model being trained to output data indicating whether the interaction is valid based on the attributes of the digital component; receiving data indicating that the interaction is valid as output of the machine learning model; and generating, by the trusted program and based on the determination that the interaction is valid, a digital signature token proving the validity of the interaction with the digital component; and providing the digital signature token to a third party through the trusted program as an indication of the validity of the interaction.

[0017] An innovative aspect of the subject matter described in this specification may also be embodied in a non-transitory computer-readable medium carrying instructions that, when executed by one or more processors of a user device, cause the one or more processors to perform operations including: receiving, at a user device of a user and at a specific time, input indicating an interaction associated with a digital component that is (i) provided by a content provider and (ii) presented by a user interface of the user device; determining whether the interaction is valid through the following steps through a trusted program of the user device: detecting, through the trusted program, that the user interface of the user device is active and actively presenting the digital component at a specific time; in response to determining that the user interface of the user device is active and actively presenting the digital component at a specific time, providing a set of attributes of the digital component as input to a machine learning model that is trained to output data indicating whether the interaction is valid based on the attributes of the digital component; receiving data indicating that the interaction is valid as output of the machine learning model; and generating, by the trusted program and based on the determination that the interaction is valid, a digitally signed token that proves the validity of the interaction with the digital component; and providing the digitally signed token to a third party through the trusted program as an indication of the validity of the interaction.

[0018] Particular embodiments of the subject matter described herein may be implemented to achieve one or more of the following advantages. The proposed techniques improve the integrity of generated data and reduce the potential for fraud by relying on trusted code to verify the validity of events (e.g., user interactions with digital components). Trusted code, such as operating system code or the binary code of trusted programs (e.g., web browsers), is difficult to penetrate, and therefore, expending resources to compromise the integrity of such code is generally not economically feasible at scale. Therefore, the proposed techniques are both more reliable and less likely to be the target of vulnerabilities.

[0019] A trusted application can be, for example, part of the operating system of a user device, such as a device driver. A device driver is the first piece of software that responds to certain events, such as a touch event of a touch screen. Before any third-party application-level code receives data indicating that a user has touched the screen, the device driver can detect and verify the touch event so that the third-party application code has no chance to intervene by faking an interaction. The attestation token verification method allows for verification of interaction events without vulnerabilities that would facilitate click fraud and impression fraud.

[0020] Generating attestation tokens through trusted code and using these tokens in verifying user interaction events complements existing fraud detection methods and provides an additional layer of security. The method provides higher quality fraud detection at a low additional computational cost. Each time a user interaction with a digital component is detected, the provider of the digital component sends a request to verify the interaction to the user's device. The digital component distribution system already incurs the cost of receiving and processing the request, so the additional cost of on-device verification is not a significant additional burden. The method has three parts: (1) on-device or in-browser verification by generating and signing the attestation token, which takes less than a millisecond. (2) processing by a machine learning model to verify the declared properties of the digital component, which depends on the complexity of the machine learning model; (3) verification of the digital signature of the attestation token by the provider of the digital component to ensure that the signature is valid, which may also take less than a millisecond. Overall, the additional computational time and cost of performing the attestation token verification method is negligible when used in conjunction with existing solutions.

[0021] Current fraud detection methods are typically based on statistical analysis and require human input, such as manually defined rules. For example, a rule may specify that if a click event on a particular device is always at the same exact coordinates in the upper right corner, then the click is likely to be a fraudulent event. However, in order to determine and define these rules, human input is required to analyze the data to find fraudulent patterns. Therefore, the proposed technology requires fewer resources to develop and verify than traditional methods. In addition, since the proof token is generated on the device or in the browser without transmitting user interaction data to a third-party application, the proposed technology protects user privacy during event verification. The proposed technology can analyze, process, and store user data locally. By reducing the need for fraud detection based on statistical analysis methods, the proof token approach reduces the risk of compromising user data relative to other methods.

[0022] The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 is a block diagram of an example environment in which user interactions with digital components distributed for rendering electronic documents are authenticated through a deterministic cryptographic process.

[0024] Figure 2 is an example data flow for validating user interactions with digital components.

[0025] Figure 3is a flow chart of an example process for authenticating a user's interaction with a digital component through the generation of an attestation token.

[0026] Figure 4 is a block diagram of an example computing system.

[0027] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0028] Methods, systems, and devices are described herein to improve data integrity and prevent impression and / or click fraud through deterministic cryptographic techniques. Fraud is rampant in the digital ecosystem, resulting in billions of dollars in lost resources and revenue. In order to reduce and / or eliminate such fraudulent activity, techniques to improve the integrity of data collected from client devices are needed. The proposed techniques include trusted code (e.g., executed in a client device) that receives a request to verify a user interaction, determines that the user interaction is a valid interaction, generates a cryptographic token that proves the validity of the user interaction and the request, and provides the encrypted token to a third party, such as a provider of a digital component interacting with it. Trusted code such as operating system code or binary code of an application is less susceptible to fraud and tampering, and the user device can be easily updated to include this improved fraud detection functionality by updating or patching the trusted code. This trusted code generates cryptographic tokens that prove the validity of the user interaction. These tokens, called proof tokens, are digitally signed by the user device before being provided to a third party to prove that events such as impressions and click events are legitimate interactions. For example, a signed proof token may be provided to a digital component distribution system to verify the digital signature and detect fraud, such as impression and click fraud, even across an entity chain with multiple different entities.

[0029] Note that the techniques described in this document may also be implemented in situations where a user is browsing available applications (e.g., in an online analytics application or web browser) or in other environments (e.g., on a publisher web page). For brevity, much of the description below will refer to the data analytics environment, but it should be understood that the techniques discussed in this document may be applied to other situations where it is desirable to improve the integrity of data representing interactions with a client device. For example, the techniques discussed in this document may also be used to verify user interactions on a client device requesting access to a specific server, a specific website, a specific data set, or a specific account to ensure that the request is valid.

[0030] 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, text, or another unit of content). A digital component can be electronically stored as a single file or a collection of files in a physical storage device, and a digital component can take the form of a video file, an audio file, a multimedia file, an image file, or a text file, and contain advertising information, such that an advertisement is a digital component. Typically, a digital component is defined by (or provided by) a single provider or source (e.g., an advertiser, publisher, or other content provider), but can be a combination of content from multiple sources. Digital components from multiple different sources can be combined into a single electronic document (e.g., a collection of various different digital components), and portions of various digital components from different sources can be combined into a single digital component with information extracted from search results (or other portions of content).

[0031] Figure 1 1 is a block diagram of an example environment 100 in which digital components are distributed for presentation with electronic documents. User interactions with these digital components are collected and used to generate training data. The generated data is used to train a validation model that determines the effectiveness of the interactions. The example environment 100 includes a network 102, such as a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof. The network 102 connects electronic document servers 120, user devices 104, and a digital component distribution system (DCDS) 112 (also referred to as a distribution system). The example environment 100 may include many different electronic document servers 120 and multiple types of user devices 104.

[0032] User device 104 is an electronic device capable of requesting and receiving resources over network 102. Exemplary user devices 104 include personal computers, mobile communication devices, and other devices that can send and receive data over network 102. In some examples, user device 104 is a mobile device, such as a cell phone, a virtual reality device (e.g., implemented in a headset or in other devices such as a combination of speakers and a display), a smartphone, a personal digital assistant (e.g., implemented in a desktop speaker or other devices such as a combination of speakers and a display), or a tablet computer, and communicates over a wireless network. User device 104 typically includes a user application, such as a web browser, to facilitate sending and receiving data over network 102, but native applications executed by user device 104 can also facilitate sending and receiving data over network 102.

[0033] The user device 104 includes a trusted program 130 and a verification model 140. The trusted program 130 includes trusted code from a reliable source that is difficult to forge. For example, the trusted program 130 can be an operating system, a part of an operating system, a web browser, etc. Generally, the trusted program 130 is difficult to penetrate, and there is a high probability that an attacker will need to spend a lot of time and effort to tamper with the trusted program 130. In addition, because the trusted program 130 is provided and maintained by a reliable source, any vulnerabilities that arise can be resolved by the source.

[0034] Trusted program 130 can be local to user device 104. For example, trusted program 130 can be a device driver for an operating system of user device 104. In some implementations, trusted program 130 runs entirely locally to user device 104, reducing the need to send user information. In some implementations, trusted program 130 can run locally to user device 104 and over a network, such as network 102. For example, trusted program 130 can be a web browser installed on user device 104 and sends and receives information over network 102.

[0035] The validation model 140 can be a system that trains and implements a machine learning model to validate interaction events from the user device 104. The validation model 140 can be, for example, a neural network that receives training examples and user or profile information as input and outputs a prediction about whether the interaction event itself or event features are valid. For example, the validation model 140 can determine whether an event, such as a click, occurred. The validation model 140 can also determine whether features of the event, such as the content of the digital component where the impression occurred, are valid.

[0036] The user device 104 may collect user interaction data to generate training data for input to the validation model 140. The user device 104 may select random samples to obtain negative samples to train, for example, the logistic regression model 140. The user device 104 may obtain multiple user interaction data samples to generate one or more training data sets.

[0037] When generating a training data set, the user device selects training features to use in the training data set from the user's historical interactions with the digital component. The user device 104 determines the training example weights in one of several ways. In some embodiments, the user device 104 may weight each training example equally and only sample data points within a predetermined time period. In some embodiments, the user device 104 may use a decay function to weight training examples differently depending on how recent the examples are.

[0038] The system can split various percentages of modeling time and resources into training, validation, and generating test data. The system can also cross-validate the output of the model.

[0039] The verification model 140 receives training data and trains a machine learning model to determine whether an event is legitimate. The machine learning model can use any of a variety of techniques, such as decision trees, linear regression models, logistic regression models, neural networks, classifiers, support vector machines, inductive logic programming, model ensembles (e.g., using techniques such as bagging, boosting, random forests, etc.), genetic algorithms, Bayesian networks, etc., and can be trained using a variety of methods, such as deep learning, association rules, inductive logic, clustering, maximum entropy classification, learning classification, etc. In some examples, the machine learning model uses supervised learning. In some examples, the machine learning model uses unsupervised learning. The machine learning model can also use extensive and deep learning, long short-term memory modeling, boosting, matrix decomposition, user embedding, or item embedding.

[0040] The verification model 140 is used to determine whether an interaction is a valid interaction. The output of the verification model 140 is a determination of whether the interaction is a valid interaction. In some embodiments, the verification model 140 may output the possibility that the interaction is a valid interaction.

[0041] An electronic document is data that presents a set of content on a user device 104. Examples of electronic documents include analytical reports, web pages, word processing documents, portable document format (PDF) documents, images, videos, search result pages, and feeds. Native applications (e.g., "apps") such as applications installed on a mobile device, tablet, or desktop computer device are also examples of electronic documents. Electronic document 121 ("electronic document") can be provided to user device 104 by electronic document server 120 ("electronic document server"). For example, electronic document server 120 can include a server that hosts a publisher website. In this example, user device 104 can initiate a request for a resource such as a given publisher web page, and electronic document server 120 that hosts the given publisher web page can respond to the request by sending machine-executable instructions that initiate presentation of the given publisher on user device 104.

[0042] In another example, electronic document server 120 may include an application server from which user device 104 may download applications. In this example, user device 104 may request resources, such as files needed to install an application, download files, and then execute the downloaded application locally.

[0043] The electronic document 121 may include a variety of content. For example, the electronic document 121 may include static content (e.g., text or other specified content) that is within the electronic document itself and / or does not change over time. The electronic document 121 may also include dynamic content that may change over time or based on each request. For example, the publisher of a given electronic document 121 may maintain data sources for populating the various parts of the electronic document 121. In this example, the given electronic document 121 may include one or more tags or scripts that cause the user device 104 to request content from the data source when the given electronic document 121 is processed (e.g., rendered or executed) by the user device 104. The user device 104 integrates the content obtained from the data source into the given electronic document 121 to create a composite electronic document including the content obtained from the data source. The electronic document may also include a dynamically generated report that processes data from other sources. For example, a given electronic document 121 may be a dynamically generated report that analyzes data from multiple other data sources, such as user interactions with other electronic documents 121.

[0044] In some cases, a given electronic document 121 may include one or more digital component tags or digital component scripts that reference DCDS 112. In these cases, when a given electronic document is processed by a user device 104, the user device 104 executes the digital component tag or digital component script. The execution of the digital component tag or digital component script configures the user device 104 to generate a request for a resource containing one or more digital components (referred to as a "component request"), which is sent to DCDS 112 via network 102. For example, the digital component tag or digital component script may enable the user device 104 to generate a packetized data request including header and payload data. The component request may include event data that specifies characteristics such as the name (or network location) of a server from which the digital component is requested, the name (or network location) of the requesting device (e.g., user device 104), and / or information that DCDS 112 may use to select one or more digital components to be provided in response to the request. The component request is sent by the user device 104 to a server of DCDS 112 via network 102 (e.g., a telecommunications network).

[0045] The component request may include event data specifying other event characteristics, such as the electronic document being requested and the location characteristics of the electronic document at which the digital component can be presented. For example, event data specifying a reference (e.g., a URL) to an electronic document (e.g., a web page) in which the digital component will be presented, an available location of the electronic document that can be used to present the digital component, the size of the available location, and / or a media type suitable for presentation at the location can be provided to DCDS112. Similarly, event data specifying keywords associated with the electronic document ("document keywords") or entities (e.g., people, places, or things) referenced by the electronic document can also be included in the component request (e.g., as payload data) and provided to DCDS112 to help identify digital components suitable for presentation with the electronic document. Event data may also include a search query submitted from the user device 104 to obtain a search results page, and / or data specifying search results and / or text, audible, or other visual content included in the search results.

[0046] The component request may also include event data related to other information, such as information that a user of the client device has provided, geographic information indicating the state or region in which the component request was submitted, or other information that provides context for the environment in which the digital component will be displayed (e.g., the time of day of the component request, the day of the week of the component request, the type of device (e.g., a mobile or tablet device) on which the digital component will be displayed). The component request may be sent, for example, over a packet network, and the component request itself may be formatted as packet data having a header and payload data. The header may specify a destination for the packet, and the payload data may include any of the information discussed above.

[0047] DCDS 112 selects digital components to be presented with a given electronic document in response to receiving a component request and / or using information included in a component request. System 110 uses data generated from user interactions with digital components such as electronic documents 121 to personalize the selection of electronic documents 121 presented to user device 104.

[0048] The user device 104 may receive data that causes the user device 104 to request a digital component from the DCDS 112. For example, the DCDS 112 may select a digital component to be presented to the user device 104. To maintain the integrity of the process, the user device 104 may prove that it is the device requesting the digital component and that the request is a genuine request. The user device 104 may receive data indicating an interaction with the digital component. The provider of the digital component then generates a request to the user device 104 for verifying the interaction. When the user device 104 receives data indicating an interaction with the digital component, the user device 104 begins the process of verifying the interaction. The interaction may simply be the presentation of the digital component and subsequent viewing or impression by the user of the user device 104. The interaction may be an explicit interaction of the user of the user device 104 with the digital component. For example, the interaction may be a click of the user of the user device 104 on the digital component. In the context of the digital component, the interaction may be an impression or a click, and the digital component distribution system may be compensated for each interaction. Such interactions are easily tampered with, and therefore, the proposed technology reduces instances of fraud by verifying the validity of each interaction by a trusted program.

[0049] The user device 104 can verify the request for the digital component or the interaction with the digital component by generating a deterministic cryptographic token or a proof token that proves the validity of the interaction. For example, the trusted program 130 can generate a proof token based on the interaction data and historical user data. When generating the proof token, the user device 104 generates a public key and a private key. The trusted program 130 uses a consistent public / private key architecture and allows a consistent fraud detection solution across platforms. When the user device 104 issues a sensitive or fraud-prone request, or when the user device 104 receives a request for verifying the interaction, the trusted program 130 stores the private key securely locally and sends out the public key. Then, the user device 104 generates a proof token including parameters that are easily forged and signs it with the private key. The user device 104 can attach a digitally signed proof token to a request for a digital component, or provide a token in response to a request for the validity of the interaction with the digital component. The token can be used to verify that the request is generated from a specific device, that the specific device has performed an interaction, that the interaction is performed with a specific digital component, and / or that the request or digital component parameters are not modified during transmission.

[0050] The proof token allows content providers to independently verify the source of each request, thereby reducing instances of forged requests and resource loss due to fraud. Because the proof token is digitally signed by the user device 104 with a private key, the content provider can authenticate the request using the proof token attached to the request to ensure that both the request and the token are generated by the user device 104. The digital component distribution system (e.g., DCDC 112) and / or other devices can verify the request and / or the interaction with the proof token provided in response to the verification request to ensure that the interaction occurs and / or the interaction is related to the declared digital component. The cryptographic nature of the proof token proves the integrity of the request and / or interaction, and allows content providers and digital component distribution systems in other third parties to safely know that the request and / or interaction request was not fraudulently created or modified by any intermediary. The content provider and / or digital component distribution system can use the proof token to determine whether the request is a new request or a replay attack, and / or whether the interaction is generated by an infected device (e.g., a root device or a device emulator) and other fraudulent activities.

[0051] Figure 2 is used in Figure 1 1. The operations of data flow 200 are performed by user device 104. The various stages of flow 200 are performed within a network environment such as environment 100.

[0052] In some examples, the user device 104 is a mobile device with a touch screen, such as a mobile phone, a smart phone, or a tablet computer, and communicates over a wireless network such as the network 102. In some examples, the user device 104 may be a desktop device, such as a laptop computer, a desktop computer, a workstation, and the like, and may have a touch screen. The third-party device 210 may be, for example, a server communicating over a wireless network such as the network 102 or a wired network separate from the wireless network over which the user device 104 communicates. For example, the user device 104 may be a smart phone communicating over a wireless cellular network, and the third-party device 210 is a remote server communicating over a wired network. In some examples, the third-party device 210 may be a DCDS 112 or an electronic document server 120. For example, the third-party device 210 may be an electronic document server 120, and may verify the validity of the interaction event before compensating the DCDS 112.

[0053] In this particular example, user device 104 is a smartphone with a touch screen; communications performed at various stages of process 200 occur via network 102, which may be the Internet; third-party device 210 is electronic document server 120, which provides digital components served to user device 104 via DCDS 112.

[0054] Impression Verification

[0055] Process 200 is a verification process, and in this example, process 200 shows the data flow of the process for verifying an impression. In this example, the user device 104 renders a digital component to be displayed to the user through the UI of the user device 104. The SDK or browser of the user device 104 is communicatively connected to the electronic document server 120 that provides the digital component, and the digital component can be rendered in, for example, a digital component time slot. When rendering the digital component, the content provider SDK of the user device 104 requests an impression certification token from the trusted program 130 of the user device 104. The trusted program 130 of the user device 104 can be, for example, the OS of the user device 104 or a web browser application installed on the user device 104.

[0056] Flow 200 begins at stage (A), where the user device 104 receives data indicating an interaction event at a particular time. In this example, stage (A) is depicted as stage (A-1), where the user device 104 receives data indicating an interaction event with a digital component. The data may indicate an event in which the data causes the content provider SDK of the user device 104 to render a digital component within a digital component time slot. The data indicates that the digital component is provided by a content provider. For example, the digital component may be provided by an electronic document server 120. In this particular example, the third-party device 210 is an electronic document server 120, which provides the user device 104 with a digital component for which the interaction event data is provided. The digital component is presented to the user of the user device 104 through a user interface (UI) of the user device 104. For example, the digital component may be presented to the user of the smartphone user device 104 through a touch screen of the smartphone user device 104. The data indicates that the interaction event is an interaction with the digital component. For example, a digital component may be provided to a user device 104 by the DCDS 112, and the user interaction may be simply a rendering of the digital component within a digital component time slot, such that the user of the user device 104 can view the digital component, which is known as an impression. Upon receiving data that causes the rendering of the digital component within the digital component time slot, the SDK of the user device 104 requests verification of the interaction by requesting a proof token from the trusted program 130 of the user device 104.

[0057] Flow 200 continues to stage (B), in which trusted program 130 of user device 104 determines that the data indicating the interaction with the digital component is valid. Trusted program 130 determines that the data indicating the interaction is valid by detecting that the UI of user device 104 is active and actively presenting the digital component (i.e., the digital component is visible to the user) at a particular time, and determines that one or more attributes of the digital component are valid.

[0058] In this example, the interaction indicated by the data is an impression or a rendering of the digital component within a digital component time slot so that the digital component can be viewed by a user of user device 104. Trusted program 130 determines that the data indicating the interaction is valid by ensuring that the portion of the UI of user device 104 that displays the digital component is in the foreground of the display of user device 104 at a particular time.

[0059] Trusted program 130 can also determine the properties of the digital component. For example, trusted program 130 can determine the size, content, and location of the digital component.

[0060] The process 200 continues to stage (C), in which the trusted application 130 uses the verification model 140 to compare the determined attributes with the declared attribute set of the digital component and evaluate the validity of the interaction based on the comparison. The verification model 140 can compare the determined attributes of the digital component with the declared attribute set of the digital component. The declared attribute set can be provided by, for example, the electronic document server 120 that provides the digital component or the SDK that presents the digital component. The verification model 140 can evaluate the validity of the interaction based on the comparison by comparing each determined attribute of the digital component with the declared attribute set of the digital component. For example, the verification model 140 can compare and confirm that the position coordinates of the determined digital component match the position coordinates of the declared digital component; the digital component is a video and matches the declared type of the digital component; and the digital component is 300x100 pixels and matches the declared digital component size.

[0061] The verification model 140 may compare the source of the digital component with the declared source of the digital component. For example, the electronic document server 120 requests verification of interaction with the digital component, and the verification model 140 may compare the determined source of the digital component content with the declared source (in this example, the electronic document server 120) to verify that the correct digital component is being interacted with.

[0062] The verification model 140 can compare the content of the digital component with the content of the declared digital component. For example, the verification model 140 can determine that the digital component is an image related to sports shoes and confirm that this matches the content of the declared digital component.

[0063] The verification model 140 can perform one or more of these comparisons based on whether the interaction is suspicious. For example, the verification model 140 can use a trained machine learning model specific to the user and can detect whether the interaction deviates from previous interactions taken by the user or other users with similar characteristics. Each unverified interaction can be given an anomaly score relative to past interactions. If the unverified interaction is above a threshold anomaly score, the verification model 140 can perform comparisons of more attributes to improve security.

[0064] The verification model 140 may determine that the interaction is a valid interaction based on the digital component displayed in the display of the user device 104 at a particular time and the determined attributes matching the declared attribute set. For example, the verification model 140 of the user device 104 may automatically perform a comparison of the determined attributes of the digital component with the declared attribute set of the digital component to evaluate the validity of the interaction. In this particular example, the interaction is an impression.

[0065] In order to maintain an accurate registration of digital components, the trusted program 130 can obtain information about the portion of the UI of the user device 104 where the digital component is presented. For example, the trusted program 130 can determine in which application running on the user device 104 the digital component slot and the digital component are presented. The trusted program 130 can then update the registry of digital components to include the application and the digital component in the registry. The registry maintains the screen area occupied by the digital component and can provide verification data of the location of the digital component. For example, the registry can be updated based on the digital component currently displayed in a specific area of ​​the screen of the user device 104.

[0066] Flow 200 continues to stage (D) where the trusted application 130 of the user device 104 generates a proof token based on the determination that the interaction is valid. The trusted application 130 may generate a public / private pair for the token and cryptographically generate the proof token itself.

[0067] Flow 200 continues to stage (E) where user device 104 digitally signs the attestation token and provides the token to a third-party device 210. In this particular example, third-party device 210 is an electronic document server 120 that provides the digital component.

[0068] Click Verify

[0069] Flow 200 is a verification process, and in this example, flow 200 shows the data flow of the process for verifying clicks. In this example, the user device 104 renders the digital component to be displayed to the user through the UI of the user device 104. The user device 104 can render the digital component within the digital component time slot to present it to the user. The trusted program 130 of the user device 104 can be, for example, a part of the OS of the user device 104, such as a device driver for the display of the user device 104 or a Web browser application installed on the user device 104. In this particular example, the display is a touch screen display. In some embodiments, the device driver can be a driver for a physical user interface device (such as a mouse or trackball) of the user device 104.

[0070] Trusted program 130 may detect triggering events that indicate a particular user's interaction with the display of user device 104. For example, device driver 130 may receive a finger-down event from a user touching a touch screen of user device 104. Device driver 130 is part of the operating system of user device 104 and is the first software to receive the finger-down event. Device driver 130 may detect the finger-down event and properties of the event, such as time, location, amount of force used, etc.

[0071] At a later time, trusted program 130 may detect a target event indicating a different user interaction with the display of user device 104. For example, device driver 130 may receive a finger-up event from a user lifting their finger from the touch screen of user device 104. Device driver 130 may detect the finger-up event and properties of the event, such as the time, location, amount of force used, etc.

[0072] When the target event and the time of the target event are detected, the device driver 130 identifies the most recent triggering event. In this particular example, the most recent triggering event is the most recent finger down event. Then, the device driver 130 can determine the digital component time slot associated with the finger up event and the most recent finger down event. In addition, once the finger up event and the most recent finger down event are identified, the device driver 130 can use the verification model 140 to verify the click event. For example, the device driver 130 can determine the amount of time between the finger up event and the most recent finger down event, and provide the amount of time to the verification model 140 to verify the interaction, as further described below. The device driver 130 can also determine the distance between the finger up event and the most recent finger down event by calculating the distance between the coordinates of the determined event, and provide the distance to the verification model 140 as an input for verifying the interaction as described below.

[0073] In this particular example, process 200 begins at stage (A) in which the user device 104 receives data indicating an interaction event at a particular time after determining an amount of time between a finger down event and a subsequent hand up event, and an unverified user interaction with the digital component occurs.

[0074] Process 200 continues with stage (B) described above regarding the impression verification process.

[0075] Flow 200 continues to stage (C), in which the trusted application 130 uses the verification model 140 to compare the determined attributes with the declared attribute set of the digital component and evaluate the validity of the interaction based on the comparison. In addition to the description of stage (C) above, the verification model 140 can also determine whether the click is a legitimate click based on the amount of time and the detected attributes of the finger down and finger up events. The verification model 140 can automatically determine the definition of the click that the user may perform. The verification model 140 can determine the minimum and maximum thresholds of the amount of time between the finger down event and the subsequent finger up event that are acceptable for the click. For example, if the time between the finger down event and the subsequent finger up event is lower than the minimum threshold amount of time that a human may perform an action, the verification model 140 can determine that the click may be a result of a robot attack or a fraudulent click. In addition, the verification model 140 can determine the minimum and maximum thresholds of the distance between the finger down event and the subsequent finger down event that are acceptable for the click. For example, the minimum distance threshold can be initially set to the lower limit of the range of distances of the movement of a person's finger from the initial finger down event to the finger up touch event that releases the touch screen click. The verification model 140 can automatically determine the maximum distance threshold by determining at what distance a pair of finger down events and finger up events is considered to be scrolling. For example, if the distance between a finger down event and a subsequent finger up event is greater than the maximum threshold distance, the verification model 140 can determine that the finger down event and the finger up event together constitute a scrolling action rather than a click. In some embodiments, the verification model 140 can be trained using data for a specific user, thereby personalizing the verification results for each user.

[0076] Process 200 continues with stage (D) and ends with stage (E) as described above with respect to the impression verification process.

[0077] Request Verification

[0078] Process 200 is a verification process, and in this example, process 200 shows the data flow of the process of generating a request for a digital component and attaching a token to the request. Process 200 starts at stage (A). In this example, stage (A) is depicted as stage (A-2), where the user device 104 receives data indicating an interaction event with the digital component. In this example, the user device 104 receives data that causes the user device 104 to request the digital component from the digital component distribution system. The trusted program 130 of the user device 104 can be, for example, part of the OS of the user device 104 or a web browser application installed on the user device 104. In this particular example, the third-party device 210 is DCDS112.

[0079] Flow 200 continues from stage (A-2) to stage (D) where the trusted application 130 of the user device 104 generates a proof token based on the determination that the interaction is valid. The trusted application 130 may generate a public / private pair for the token and cryptographically generate the proof token itself.

[0080] Flow 200 continues to stage (E) where the user device 104 digitally signs the certification token and provides the token to the third party device 210 along with the request for the digital component.

[0081] Figure 3 is a flow chart of an example process 300 for verifying an interaction event. In some implementations, the operations of process 300 may be performed by a user device. For example, the operations of process 300 may be performed by Figure 1 In some implementations, the process 300 may be implemented as instructions stored on a non-transitory computer-readable medium, and when the instructions are executed by a user device, the instructions may cause the user device to perform the operations of the process 300.

[0082] Process 300 begins by receiving input at a user device and at a particular time indicating an interaction associated with a digital component that is (i) provided by a content provider and (ii) presented by a user interface of the user device (302). For example, user device 104 may receive data that causes the digital component to be presented within a digital component time slot of a UI of user device 104. In this example, the digital component is provided by electronic document server 120. The digital component is presented via the user interface of user device 104.

[0083] Process 300 continues with a determination by the trusted program of the user device that the interaction is valid (304). Trusted program 130, which in this example is OS 130 of user device 104, can determine that the interaction indicated by the input data is valid.

[0084] Determining that the interaction is valid includes detecting, by a trusted program of the user device, that a user interface of the user device is active and actively presenting the digital component at a particular time (306). For example, the trusted program 130 of the user device 104 may determine that the digital component is in the foreground of the user interface of the user device 104 and that the digital component is visible at a particular time.

[0085] Determining that the interaction is valid also includes determining, by the trusted program and in response to detecting that the user interface of the user device is active and actively presenting the digital component at a particular time, a set of properties of the digital component, including a location in the user interface where the digital component is actively presented (308). For example, the trusted program 130 can determine the set of properties of the digital component, such as size, location, and content.

[0086] Determining that the interaction is valid also includes comparing, by a trusted program of the user device, each attribute of the determined attribute set with a corresponding attribute in a reference attribute set of the digital component provided by the content provider (310). For example, the trusted program 130 may use the verification model 140 to compare each attribute of the determined attribute set with a corresponding attribute in the reference attribute set. The reference attribute may be a declared attribute set provided by the electronic document server 120 as the content provider of the digital component.

[0087] Determining that the interaction is valid also includes evaluating the validity of the interaction based on the comparison and by the trusted program, wherein in response to (i) the comparison indicating a match between the determined set of attributes and a reference set of attributes, and (ii) detecting that the user interface of the user device is active and actively presenting the digital component at the specific time, the interaction is deemed valid (312). For example, trusted program 130 can use verification model 140 to determine that the interaction is valid in response to the comparison indicating a match between the determined set of attributes and the reference set of attributes, and detecting that the digital component is visible and presented to a user of user device 104 at the specific time.

[0088] Process 300 continues with generating, by the trusted program of the user device and based on the validity evaluation based on the determination that the interaction is valid, a digital signature token that proves the validity of the interaction with the digital component (314). For example, the trusted program 130 can use cryptographic methods to generate the proof token. The proof token proves the validity of the interaction.

[0089] Process 300 also includes providing a digitally signed proof token to the third party through the trusted program of the user device as an indication of the validity of the interaction (316). For example, trusted program 130 can send the digitally signed proof token to third-party device 210, electronic document server 120, DCDS 112, etc.

[0090] Figure 4 4 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 is capable of processing instructions executed within system 400. In one embodiment, processor 410 is a single-threaded processor. In another embodiment, processor 410 is a multi-threaded processor. Processor 410 is capable of processing instructions stored in memory 420 or storage device 430.

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

[0092] The storage device 430 can provide mass storage for the system 400. In one embodiment, the storage device 430 is a computer-readable medium. In various embodiments, the storage device 430 may include, for example, a hard disk device, an optical disk device, a storage device shared on a network by multiple computing devices (e.g., a cloud storage device), or some other mass storage device.

[0093] The input / output devices 440 provide input / output operations for the system 400. In one embodiment, the input / output devices 440 may include: one or more network interface devices, such as an Ethernet card; a serial communication device, such as an RS-232 port; and / or a wireless interface device, such as an 802.11 card. In another embodiment, the input / output devices may include a driver device configured to receive input data and send output data to other input / output devices, such as a keyboard, a printer, and a display device 460. However, other embodiments may also be used, such as a mobile computing device, a mobile communication device, a set-top television client device, etc.

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

[0095] An electronic document (referred to simply as a document for simplicity) does not necessarily have to correspond to a file. A document may be stored in a portion of a file that holds other documents, in a single file dedicated to the document in question, or in multiple coordinated files.

[0096] The subject matter and the embodiment of operation described in this specification can be implemented in digital electronic circuits, or in computer software, firmware or hardware, or in one or more combinations thereof, including the structure disclosed in this specification and its equivalent structure. The embodiment of the subject matter described in this specification can be implemented as one or more computer programs, that is, one or more modules of computer program instructions, encoded on a computer storage medium (or multiple media) to be executed by a data processing device or to control the operation of the data processing device. Alternatively or in addition, the program instruction can be encoded on an artificially generated propagation signal, such as an electrical, optical or electromagnetic signal generated by a machine, which is generated to encode information to be transmitted to a suitable receiver device to be executed by a data processing device. The computer storage medium can be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them or included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. 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 instruction encoded with an artificially generated propagation signal. The computer storage medium can also be or be contained in one or more separate physical components or media (eg, multiple CDs, disks, or other storage devices).

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

[0098] The term "data processing apparatus" covers 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, as described above. The apparatus may 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 may 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 thereof. The apparatus and execution environment may implement a variety of different computing model architectures, such as network services, distributed computing, and grid computing architectures.

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

[0100] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows 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).

[0101] For example, processors suitable for executing computer programs include general and special 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 storage devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data or be operably coupled to one or more mass storage devices for storing data to receive data from one or more mass storage devices for storing data or to send data to one or more mass storage devices or both. However, a computer does not have to have such a device. 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), to name a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and storage 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 may be supplemented by, or incorporated in, special purpose logic circuitry.

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

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

[0104] A computing system may 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 respective computers and having a client-server relationship with each other. In some embodiments, the server sends data (e.g., an HTML page) to a client device (e.g., for the purpose of displaying data to a user interacting with the client device and receiving user input therefrom). Data generated at the client device (e.g., the result of a user interaction) can be received at the server from the client device.

[0105] Although this specification contains many specific implementation details, these should not be interpreted as limitations on any invention or the scope of protection that can be claimed, but rather as descriptions of features specific to specific embodiments of specific inventions. Certain features described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented in multiple embodiments or in any suitable sub-combination, respectively. Moreover, although features may be described above as working in certain combinations and even initially claimed as such, in some cases, one or more features in the claimed combination may be removed from the combination, and the claimed combination may be used in a sub-combination or a variation of the sub-combination.

[0106] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a continuous order, or that all of the operations shown be performed to achieve the desired effect. In some cases, multitasking and parallel processing may 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 into a single software product or packaged into multiple software products.

[0107] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired results. Additionally, the processes depicted in the accompanying drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing may be advantageous.

Claims

1. A method comprising: receiving, at a user device of the user and at a particular time, input indicative of an interaction associated with a digital component that is (i) provided by a content provider and (ii) presented by a user interface of the user device; Verify that the interaction is valid through the trusted program of the user device by following these steps: Detecting through a trusted program that the user interface of the user device is active and actively presenting digital components at specific times; In response to determining that the user interface of the user device is active and actively presenting the digital component at a particular time, providing a set of properties of the digital component as an input to a machine learning model that is trained to output data indicating whether the interaction is valid based on the properties of the digital component; and receiving data indicating that the interaction was valid as an output of the machine learning model; and generating, by the trusted program and based on a determination that the interaction is valid, a digital signature token attesting to the validity of the interaction with the digital component; and A digitally signed token is provided to a third party through a trusted program as an indication of the validity of the interaction.

2. The method of claim 1 , wherein a machine learning model is trained to determine whether an interaction deviates from a user's previous interactions.

3. The method according to claim 1, wherein: The machine learning model is trained to determine whether an interaction deviates from previous interactions with users determined to have similar characteristics to the user.

4. The method according to claim 1, wherein: The trusted program includes an operating system of the user device or one of the web browsers of the user device.

5. The method according to claim 1, wherein: The properties of a digital component include the location where the digital component is actively rendered within the user interface.

6. The method according to claim 1, wherein: The properties of a digital component include the application in which the digital component is rendered.

7. The method according to claim 1, wherein: The attributes of the digital component include at least one of the size, type and content of the digital component.

8. A system comprising: one or more processors of a user device; and 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: receiving, at a user device of the user and at a particular time, input indicative of an interaction associated with a digital component that is (i) provided by a content provider and (ii) presented by a user interface of the user device; Verify that the interaction is valid through the trusted program of the user device by following these steps: Detecting through a trusted program that the user interface of the user device is active and actively presenting digital components at specific times; In response to determining that the user interface of the user device is active and actively presenting the digital component at a particular time, providing a set of properties of the digital component as an input to a machine learning model that is trained to output data indicating whether the interaction is valid based on the properties of the digital component; and receiving data indicating that the interaction was valid as an output of the machine learning model; and generating, by the trusted program and based on a determination that the interaction is valid, a digital signature token attesting to the validity of the interaction with the digital component; and A digitally signed token is provided to a third party through a trusted program as an indication of the validity of the interaction.

9. The system according to claim 8, wherein: Train a machine learning model to determine if an interaction deviates from the user’s previous interactions.

10. The system according to claim 8, wherein: The machine learning model is trained to determine whether an interaction deviates from previous interactions with users determined to have similar characteristics to the user.

11. The system according to claim 8, wherein: The trusted program includes an operating system of the user device or one of the web browsers of the user device.

12. The system according to claim 8, wherein: The properties of a digital component include the location where the digital component is actively rendered within the user interface.

13. The system according to claim 8, wherein: The properties of a digital component include the application in which the digital component is rendered.

14. The system according to claim 8, wherein: The attributes of the digital component include at least one of the size, type and content of the digital component.

15. A non-transitory computer-readable medium carrying instructions that, when executed by one or more processors of a user device, cause the one or more processors to perform operations comprising: receiving, at a user device of the user and at a particular time, input indicative of an interaction associated with a digital component that is (i) provided by a content provider and (ii) presented by a user interface of the user device; Determining that interactions are valid through trusted programs on the user's device includes: Detecting through a trusted program that the user interface of the user device is active and actively presenting digital components at specific times; In response to determining that the user interface of the user device is active and actively presenting the digital component at a particular time, providing a set of properties of the digital component as input to a machine learning model that is trained to output data indicating whether the interaction is valid based on the properties of the digital component; and receiving data indicating that the interaction was valid as an output of the machine learning model; and generating, by the trusted program and based on a determination that the interaction is valid, a digitally signed token attesting to the validity of the interaction with the digital component; and A digitally signed token is provided to a third party through a trusted program as an indication of the validity of the interaction.

16. The non-transitory computer readable medium of claim 15, wherein: Train a machine learning model to determine if an interaction deviates from the user’s previous interactions.

17. The non-transitory computer readable medium of claim 15, wherein: The machine learning model is trained to determine whether an interaction deviates from previous interactions with users determined to have similar characteristics to the user.

18. The non-transitory computer readable medium of claim 15, wherein: The trusted program includes an operating system of the user device or one of the web browsers of the user device.

19. The non-transitory computer readable medium of claim 15, wherein: The properties of a digital component include the location where the digital component is actively rendered within the user interface.

20. The non-transitory computer readable medium of claim 15, wherein: The properties of a digital component include the application in which the digital component is rendered.

Images