Patent Description:
<CIT> discloses a system and method for protecting social networks from malicious activities, such as impersonation and phishing, that might lead to dissemination of false or misleading information.

This specification describes technologies relating to combating false advertising using crowdsourcing to protect user privacy and prevent fraudulent reporting of false advertising.

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include the actions of receiving, by the one or more servers, a false digital component alert indicating that a digital component presented at a client device includes false information. The false digital component alert is validated based on a public key to verify digital signature included in the false digital component alert matching the public key of stored attestation tokens specifying presentation and interaction data for the digital component, and in response to validating the false digital component alert, adding the false digital component alert to an aggregated report for the digital component. Based on a false alert ratio, it is determined that a magnitude of validated false digital component alerts in the aggregated report for the digital component meets a threshold, and triggering a false digital component mitigation response based on the magnitude of the validated false digital component alerts meeting the threshold, providing a false information warning with the false digital component to one or more client devices or digital component provider. Other embodiments of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

These and other embodiments can each optionally include one or more of the following features. In some implementations, the methods further include providing a false information warning with the false digital component to one or more client devices or digital component provider.

In some implementations, the methods further include reducing or halting distribution of the false digital component based at least in part on the false digital component mitigation response. Reducing or halting distribution of the false digital component can be performed by a digital component provider. Reducing or halting distribution of the false digital component can be performed by a browser, an application or an operating system of the client device.

In some implementations, the methods further include receiving, by another client device, the false digital component mitigation response, and reducing or halting distribution of the false digital component by a browser, an application or an operating system of the another client device. Reducing or halting distribution of the false digital component can include preventing output of the false digital component on the client device. Reducing or halting distribution of the false digital component can include preventing output of the false digital component on the another client device.

In some implementations, the stored attestation tokens specifying presentation and interaction data for digital components include multiple impression attestation tokens for multiple presentations of the digital component, and multiple click attestation tokens, each click attestation token corresponding to a particular impression attestation token of the multiple impression attestation tokens, and/or multiple conversion tokens, each conversion token corresponding to a particular conversion attestation token of the multiple conversion attestation tokens.

In some implementations, each impression attestation token of the multiple impression attestation tokens includes i) a campaign ID, ii) a date/time of presentation, and iii) a uniform resource locator for a landing page linked to by a particular digital component.

In some implementations, the impression attestation token can include i) a campaign ID, ii) a date/time of presentation, and iii) an advertisers phone number (e.g., for click-to-call advertisements) or geo-fencing of an advertiser's store location (e.g., for in-store visit advertisements).

In some implementations, each click attestation token of the multiple click attestation tokens includes a conversion confirmation of a user action performed in response to the presentation of the digital component.

In some implementations, validating the false digital component alert includes determining the false digital component alert includes a particular impression attestation token and a corresponding particular click attestation token and/or other relevant conversion attestation token for the digital component.

In some implementations, providing the false information warning to one or more client devices with the false digital component includes providing a visual signal for presentation with the false digital component on a client device. The visual signal can include presenting a user on the client device an option to not proceed with an associated action, e.g., not proceed to a landing page, not proceed to dial the advertiser's phone number, locating the advertiser's store location (e.g., open a mapping application and accessing a geo-fence for the store location), etc., defined by the digital component. Providing the false information warning to one or more client devices with the false digital component can include providing a validated false digital component report to a publisher of the digital component.

Other embodiments of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

Using server-side validation and aggregation of false digital component alerts from multiple users protects individual user privacy while allowing consumers to report false digital components in a verified way. Validation of the false digital component alerts using attestation tokens protects the interests of the publisher of the digital component by preventing malicious or false reporting (e.g., by malicious entities) of the digital components. False advertising reports that are reported by users rather than by particular companies or interested parties can be perceived as more neutral and therefore more trustworthy.

This subject matter can be utilized to rapidly identify false information distributed through an online system using crowdsourcing. Bad actors can be prevented from falsely reporting information as fake, by independently verifying that the reporting user has viewed and interacted with the content. By ensuring that the false digital content alerts being processed are valid prior to the processing of the alerts, the processing, memory, and resources being used to provide content to end-users is reduced because resources are not being utilized to store, distribute, or present the false information. Additionally, using attestation tokens can assist in classifying digital components as false in a more reliable and efficient manner, reducing the resources required to store and distribute misleading information. For example, the attestation tokens are configured to ensure that the alerts of false information are made by users that were actually exposed to and/or interacted with digital components that contained the false information, while still preserving the user's privacy. As such, the false information alerts can be confirmed to be legitimate rather than being made by malicious actors (e.g., entities trying to harm a particular content distributor). As such, resources are not wasted processing illegitimate false information alerts, and the resulting metrics and/or reports providing information about digital components that contain false information are made more accurate and are more efficiently created because of the ability to validate each false information alert as legitimate or illegitimate using the attestation tokens.

In general, this document relates to computer implemented methods and systems to validate and report distribution of false digital components (e.g., video clips, audio clips, multimedia clips, images, text, or another unit of content) using crowdsourcing. User alerts of (e.g., submissions identifying) false digital components are validated using content request attestation, subsequent impression attestation and click attestation in response to, or as the result of the content request attested by the content request attestation, and are aggregated by a server to maintain user privacy of the user making the alerts. A digital component that is reported as a false digital component by a threshold portion of the users who view/interact with the digital component is flagged as a false digital component for future presentations of the digital component to users. Reporting of the false digital component can be provided to content providers, publishers, and end-users. The distribution of digital components that present false information can be limited, modified, or halted, as discussed throughout this document.

Operating systems (OS), applications or browsers may provide user interfaces to enable users exposed to false digital components to report the false digital components in a privacy-preserving manner. In particular, the OS/browser can send a false digital component alert from a user to a central aggregation server(s) that implements privacy-preserving aggregation measurements. Additionally, to preserve the interests of the content publishers, measures to prevent fraudulent reporting are taken to validate each false digital component alert using encrypted content request attestation tokens, impression attestation tokens and click attestation tokens. Validating the entire causality chain of events, e.g., content request, user impression of the content, and user interaction with the content, via attestation tokens can detect falsified reports more effectively. User interfaces can alert users viewing digital components that have been deemed to contain false information in future views, e.g., through visual alerts in the user interface, as described in further detail below with reference to <FIG> and <FIG>.

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

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

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

A client device <NUM> is an electronic device that is capable of communicating over the network <NUM>. Example client devices <NUM> include personal computers, mobile communication devices, e.g., smart phones, and other devices that can send and receive data over the network <NUM>.

A client device <NUM> typically includes applications <NUM>, such as web browsers and/or native applications, to facilitate the sending and receiving of data over the network <NUM>. A native application is an application developed for a particular platform or a particular device. Publishers <NUM> can develop and provide, e.g., make available for download, native applications to the client devices <NUM>. In some implementations, the client device <NUM> is a digital media device, e.g., a streaming device that plugs into a television or other display to stream videos to the television. The digital media device can also include a web browser and/or other applications that stream video and/or present resources.

A web browser can request a resource <NUM> from a web server that hosts a website <NUM> of a publisher <NUM>, e.g., in response to the user of the client device <NUM> entering the resource address for the resource <NUM> in an address bar of the web browser or selecting a link that references the resource address. Similarly, a native application can request application content from a remote server of a publisher <NUM>.

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

When the application <NUM> loads a resource <NUM> (or application content) that includes one or more digital component slots, the application <NUM> can request a digital component for each slot from the digital component distribution system <NUM>. The digital component distribution system <NUM> can, in turn request digital components from digital component providers <NUM>. The digital component providers <NUM> are entities that provide digital components for presentation with resources <NUM>.

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

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

When the application <NUM> presents a digital component, the application <NUM> (which could be a browser) can store impression data <NUM> for the presentation of the digital component. The impression data <NUM> for a particular presentation of a digital component can include a URL or domain of a landing page for the digital component (e.g., a page linked to by the digital component and when the user clicks or interacts with the digital component, the application/browser presents the page to the user), one or more identifiers for the digital component, event-level data associated with the impression, an expiration time that specifies when the impression data is to be deleted from the client device <NUM>, and/or a reporting URL or domain to which conversion reports for the digital component are to be sent. This data can be provided by the digital component, e.g., as metadata of the digital component or an anchor tag of the digital component. As described in more detail below, rather than storing, or in addition to storing, raw impression data for each impression of a digital component, the application <NUM> can store impression data that is blindly signed by the detection system <NUM> to attest the authenticity of the impression event and impression data.

The application <NUM> can also store conversion data <NUM> in response to a conversion being detected. A conversion for a digital component is the completion of a specified user action after the digital component is presented to and/or interacted with (e.g., clicked or tapped) by the user. The conversion data <NUM> for a conversion can include data that indicates a type of the conversion as some conversions can have multiple types. The type of a conversion can specify a subsequent action after the conversion is completed. For example, a conversion may be the addition of an item to an online shopping cart. In this example, a first type of conversion may be the addition of the item without checking out (e.g., not completing a purchase) and a second type of conversion may be checking out. As described in more detail below, the conversion data for a conversion can be a set of one or more bits that indicate the type of conversion and the application can store conversion data that is blindly signed by the digital component distribution system <NUM> (or another appropriate system) to attest the authenticity of the conversion event and conversion data.

The detection system <NUM> can evaluate fraud signals received from the client device <NUM> to determine whether an impression or conversion is valid or fraudulent. The fraud signals can be dependent on the application and can vary in different implementations. The application <NUM> (or the operating system on client device <NUM>) can include an API that enables a digital component to make a call to the application <NUM> (or the operating system on client device <NUM>) to collect the fraud detection signals and provide the fraud detection signals to the detection system <NUM>. In addition to the fraud detection signals, the application <NUM> can send blinded impression data for the impression to the detection system <NUM>. If the detection system <NUM> determines that the impression is valid, the detection system <NUM> can sign the blinded impression data and provide the signed blinded impression data to the application <NUM> (or the operating system on client device <NUM>). Example techniques for generating blinded impression data and signing the blinded impression data are described below.

The aggregation system <NUM> can generate aggregated network measurements based on data received from client devices <NUM>. In the following description, the techniques for generating and providing measurement data elements is described as being performed by the application <NUM>, which can be a web browser or native application. However, in some implementations, the operating system of the client device <NUM> can generate and send the measurement data elements. In such implementations, the web browser(s) and application(s) on the client device <NUM> can be configured to report impressions and conversions to the operating system. The operating system can perform each of the operations for reporting the impressions and conversions described below as being performed by the application <NUM>.

The application <NUM> on the client devices <NUM> can provide, to the aggregation system <NUM>, measurement data elements that include encrypted data that represents network data. The network data can include impression data and/or conversion data for each conversion. For example, the application <NUM> can generate and send to the aggregation system <NUM>, a measurement data element for each impression, user interaction, and/or conversion that takes place at the client device <NUM>. The aggregated network measurements can include, for each of one or more digital components, a total number of impressions, user interactions, and/or conversions for the digital component across multiple client devices <NUM> or applications <NUM>.

In some implementations, a secure, privacy preserving aggregation system can be implemented as follows: the application <NUM> can use an (t, n) threshold scheme to generate the data in a measurement data element. In some implementations, when the application <NUM> detects a conversion or receives conversion data for a conversion, the application <NUM> generates a group key (e.g., a polynomial function) based on impression data and conversion data for the conversion. The application can then generate a group member key that represents a portion of the group key and that can be used to regenerate the group key only when a sufficient number of group member keys for the same impression and conversion pair are received. In this example, the measurement data element for a conversion can include the group member key generated by the application and a tag that corresponds to the impression and conversion pair. Each unique impression and conversion pair can have a corresponding unique tag so that the aggregation system <NUM> can aggregate the measurement data elements for each impression and conversion pair using its tag.

In a (t, n)-threshold encryption scheme, the aggregation server <NUM> would need to receive at least t group member keys for the same impression and conversion pair to be able to decrypt the impression and conversion data. If less than t group member keys are received, the aggregation server <NUM> cannot decrypt the impression and conversion data. Once at least t measurement data elements for the same impression and conversion pair are received from client devices <NUM>, the aggregation system <NUM> can determine the group key from the at least t group member keys and obtain the impression and conversion data from the group key.

The aggregation system <NUM> can determine the quantity of the conversions for an impression and conversion pair based on the number of measurement data elements received that includes impression data and conversion data for the impression and conversion pair. For example, after obtaining the impression and conversion data using the at least t group member keys, the aggregation system <NUM> can determine, as the quantity of conversions, a count of the number of the group member keys received for the impression and conversion pair. The aggregation system <NUM> can report the impression data, the conversion data, and the quantity of the conversions to the reporting system <NUM>, which may be implemented as a reporting domain that corresponds to a reporting URL of the digital component that, in turn, corresponds to the impression and conversion data. In some embodiments, another secure, privacy preserving aggregation system can implement a multi-party computation (MPC).

Digital component system <NUM> can distribute digital components from various digital component providers <NUM> to client devices <NUM>. Digital components can be flagged as false, e.g., spam, fake, or misleading, by users of the client devices <NUM>. The generated alerts for the false digital components can be verified and aggregated in order to protect the privacy of the reporting end-user as well as preserving the interests of the digital component providers <NUM>. <FIG> is a block diagram of an environment <NUM> in which false digital components are validated and reported. A false digital component refers to a digital component that contains false or misleading information. False digital component reporting server <NUM> is configured to receive false digital component alerts <NUM> responsive to digital components 205a,b provided by a digital component provider <NUM> from client devices <NUM> and/or browsers <NUM> as input and provide false information response <NUM> as output to the client devices <NUM> and/or browsers <NUM>.

False digital component reporting server <NUM> can include a validation engine <NUM>, aggregation engine <NUM>, and a response generator <NUM>. In some implementations, the processes performed by the validation engine <NUM>, aggregation engine <NUM>, and response generator <NUM> can be performed by more or fewer modules. Validation engine <NUM> is configured to receive alerts <NUM> from an operating system <NUM> of a client device <NUM> and/or alerts <NUM> from a website browser <NUM>. Additionally, the validation engine receives attestation tokens <NUM> from the respective operating system <NUM> and/or browser <NUM>.

In some implementations, attestation tokens <NUM> include impression attestation tokens, e.g., impression data <NUM> described with reference to <FIG>. Impression tokens generated by the presentation of a digital component 205a,b on a client device or web browser can include one or more of campaign identification information, a date and time of the presentation of the digital component, a uniform resource locator (URL) of a landing page linked to by the digital component, and a digital signature created by the operating system or web browser. In some implementations, impression tokens can include a phone number for click-to-call ads, or a physical location for in-store visit ads.

In some implementations, the attestation token <NUM> may carry the identity of the application <NUM> (e.g. "Application A") or the domain that the user is browsing (e.g. example. In some implementations, the attestation token <NUM> may carry additional parameters describing the impression, user interaction or conversion. In some implementations, impression tokens may carry an device integrity token or browser trust token created by detection system <NUM> to attest that the device/browser is trustworthy, and/or user's behavior on the device or in the browser is genuine. The device integrity token/browser trust token may carry the level of trustworthiness/genuineness, timestamp when the device integrity token/browser trust token was generated, the device/browser's public key or its crypto hash to bind the device integrity token/browser trust token to the device/browser, as well as the detection system <NUM>'s digital signature so that anyone can verify the authenticity of the device integrity token/browser trust token.

In some implementations, attestation tokens <NUM> include click attestation tokens, e.g., conversion data <NUM> described with reference to <FIG>. Each click attestation corresponds to a particular impression token, and is generated by a user-interaction with the presented digital component. Click attestation tokens can include a digital signature from the client device where the click occurred. In some implementations, the click attestation token includes a conversion confirmation of a user action performed in response to the presentation of the digital component. A user action can include, for example, a user clicking a hyperlink and following it to a linked landing page. In another example, a user action can be the user scrolling through at least a portion of a news article (or other content). In yet another example, a user action can be the user providing feedback, e.g., a "like," "dislike," or "share" button, in response to presentation of the digital component. In some implementations, the click token may include the source of the interaction, e.g. whether the interaction is from a stylus, mouse, keyboard, trackball, touchscreen, or programmatically injected by the application <NUM>, an virtual keyboard on screen. In some implementations, the click token may include metadata indicating which subset the information included in the token is self-declared by the application <NUM> vs. verified by the operating system of the client device <NUM>.

The attestation tokens <NUM> can be validated and aggregated, e.g., as described in <FIG> with reference to the aggregation system <NUM>, by the validation engine <NUM> and aggregation engine <NUM>. Validation engine <NUM> can receive an alert <NUM> and attestation tokens <NUM> and validate the alert <NUM>. Validation of the alert <NUM> can include verifying the impression or presentation of the digital component, verifying a user interaction with the digital component, and verifying the alert as generated in response to a report by a same human user who both viewed and interacted with the digital component. Further details of the validation process is described below with reference to <FIG>.

Validated alerts <NUM> are provided as output from the validation engine <NUM> to the aggregation engine <NUM>. Aggregation engine <NUM> is configured to receive the validated alerts <NUM> as input and determine, from the aggregated validated alerts <NUM> and the attestation tokens <NUM>, that a magnitude of the validated alerts <NUM> meets a threshold. A magnitude of the validated alerts <NUM> can be a ratio of the validated alerts <NUM> responsive to the digital component 205a,b versus a total number of presentations of the digital component <NUM> a, b to users, or total number of users exposed to the digital component <NUM>, or total number of attestation tokens <NUM> for the digital component. For example, for <NUM> users who viewed and interacted with the digital component 205a, <NUM> of the users generated false digital component alerts <NUM> responsive to the digital component 205a, meeting a threshold of <NUM>% of the total views/interactions resulting in alerts <NUM>.

In some implementations, a magnitude of the validated alerts <NUM> can be a number of alerts for the digital component 205a,b from a start of a campaign, e.g., a first impression of the digital component on a client device <NUM> and/or website browser <NUM>. The false digital component reporting server <NUM> can have an aggregation threshold that is a total number of validated alerts that are permissible before triggering a response to the digital component 205a,b. For example, once the aggregation engine <NUM> has recorded <NUM> validated alerts <NUM> total from a start of a campaign for the digital component 205a, a threshold magnitude of validated alerts <NUM> is met.

In response to determining the threshold of validated alerts <NUM> has been met, the aggregation engine <NUM> can provide a response trigger <NUM> as output to the response generator <NUM>. Response generator <NUM> receives a response trigger <NUM> as input and provides a false digital component mitigation response <NUM> as output. The false digital component mitigation response <NUM> can be provided to one or more client devices <NUM> and/or website browsers <NUM>. In one example, a false information warning 224b is provided with the digital component 205b in a resource <NUM> by the web browser <NUM>. In another example, a false information warning 224a is provided with the digital component 205a in an application environment <NUM>.

In some implementations, a browser or operating system can query the server <NUM> for a false information response <NUM>, e.g., a report, for a particular digital component <NUM> prior to requesting the digital component from the digital component provider <NUM>. For example, prior to selecting a digital component from a particular digital component provider <NUM>, a browser can check the digital component for false digital component alerts in order to determine whether to serve the digital component in the active window.

In some implementations, a browser or operating system can query the false information response <NUM> for a current digital component <NUM> presented on a client device, e.g., in order to provide a false information warning 224a along with the digital component 224b.

As depicted in <FIG>, the false information warning 224a,b can include information to the user related to the reports of the digital component being a false digital component. In some implementations, the false information warning 224a is an overlay display over a current view in the application environment, e.g., a pop-up, including information warning a user of false digital content.

Additionally, the false information warning 224a can include active buttons 225a,b for a user to interact with the false information warning 224a. As depicted in <FIG>, active buttons 225a,b include "yes" and "no" that allow a user to proceed to a landing page or other action associated with the selection of digital component 205a, or to not proceed with the process or action associated with the selection digital component 205a, respectively.

In some implementations, a user's selection of an active button 225a,b can provide feedback to the server <NUM>. User selection of an active button 225a that causes the action to proceed for the digital component 205a, e.g., proceed to a landing page, can be received by the server <NUM> as part of a click attestation and utilized to re-evaluate the threshold for the digital component 205a. In one example, for a magnitude of validated selections of the active button 225a, e.g., "yes" or "proceed," that causes the user interacting with the digital component 205a to proceed to a landing page for the digital component 205a, the server <NUM> may re-evaluate the labeling of the digital component 205a as a false digital component 205a. The re-evaluation process may involve a review by a human-expert.

In some implementations, as depicted in <FIG>, the false information warning 224b is an overlay, bounding box, or sticker displayed with the digital component 205b to warn the user of the false digital component 205b. The false information warning 224b can include an active button 225b that allows a user to provide feedback responsive to the false information warning 224b. Active button 225b can allow a user to indicate that the false information warning 224b is incorrect, e.g., that a news article is incorrectly labeled as fake news. A selection of the active button 225b can be provided to server <NUM> with a click attestation token to trigger re-evaluation of the false digital component mitigation response <NUM>.

In some implementations, the false digital component mitigation response <NUM> is provided to the digital component provider <NUM>. The false digital component mitigation response <NUM> can be, for example, a report notifying the digital component provider <NUM> that validated alerts <NUM> have been received by the false digital component reporting server <NUM> responsive to presentations of a digital component 205a. In the example of the report being provided to the digital component provider <NUM>, information about the particular reporting users of the client devices and/or browsers <NUM> can be anonymized or removed before providing the report to the digital component provider <NUM>.

In some implementations, the digital component provider <NUM> can provide an appeal <NUM> to the false digital component reporting server <NUM>, for example, responsive to a received false digital component mitigation response <NUM>. In one example, a digital component provider <NUM> can appeal <NUM> a false digital component mitigation response <NUM> that labels a digital component 205a,b. The appeal <NUM> can trigger a human-expert review of the digital component 205a,b in question to determine whether or not the mitigation response <NUM> is accurate, e.g., whether the digital component 205a,b is mislabeled as a false digital component 205a,b.

In some implementations, validation and aggregation of the alerts <NUM> responsive to the presentation of digital components <NUM> is performed by the digital component provider <NUM>. The digital component provider <NUM> can determine, based on the magnitude of validated alerts <NUM> meeting a threshold, to trigger a human-expert review of the digital component 205a,b. For example, an online news platform can validate and aggregate the alerts <NUM> responsive to news reports on their platform, e.g., to determine which news reports are being flagged by readers as fake news.

In some implementations, the false digital component reporting server <NUM> can determine that a particular source, e.g., a particular digital component provider <NUM>, is a source of multiple false digital components. The server <NUM> can generate a response <NUM> including alerting users of client devices that the digital component provider <NUM> is known to be a source of false digital components when a given digital component from the digital component provider <NUM> is presented on the client device. For example, a particular website domain may be associated with multiple validated false content, and the server <NUM> can generate a false digital component mitigation response <NUM>, e.g., a report that alerts digital component provider <NUM> to be aware that digital components from the domain may be untrustworthy.

In some implementations, the server <NUM> can determine that a particular digital component provider <NUM>, e.g., a website domain or application, is associated with multiple validated false digital components and provide reports <NUM> with some or all of the digital components 205a,b from the particular digital component provider <NUM>. For example, a particular domain can be associated with multiple false news reports such that when a user is presented with a news report, the server <NUM> will provide a warning, e.g., "this website has been reported for fake news," preemptively.

In some implementations, a digital content provider <NUM> does not call on a browser <NUM> application programming interface (API) to generate an attestation token <NUM> for a digital component 205b. Web browser <NUM> can generate the attestation token <NUM>, for example, using browser history. In one example, browser <NUM> may take a screenshot of the digital component 205b and/or verify a landing page for the digital component 205b.

In some implementations, the aggregation engine <NUM> may cluster similar digital components <NUM>, e.g., similar in visual appearance, linked to a same landing page, etc., but may have different campaign identification information. The aggregation engine <NUM> may aggregate the validated alerts <NUM> from the clustered digital components <NUM>, which can reduce the number of validated alerts <NUM> required from each of the digital components in the cluster to trigger a response <NUM>.

In some implementations, the methods and systems described herein can be applied to validate and aggregate the distribution of other forms of digital components, for example, for malware identification, fake news distribution, social media, inappropriate content and the like.

<FIG> is a flow diagram that illustrates an example process for crowdsourcing false digital component reports. A false digital component alert is received that indicates that a digital component presented at a client device includes false information (<NUM>). As depicted in <FIG>, a false digital component alert <NUM> is received by the validation engine <NUM>. The false digital component alert <NUM> has stored corresponding attestation token <NUM> including an impression attestation token, e.g., impression data <NUM>, and/or a click attestation token, e.g., conversion data <NUM>. Each attestation token <NUM> includes information for the presentation of a digital component to a user and (optionally) an interaction by the user with the digital component. A respective attestation token <NUM> can be generated for each instantiation of the digital component <NUM> on a client device, or for each user interaction with digital component <NUM>.

In some implementations, the stored attestation token <NUM> for the particular instantiation of the digital component <NUM> includes an impression attestation token and/or a click attestation token. An impression attestation token can be generated as follows: the operating system <NUM> (or another trusted application <NUM> on client device <NUM> or web browser <NUM>) receives a request from an application <NUM> or web browser <NUM> to generate a digitally signed token that may be partially or fully encrypted. This digitally signed token can be used to verify that the particular digital component <NUM> that is provided on a content page within the application <NUM> (or in webpage <NUM> of the web browser <NUM>) and displayed at a particular portion of the display of the client device <NUM> and visible to a user, is a particular digital component <NUM> provided by a digital component provider <NUM>.

In some situations, the operating system <NUM> (or another trusted application on the client device or a web browser) of the client device <NUM> determines whether a digital watermark is embedded in the particular digital component <NUM> displayed at the particular portion of the display, e.g., a touch screen for mobile devices and an LCD/LED display for desktop computers. As used in this specification, a trusted application is an application that operates within a secured environment on the device <NUM> and performs certain core device services (similar to device driver services performed by the privileged code within the operating system). If the operating system <NUM> (or a web browser <NUM>) does not identify a digital watermark in the digital component <NUM>, it concludes that the digital component <NUM> provided by the digital component provider <NUM>, which would include such a watermark, is not visible on the client device <NUM>. This may be indicative of an error in the content page, the content platform, the application, or the content provider. On the other hand, if the operating system <NUM> (or a web browser <NUM>) identifies a digital watermark in the particular digital component <NUM>, it decodes the digital watermark to obtain data for multiple attributes (e.g., content item identifier, content type, content description, content creator, etc.) that are descriptive of the particular digital component <NUM> being presented at the client device.

In some implementations, a hashed message authentication code (HMAC) algorithm can be used to protect metadata that the operating system extracts from the watermark. The extracted watermark can be provided to a potentially untrusted application and then provided to a trusted application that will generate the impression attestation token including the watermark content in the payload. Utilizing the HMAC approach enables the trusted application to differentiate falsified watermark content from watermark content that has been extracted by the operating system.

Using this decoded data, the operating system <NUM> (or another trusted application <NUM> on the client device or a web browser <NUM>) generates a digitally signed token that includes the data for the multiple attributes in the payload of the digitally signed token. In some implementations, the digitally signed token is an impression attestation token that includes (<NUM>) the client device's unique identifier (e.g., the device's public key), (<NUM>) the payload, (<NUM>) a device integrity token that can be used to evaluate the client device's trustworthiness, and/or (<NUM>) a digital signature of the device identifier for the client device, the payload, and the device integrity token, that is generated using the client device's private key. The digitally signed token, and in particular the impression attestation token, ensures that the receiver of the digitally signed token can identify if any of the data included in the token's payload (or otherwise) has been tampered with or forged. In the case where the web browser <NUM> generates the digitally signed token, the browser's native code generates the token. The browser native code has privileges that a script running on a webpage rendered by the browser does not have. The impression attestation token may be stored at the server <NUM> with the stored attestation tokens <NUM> for use in validating false digital component alerts <NUM>. For example, the information in the impression attestation token can be used to verify that a user who submitted a false digital component alert <NUM> was, in fact, presented the digital component identified in the digital component alert, such that the integrity of false digital component alerts <NUM> can be ensured.

The trusted application (which may be part of or separate from the operating system of the client device or a web browser) can also receive a request from the application or webpage to generate a click attestation token indicating that a particular digital component was interacted with by the user. Before generating this click attestation token, the trusted application determines whether certain data included with the request, which is identified by the application as being obtained from the operating system <NUM> (or the web browser <NUM>), is indeed generated and/or obtained from the operating system (or the web browser). This data can include data for a first set of parameters that is identified by the application as being descriptive of the first interaction and a first keyed-hash message authentication code (HMAC) that is identified by the application as being generated using the data for the first set of parameters. The trusted application provides this data to the operating system (or the web browser), which generates a second HMAC using the data for a first set of parameters that is included with the request.

If the second HMAC is not identical to the first HMAC, the operating system (or the web browser) determines that the first interaction is not an interaction by an actual human user and that there may be an error in the application (and/or its SDK) and/or the content platform. More specifically, for example, if the second HMAC result obtained by applying an HMAC algorithm on the first set of parameters that is identified by the application as being descriptive of the first interaction and a secret key that the operating system (or trusted application) keeps confidential is not identical to the first HMAC.

On the other hand, if the second HMAC is identical to the first HMAC, the operating system (or the web browser) concludes that the first interaction is an interaction by an actual human user. In this case, the operating system (or the web browser) also indicates to the trusted application that the first HMAC is identical to the second HMAC and thus, the data included in the request is authentic (and not forged/compromised).

In response to the determination that the first HMAC is identical to the second HMAC, the trusted application generates the click attestation token using the data for the first set of parameters included in the request. In generating this click attestation token, the trusted application includes in the payload of the click attestation token (<NUM>) data for a first set of parameters that is descriptive of the first interaction and/or (<NUM>) data identifying the particular digital component <NUM>. The operating system (or another trusted application on the client device or a web browser) sends the impression attestation token to the server <NUM> (or another appropriate content verification system) where it may be stored, e.g., stored attestation tokens <NUM>, at the server <NUM> for validating false digital component alerts <NUM>. For example, the information in the click attestation token can be used to verify that the user who submitted a false digital component alert <NUM> actually clicked on (or tapped on) the digital component identified in the digital component alert. As such, the system can conclude that the user was, in fact, presented with information on a page to which the digital component linked, which places the user in a position to judge the truthfulness or accuracy of information presented in the digital component and on the page to which the digital component linked.

In some implementations, stored attestation tokens specifying presentation and interaction data for digital components further include multiple conversion tokens, e.g., conversion data <NUM> as described with reference to <FIG>. Each of the conversion token included in the stored attestation tokens corresponds to a particular conversion attestation token of the multiple of conversion attestation tokens. For example, conversion attestation tokens can be created for a purchase of digital content, a phone call made to an advertiser, or a physical visit to a brick and mortar location. Conversion attestation tokens provide further support that the reporting user is qualified to assess whether the digital component is a false digital component. Each conversion attestation token can include information about the conversion (e.g., conversion event, identifier of a client device used to perform the conversion event, time of the conversion event, etc.), and be secured (e.g., digitally signed and/or encrypted) to prevent manipulation of the information carried by the conversion attestation token.

Referring back to <FIG>, the false digital component alert is validated based on a digital signature included in the false digital component alert, whose corresponding public key matches the public keys in stored attestation tokens specifying presentation and interaction data for the digital component (<NUM>).

The validation engine <NUM> can compare the public key from the operating system <NUM> or browser <NUM> for the alert <NUM> to the public key of a stored attestation token <NUM> for the particular instantiation of the digital component <NUM> and determine that the received alert is responsive to a real impression/conversion of the digital component <NUM>. Additionally, the validation engine <NUM> can verify, from the device integrity token/browser trust token and its digital signature, that the client device/browser is reliable.

In some implementations, validation of the attestation tokens can be performed by the server <NUM> as follows: the server <NUM> validates whether the digitally signed token, e.g., the impression attestation token, is authentic by verifying the digital signature. If not, the server <NUM> concludes that the digital component <NUM> may not have been displayed on the client device and that there may be an error in the content page, the content platform, or the application. In situations where an impression attestation token cannot be verified for a particular impression of the digital component, the server <NUM> can ignore (or discard) the false digital component alert <NUM> corresponding to that particular impression.

If the server <NUM> determines that the digitally signed token is authentic, it next determines whether the data for the attributes included in the payload match the data for the attributes of the digital component provided by the digital component provider. For example, to prove that the digital component is provided by the digital component provider, the digital component provider can digitally sign the digital component, where the digital signature enables verification of authenticity of the digital component.

If the server <NUM> determines that the data for the attributes match, the server <NUM> concludes that the particular digital component <NUM> was provided for display and visible to the user in the particular portion of the device's display is indeed provided by the digital component provider. In these situations, the server <NUM> can conclude that the false digital component alert <NUM> was submitted by a user that was actually presented with a particular digital component <NUM>. If not, the server <NUM> concludes that the digital component is/was not actually displayed on the client device and that there may be an error in the content page, the content platform, the application, or the digital component provider. In situations where the server <NUM> concludes that the particular digital component was not actually displayed, the server <NUM> can ignore (or discard) the false digital component alert <NUM> corresponding to the impression identified in the false digital component alert <NUM>.

The corresponding click attestation token for the impression attestation token can be used to verify that the interaction is an interaction by an actual human user, or if the interaction has been erroneously generated and/or falsified. As such, the server <NUM> can use the click attestation token to further ensure that the user who submitted the false digital component alert <NUM> actually interacted with the particular digital component, which would expose the user to more information related to the particular digital component.

As part of this click verification, the server <NUM> validates whether the click attestation token is authentic. If not, the server <NUM> concludes that the interaction is not an interaction by an actual human user and that there may be an error in the application (and/or its SDK) and/or the content platform. In situations where the click attestation token is not authentic, the server <NUM> can ignore (or discard) the false digital component alert <NUM> corresponding to the click (or impression) identified in the false digital component alert <NUM>.

If the server <NUM> determines that the click attestation token is authentic, the server <NUM> uses a rules-engine or another statistical model (e.g., a supervised or unsupervised machine learning model) to determine whether the data for the first set of parameters indicates that the interaction is an interaction by an actual human user. Based on this processing, the server <NUM> can either conclude that the interaction is an interaction by an actual human user, or not.

The server <NUM> can conclude from the validation of the impression attestation token and click attestation tokens whether the alert <NUM> is authentic and representative of a real impression and interaction of the digital component by a human user. Thus, the false digital component alert <NUM> can be validated as authentic, and from a user who was actually presented and/or interacted with the particular digital component, using the impression and click attestation tokens.

In some implementations, validating the false digital component alert includes determining the false digital component alert includes other relevant conversion attestation tokens for the digital component. For example, validating the false digital component alert can include determining that the alert includes conversion data related to an in-application purchase, a click-to-call, or a visit to a physical store location by the receiving user.

In response to validating the false digital component alert, the false digital component alert is added to an aggregated report for the digital component (<NUM>). The validated alerts <NUM> can be provided to an aggregation engine <NUM> at the server <NUM>. The aggregated report for the particular digital component can track a number of validated alerts <NUM> for the particular digital component <NUM>. In some implementations, the aggregated report may track other information, e.g., regionality of the validated alerts, a time-dependence of the validated alerts, or other statistics related to the validated alerts for the digital component.

Based on a false alert ratio it is determined that a magnitude of validated false digital component alerts in the aggregated report for the digital component meets a threshold (<NUM>). The aggregation engine <NUM> can compare the validated alerts <NUM> to the stored attestation tokens <NUM> for the particular digital component <NUM>. For example, the server <NUM> can compare a ratio of validated alerts <NUM> versus a total number of validated impressions/conversions for the digital component 205a. In this example, a threshold is met when the ratio of validated alerts exceeds a particular number or range, e.g., greater than <NUM>% of total impressions/conversions for the digital component are reported as false digital component.

A false digital component mitigation response is triggered based on the magnitude of the validated false digital component alerts meeting the threshold (<NUM>). In response to determining that the threshold is met, the aggregation engine <NUM> will trigger a false digital component mitigation response <NUM> at the response generator <NUM>. The response generator <NUM> can determine a type of false information warning to provide with new presentations of the digital component based on, for example, a classification of the digital component. A classification of the digital component can include, for example, an advertisement or a news or other information article. In one example, a digital component 205b that is a news article can trigger a false information warning 224b that warns a user of the fake news by presenting the digital component 205b with a border or overlay.

In some implementations, the response generator can determine a type of false information warning to provide based on a type of client device presenting the digital component. For example, a digital component 205b that is to be presented in an application environment <NUM> can trigger a false information warning 224a including a pop-up warning 224a including one or more action buttons 225a for the user to select after interacting with the digital component 205a.

In some implementations, a false information warning <NUM> is a false digital component report including reporting statistics, e.g., regionality of the alerts, that are anonymized to protect the reporting user privacy. The false digital component report can include information to be used by digital component providers <NUM>, web browsers, or application providers to better understand the digital components being reported as false digital components.

A false information warning is provided with the false digital component to one or more client devices (<NUM>). The false information warning <NUM> can be provided to the digital component provider <NUM>, client devices <NUM>, and/or website browsers <NUM>. The false information warning <NUM> can be queried by digital component provider <NUM> from the server <NUM> prior to providing the digital component <NUM> for presentation to a user so that the false information warning <NUM> can be provided with the digital component <NUM>. In one example, web browser <NUM> can query the server <NUM> for the false information warning <NUM> for a particular news article to be provided in a webpage for presentation to a user.

In some implementations, the distribution of the false digital component can be reduced or halted based in part on the false digital component mitigation response. The distribution of the false digital component can be reduced or halted by the digital component provider <NUM>. In one example, the digital component provider <NUM> can determine to halt or reduce distribution of a particular digital component <NUM> that has been labeled as false by a threshold magnitude of users in a particular region, e.g., in a particular country. In some implementations, the distribution of the false digital component can be reduced or halted by the browser <NUM>, application <NUM> or operating system <NUM> in response to the false digital component mitigation response, e.g., a report generating by the server <NUM> and queried by the browser <NUM>, application <NUM>, or operating system <NUM> prior to publishing the digital component.

In some implementations, the distribution of the false digital component can be reduced or halted by preventing output of the false digital component on the client devices <NUM> in response to the false digital component mitigation response. As such, a reduction in computing resources is achieved by not wasting resources in processing and rendering false information in the false digital component.

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

A user may be provided with controls allowing the user to make an election as to both if and when systems, programs, or features described herein may enable collection of user information (e.g., information about a user's social network, social actions, or activities, profession, a user's preferences, or a user's current location), and if the user is sent personalized content or communications from a server. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, the information retention policy, and what information is provided to the user.

Claim 1:
A method performed by data processing apparatus, the method comprising:
receiving from a client device (<NUM>, <NUM>) of a plurality of client devices a false digital component alert indicating that a digital component presented at a client device includes false information;
receiving and storing attestation tokens from said plurality of client devices, said attestation tokens comprising:
impression attestation tokens including impression data (<NUM>) generated by the presentation of a digital component on a client device; and
conversion attestation tokens including conversion data (<NUM>) generated in response to detecting a user interaction for a digital component on a client device, wherein the attestation tokens are digitally signed and include the public key of the client device (<NUM>, <NUM>);
validating the false digital component alert by comparing a public key from the client device (<NUM>, <NUM>) for the false digital component alert to a public key of the stored attestation tokens, verifying the digital signature of the attestation tokens, and determining that the digital component (<NUM>) was actually presented to and/or interacted with by the user;
in response to validating the false digital component alert, adding the false digital component alert to an aggregated report for the digital component;
determining, based on a false alert ratio, that a magnitude of validated false digital component alerts in the aggregated report for the digital component meets a threshold;
triggering a false digital component mitigation response based on the magnitude of the validated false digital component alerts meeting the threshold; and
providing said false digital component mitigation response to one or more client devices.