VERIFYING CONTENT AND INTERACTIONS WITHIN WEBVIEWS

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for verifying content provided for display within a webview and interactions with such content. Methods can include providing, within a webview executing in a portion of an application launched on a client device, a first content page including a digital component and detecting, by a script executing within the webview, a set of interaction signals. After detection of the set of interaction signals, the signals can be transferred from the webview, via a communication bridge, to a software library that is resident within the native layer. The software library transmits the set of interaction signals to a first content provider, which can determine whether the interaction signals indicate interactions by an actual human user as opposed to automated interactions. The software library then launches a second content page that is linked to by the digital component.

BACKGROUND

This specification generally relates to data processing and verifying content provided for display within a webview executing within a native application as well as interactions with the content within the webview.

A client device can display digital web content that is provided by one or more content providers, e.g., within a commercial web browser or through a native application (other than a commercial web browser) executing a webview. As used in this specification, a webview may include a browser engine contained within a native application that can (1) render web pages, (2) read, compile, and/or execute scripts and/or web code (such as JavaScript, cascading style sheets (CSS), extensible markup language (XML) etc.) to generate graphical user interfaces, and/or (3) enable communication with servers (e.g., content providers, content platforms, etc.).

SUMMARY

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods including the operations of providing, within a webview executing in a portion of an application launched on a client device, a first content page including a digital component; detecting, by a script executing within the webview, a set of interaction signals representing one or more interactions with the digital component; transferring, via a communication bridge between a native layer of the application and the webview, the set of interaction signals from the webview to a software library that is resident within the native layer; transmitting, by the software library, the set of interaction signals to a first content provider for an evaluation of whether the set of interaction signals indicate interactions by a human user of the client device with the digital component instead of an automated interaction; and launching, by the software library and in response to the one or more interactions with the digital component, a second content page that is linked to by the digital component and that is provided by the first content provider. Other embodiments of this aspect include corresponding methods, 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.

Methods can further include generating, by the script executing within the webview, a request for digital content, wherein the request includes a unique identifier for the webview that is assigned to the webview by the native layer and wherein the request for digital content includes an encrypted dataset that is generated by encrypting the environment trustworthiness data and the unique identifier; providing the request for digital content to a second content provider, wherein the second content provider is different from the first content provider; in response to providing the request for digital content to the second content provider, receiving, from the second content provider, data including the digital component and the unique identifier; verifying that the data received from the content provider includes the unique identifier; in response to verifying that the data received from the content provider includes the unique identifier, providing the digital component within the webview.

Methods can include sending, by the script and via the communication bridge, a request for environment trustworthiness data to the software library, wherein the environment trustworthiness data includes data about the native application and the client device for assessing a trustworthiness of the native application and the client device; and receiving, from the software library and via the communication bridge, the environment trustworthiness data.

Methods can include launching the second content page is executed in response to the evaluation of the interaction signals indicating interaction by a human user and wherein launching the second content page comprises launching a web browser application and accessing the URL for the second content page within the web browser application.

Methods can include determining, by the software library, that the unique identifier of the webview matches the unique identifier that was included in the data that was received from the content provider.

Methods can include providing the set of interactions signals to the first content provider further includes providing the environment trustworthiness data to the first content provider that further includes appending data representing the set of interaction signals and the environment trustworthiness data to a uniform resource locator (URL) for a second content page that is provided by the first content provider and that is linked to by the digital component.

Particular embodiments of the subject matter described in this specification can be implemented to realize one or more of the following advantages. For example, the techniques described in this specification enable content providers to verify whether interactions with digital components (e.g., digital media items, digital ads, or links to other content pages) that are provided for display within a webview, are interactions by an actual human user as opposed to automated interactions (e.g., interactions that may have been erroneously generated due to a software defect/bug and/or falsified as being generated by a human user by malicious code/entity). Webviews are implemented as a container class within the native application and generally cannot access the resources running in the native layer of the underlying native application. As a result, interaction verification resources of the native layer are inaccessible by the webview and thus, these resources cannot be leveraged in verifying interactions with digital components provided for display within the webview using existing systems. In contrast, the techniques described in this specification implement a software bridge (e.g., a JavaScript bridge) between the native layer and the webview that enables utilization of the native layer's interaction verification resources to assist in the verification of interactions with digital components within the webview.

The techniques described in this specification also prevent execution of malicious or other unwanted/unrequested code from executing within the webview. Because webviews are implemented as a container class within the native application, the native layer of an application generally does not have control over the content received and displayed within the webview. As a result, a webview may receive malicious code and/or content that can compromise the webview (and/or the interactions between the webview and the native layer), the underlying native application, and/or the client device. For example, this can happen if the webview requests content from one content provider but instead receives content/code from an entity other than the content provider to whom the request was sent (e.g., a malicious entity). To address these problems, the techniques described in this specification utilize the software resources resident in the native layer of the application to verify whether the content provider to whom a request was sent is the same content provider from whom the content was received.

DETAILED DESCRIPTION

This specification generally relates to verifying content provided for display within a webview executing within a native application as well as interactions with the content within the webview.

A content provider may want to verify that an interaction with a digital component displayed within a webview of the application is an interaction performed by an actual human user of the client device, and not some falsified indication of a human interaction. The techniques described in this specification, as summarized below and as described in additional detail throughout this specification, enable such interaction verification by executing a script in the webview to detect interaction signals with the digital components and transmitting the interaction signals from the webview to a software library residing in the native layer of the application using a communication bridge between the webview and the native layer of the application. After receiving the interaction signals from the webview, the software library in the native layer transmits the interaction signals (and/or additional environment trustworthiness data (as further described in this specification)) to the content provider, which in turn can evaluate whether the interaction signals indicate interactions by an actual human user of the client device (as opposed to automated interactions that are generated, e.g., erroneously due to software defects/bugs and/or falsified by malicious code/entity).

As used in this specification, the communication bridge is a software bridge that connects the native layer of the native application with the webview of the native application, and enables communication and data transmission between the webview and the native layer. In some implementations, the communication bridge can be implemented as a JavaScript bridge. In some implementations, the JavaScript bridge is implemented by the operating system (OS) of the client device. Examples of such OS may include Android or iOS. For example, the JavaScript bridge can be implemented using an application programming interface (API) that is provided by the OS.

In addition to verifying interactions within the webview, the techniques summarized below and described throughout this specification verify that the content provided for display within the webview is indeed provided by the content provider from which such content was requested. This verification attempts to prevent reception of unwanted and/or malicious code by the webview, which in turn can prevent the webview, the native application, and/or the client device from being compromised. To enable such content verification, the software library in the native layer of the application assigns a unique identifier to the webview and provides this unique identifier along with environment trustworthiness data (as further described in this specification) to the webview. In some implementations, the software library can encrypt the unique identifier and the environment trustworthiness data before transmitting to the webview of the application. In such implementations, the webview provides this encrypted unique identifier and the environment trustworthiness data along with a request for content to a content provider.

Upon receiving the content request, the content provider can decrypt the encrypted unique identifier and the environment trustworthiness to extract the unique identifier. The content provider can then include the unique identifier along with the data (e.g., digital component) in a message that is transmitted to the webview. Before the digital component is provided for display within the webview, the webview sends the received unique identifier (via the communication bridge) to the software library, which verifies whether the received unique identifier is the same as the unique identifier assigned to the webview. If the received unique identifier is the same as the unique identifier assigned to the webview, the software library can determine that the received digital component can be provided for display within the webview and instructs the webview to provide the digital component for display. On the other hand, if the received unique identifier is not the same as the unique identifier assigned to the webview, the software library determines that the received digital component cannot be provided for display within the webview and instructs the webview not to display this digital component.

These features and additional features are further described below with reference toFIGS.1-4.

FIG.1is a block diagram of an example environment100in which content pages and digital components are distributed and provided for display on a client device. The example environment100includes a network104. The network104can include a local area network (LAN), a wide area network (WAN), the Internet or a combination thereof. The network104can also comprise any type of wired and/or wireless network, satellite networks, cable networks, Wi-Fi networks, mobile communications networks (e.g., 3G, 4G, and so forth) or any combination thereof. The network104can utilize communications protocols, including packet-based and/or datagram-based protocols such as internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), or other types of protocols. The network104can further include a number of devices that facilitate network communications and/or form a hardware basis for the networks, such as switches, routers, gateways, access points, firewalls, base stations, repeaters or a combination thereof. The network104connects client devices102, content providers106. The example environment100may include many different content platforms106, content providers108and client devices102.

A content platform106is a computing platform (such as, e.g., a data processing apparatus as described with reference toFIG.5) that enables distribution of content. Example content platforms106include search engines, social media platforms, new platforms, data aggregator platforms, or other content sharing platforms. Each content platform106may be operated by a content platform service provider.

The content platform106can publish and make available its own content. For example, the content platform106may be a news platform, which publishes its own news articles. The content platform106may also present content provided by one or more content providers108that are not part of the content platform106. In the above example, the news platform may also present third party content provided by one or more content providers108. As another example, the content platform106may be a data aggregator platform that does not publish any of its own content, but aggregates and presents third party content provided by different content providers108.

As used in this specification, a content provider108can be a data processing apparatus (as described with reference toFIG.5) and can include servers, repositories, or other storage devices that store content generated and/or published by one or more entities and that provide content to content platforms106and/or client devices102in response to requests for content from these entities.

A client device102is an electronic device that is capable of requesting and receiving content over the network104. Example client devices102include personal computers, mobile communication devices, digital assistant devices, and other devices that can send and receive data over the network104.

An example client device102A typically comprises an operating system112that is primarily responsible for managing the device hardware such as device storage114and software resources, such as applications. The client device102A typically includes applications, such as a web browser116, to facilitate the sending or receiving of data over the network104and presenting content pages on the client device102, but native applications118(other than web browsers) executing on the client device102can also facilitate the sending or receiving of data over the network104and presenting the content pages on the client device, e.g., using webviews executing within these native applications.

In some implementations, the application118that is executed on the client device102includes a native layer, which may be an executable object compiled for execution on the client device102(e.g., compiled for the software and hardware environment of the client device102A, such as the operating system, the processor, the chipset, etc.). In some implementations, the native layer122can further include a software library123. As used throughout this specification, the software library123may include computer executable resources running in the native layer of the underlying native application that enable performing one or more operations. For example, and as described throughout this specification, the software library123may enable and/or assist with the verification of content provided in webviews and/or interactions with content provided in the webview.

In some implementations, the application118can also be configured to include a webview126. As used in this specification, a webview can read, compile, and/or execute web code and/or technologies, such as JavaScript, cascading style sheets (CSS), extensible markup language (XML) etc., to generate graphical user interfaces, communicate with web servers, and perform other web client functions. In some implementations, the webview of the application loads a script along with content pages that are provided by the content providers. For example, the script127can be JavaScript code that is loaded along with the content pages and that executes within the webview126of the application118.

The webview126can communicate with content providers to request a content page from a content provider and upon receiving such content, the webview can provide this content for display. A user of the client device102A can interact with one or more digital components provided on the received content page within the webview.

As described above, in conventional systems, content provided within webviews and the interactions with such content cannot be verified. In contrast, the following descriptions ofFIGS.2and3enable verification of content provided within webviews and verification of the interactions with such content.

FIG.2is a block diagram200that illustrates the operations performed by the components ofFIG.1in verifying whether interactions with digital components provided within a webview are interactions by an actual human user.

As depicted inFIG.2, the client device102A (e.g., a smartphone) accesses a first content page202that is provided by a content provider and presented for display within webview126of the native application118. For example, the first content page202may be a content page provided by a news aggregator platform that includes news articles that are provided by different content providers108. As another example, the first content page202may be a content page provided by a social media platform that presents media items provided by one or more content providers108. As depicted inFIG.2, the first content page202can also include a digital component204that is linked to a second content page that can be provided by the same content provider or a different content provider. As used in this specification, a digital component is a discrete unit of digital content or digital information such as, e.g., a video clip, an audio clip, a multimedia clip, an image, text, a uniform resource locator (URL), or another unit of content.

FIG.2further shows operations/interactions occurring within the native application118and in particular, shows the operations/interactions occurring between the native layer122and webview126. The native layer122is an executable object compiled for execution on the client device102A and is based on the software and hardware environment of the client device102A, such as operating system, processor, chipset, etc. The webview126can read, compile, and/or execute web code and/or technologies, such as JavaScript, cascading style sheets (CSS), extensible markup language (XML), etc., to generate graphical user interfaces, communicate with web servers, and perform other web client functions. As described above, webviews are implemented as a container class within the native application and cannot directly access the resources running in the native layer of the underlying native application. Thus, for the webview to access these resources in the native layer, a communication bridge between the webview and the native layer is required (as explained above and in further detail throughout this specification).

In some implementations, the webview126loads a script along with a content page that is provided by a content provider. The webview further presents the content pages on the client device102A and enables the user of the client device102A to interact with digital components that are included in the content pages.

A user may interact with (e.g., pressing his/her finger and/or a stylus206on the touch sensitive screen of the client device102A) the digital component204. In response to this interaction, the webview can launch a second content page that is linked to by the digital component204. In some instances, interactions that are recorded with the digital component204may have been generated erroneously (e.g., because of a software defect or bug in the application and/or the webview) or may have been generated by malicious code executing within the application (e.g., code injected by a malicious entity to falsify an interaction with the digital component).

To enable verification of whether the interaction with the digital component204within the webview is performed by an actual human user of the client device102A, the script executing within the webview detects a set of interaction signals generated by the interaction with the digital component. Examples of such interaction signals detected by the script may include, the coordinates of the location where the interaction was detected (e.g., the point of contact on a touch-sensitive screen) and the amount of time for which the contact was performed. For example, if the user of the client device102A uses a stylus206to interact with the digital component204, the script can detect interaction signals that may include the coordinates of the position where the stylus206made contact and the amount of time for which the contact was performed.

After detecting the set of interaction signals, the script127executing in the webview126transmits the set of interaction signals210to the software library in the native layer of the application via the communication bridge. For example, after detecting the set of interaction signals210by the script127that is executing in the webview126, the script127transmits the set of interaction signals to the software library123in the native layer122via the communication bridge120.

In some implementations, the software library123in the native layer122is configured to operate, alone or in conjunction with the operating system of the client device102A, to collect signals regarding software and hardware environment of the client device102A and/or the native application118. Examples of the signals collected include, but are not limited to, the operating system version running on the client device, the chipset used on the client device, an identifier for the native application, the version of the native application, whether the native application was downloaded from an official application store, the type of client device, the model of the client device, evidence of whether the device has been rooted and/or jailbroken, when the operating system of the client device was last updated, whether the native application118is running on an emulator, etc. The signals may also include details regarding other hardware and/or software resources in the client device102A that may be responsible for execution of the application118on the client device102A. These signals, which are collectively referred to as environment trustworthiness data212, can be used by the content provider to determine the trustworthiness of the client device102.

In some implementations, after receiving the set of interaction signals from the webview126, the software library123transmits the set of interaction signals210alone or in combination with the environment trustworthiness data212to the content provider108. In some implementations, the software library appends data representing the set of interaction signals and the environment trustworthiness data to a uniform resource locator (URL) for a second content page that is provided by the content provider108and that is linked to by the digital component204.

In some implementations, the software library can launch a separate web browser application (e.g., application116) and access the URL referenced in the preceding paragraph. By navigating to this URL, the software library123provides to the content provider108(and the content provider108receives), the set of interaction signals and the environment trustworthiness data. Alternatively, the URL can be launched within the webview126.

Based on the received interaction signals210and/or the environment trustworthiness data212(e.g., as included in the URL used to access the second content page provided by the content provider108), the content provider108can verify whether the interactions with the digital component204in the webview are by an actual human user of the client device102A.

The content provider108may implement, e.g., a machine learning model, a rules-based engine, or another appropriate technique that processes the set of interaction signals210and/or the environment trustworthiness data212to determine whether the interactions performed on the webview126are generated by an actual human user of the client device102A. In implementations where the content provider108includes a rules-based engine, this engine can analyze the interaction signals and/or the environment trustworthiness data using a set of rules to determine whether the interactions within the webview are interactions by an actual human user. Alternatively, in implementations where the content provider108includes a machine learning model (e.g., a supervised or unsupervised learning model), this model accepts the environment trustworthiness data and/or the interaction signals as an input and outputs a determination (e.g., a binary determination, or a likelihood assessment) as to whether the interaction within the webview was performed by an actual human user. For example, the machine learning model can be a supervised model that is trained using training data for multiple client devices, which includes interaction signals and environment trustworthiness data for each such device and the known, corresponding determination as to whether the interaction within a webview for the respective device was by an actual human user or not.

Based on the determination as to whether the interaction with the digital component in the webview was an interaction by an actual human user, the content provider108can take at least the following actions. If the content provider108determines that the interaction was not by an actual human user, the content provider108can refuse access to the second content page that is linked to by the digital component204. This could save resources at the content provider such as server processing power and network bandwidth by way of avoiding the delivery of content to a potentially compromised device. In the case of a denial of service, DoS attack originating at one or more client devices, this could be a significant saving, and could even prevent the content provider from being overwhelmed with malicious requests from one or more client devices.102A. On the other hand, if the content provider108determines that the interaction was by an actual human user, the content provider108can allow access to the second content page that is linked to by the digital component204. In some implementations, if the content provider108determines that the interaction was not by an actual human user, the content provider108can nevertheless allow access to the second content page linked to by the digital component204, but may record details about the client device102A and/or application118from which the interaction originated, to prevent or limit subsequent delivery of content to that device/application which, as mentioned previously, could save resources at the content provider by way of avoiding the delivery of content to a potentially compromised client device102A.

Alternatively, instead of the content provider108verifying whether interactions within the webview are interactions by an actual human user, such verification may be performed by the software library123. For example, the native application can be configured to include certain frameworks (as described with reference to the content provider108in the preceding paragraph) for determining whether the interactions performed on the webview are generated by an actual human user of the client device. In such implementations, if the software library123determines that the interaction was not by an actual human user, the software library123can refuse to launch a separate browser application (e.g., application116) and/or prevent access to the second content page that is linked to by the digital component204within this application116. This could save resources such as processing power, memory usage, network usage and battery power of a potentially compromised client device102A. On the other hand, if the software library123determines that the interaction was by an actual human user, the software library123can launch the application116and navigate to (e.g., by accessing the URL for) the second content page within the application116.

In summary, the above description describe how interactions with digital components in webviews are verified as interactions by actual human users of the client device. The following description ofFIG.3explains how a digital component provided for display within the webview is verified as being provided by the intended content provider (i.e., a content provider to whom a request for content was sent).

FIG.3is a block diagram300that illustrates operations performed by the components ofFIG.1in verifying whether a digital component provided for display within the webview is provided by the intended content provider.

As inFIG.2,FIG.3shows operations/interactions occurring within the native application118and in particular, shows the operations/interactions occurring between the native layer122and the webview126(both of which have already been described above with reference toFIGS.1and2).

When the webview126is launched, the webview126(or alternatively, a script327executing within the webview126) requests digital content (using request316) from a content provider108. In some implementations, the request for digital content (which is also simply referred to as “request for content”) that is generated by the script executing in the webview is a packetized data request including a header and payload data. The request for content page can include event data specifying features such as, e.g., a name (or network location) of a content provider from which the digital component is being requested and a name (or network location) of the requesting device (e.g., the client device102). In some implementations, the event data specifying event features can include the location of the digital component. For example, the request for content generated by the script327executing in the webview126of the application118may include the URL or another resource identifier of the digital component.

In some implementations, the script327can include with the request for content, a unique identifier (UID) assigned to the webview and the environment trustworthiness data. In such implementations, the script initially sends a request for the environment trustworthiness data via the communication bridge120to the software library123residing in the native layer122. This request can include the UID314of the webview, which can be used by the software library123to verify that the request for the environment trustworthiness data in fact originates from the webview126(e.g., by comparing the UID of the webview126stored in native layer122with the received UID). Upon performing such verification, the software library123generates the environment trustworthiness data as described with reference toFIG.2and provides this environment trustworthiness data to the webview via the communication bridge120.

In some implementations, the software library123encrypts the environment trustworthiness data and the webview UID in an encrypted dataset and includes this dataset in the response312, which the software library123provides to the webview126. The software library can generate the encrypted dataset using, e.g., asymmetric encryption algorithms. As part of such encryption, the software library generates the encrypted dataset using the public key of the content provider108.

The script327then includes this encrypted dataset along with the request for content316. Though not shown in the diagram, the request316for digital content is transmitted to the content provider108over the network104.

Upon receiving the request for content316, the content provider108can decrypt the encrypted data set (e.g., if asymmetric encryption is used, using the content provider's private key) to obtain the unencrypted unique identifier314aand the event trustworthiness data. The content provider108generates a response318with data that includes the digital component304(or a resource identifier, e.g., a URL, for the digital component304) as well as the decrypted unique identifier314a. Though not shown inFIG.3, the response318is transmitted over the network104to the script127in the webview126of the application118executing on the client device102A.

Upon receiving the response318, the script327provides the unique identifier (UID)314aincluded in the response318to the software library123via the communication bridge120. The software library123compares the UID314awith the UID314for the Webview126that is stored in the native layer122. If the UIDs match based on this comparison/evaluation, the software library123determines that the digital component was in fact received from the intended content provider108(i.e., the content provider108to which the request for content316was sent). On the other hand, if the UID does not match based on this evaluation, the software library123determines that the received digital component was provided by an entity other than the intended content provider108(i.e., the content provider108to which the request for content316was sent). The software library generates evaluation results315, which includes an indication of whether the digital component was in fact received from the intended content provider108, and provides the evaluation results315to the script327.

Based on the evaluation results, the script327can be configured to either provide for display or prevent display of the digital component provided in response318. For example, the script327can be configured to not present the digital component received in response318within the webview126, if the evaluation results315indicate that the digital component received in response318was not received from the intended content provider108(i.e., if the UID314ain the response318is not the same as the UID314of the webview126). This would save resources such as processing power, memory usage, and battery power of the client device102A. On the other hand, the script327can be configured to present the digital component that is provided in response318within the webview126, if the evaluation results315indicate that the digital component received in response318was received from the intended content provider108(i.e., if the UID314ain the response318is the same as the UID314of the webview126, as described in the preceding paragraph).

FIG.4is a flow diagram of an example process400for verifying whether interactions with digital components provided within a webview are interactions by an actual human user. Operations of process400are described below as being performed by the components of the system described and depicted inFIGS.1,2and3. Operations of the process400are described below for illustration purposes only. Operations of the process400can be performed by any appropriate device or system, e.g., any appropriate data processing apparatus. Operations of the process400can also be implemented as instructions stored on a non-transitory computer readable medium. Execution of the instructions cause one or more data processing apparatus to perform operations of the process400.

A first content page including a digital component is provided in a webview executing in a native application launched on a client device (410). In some implementations, and as described above with reference toFIG.2, a client device102A (e.g., a smartphone) accesses a first content page202(that is provided by the first content provider108) that is provided for display within the webview126. The first content page202further includes a digital component204that links to a second content page (which can be provided by either the first content provider or a second content provider (e.g., any other content provider other than the first content provider).

A script executing within the webview detects a set of interaction signals representing one or more interactions with the digital component (420). In some implementations, the webview126of the application118executing on the client device102A loads a script127along with the content page202that is provided by a content provider108. In some instances, interactions with the digital component204may be recorded by the webview. To enable verification of whether the interactions with the digital component204within the webview are performed by an actual human user of the client device (as opposed to, e.g., an interaction that was triggered due to a software defect/bug and/or due to execution of certain malicious code), the script executing within the webview detects a set of interaction signals based on the detected interaction with the digital component (as further described with reference toFIG.2).

Transfer the set of interaction signals from the webview to a software library that is resident within the native layer via a communication bridge between a native layer of the application and the webview (430). In some implementations, after detecting the set of interaction signals, the script127executing in the webview126transmits the set of interaction signals to the software library123in the native layer122of the application118via the communication bridge120.

The software library transmits the set of interaction signals to a first content provider for evaluation (440). In some implementations, after receiving the set of interaction signals from the webview of the application (via the communication bridge), the software library in the native layer of the application transmits the set of interaction signals to the content provider for verification. For example, the software library123after receiving the set of interaction signals210from the script127, transmits the set of interaction signals210to the content provider108.

In some implementations, in addition to transmitting the set of interaction signals, the software library123also collects and transmits the environment trustworthiness data to the content provider108(as described further with reference toFIGS.2and3). As described above with reference toFIG.2, in some implementations, the content provider may use the interaction signals and/or the event trustworthiness data, to evaluate/verify whether the interactions with the digital component within the webview are generated by an actual human user of the client device.

Launch, by the software library, a second content page that is linked to by the digital component (450). In some implementations, the software library123appends data representing the set of interaction signals and the environment trustworthiness data to a uniform resource locator (URL) for a second content page that is provided by the first content provider and that is linked to by the digital component. The software library123then launches a web browser application (that is different from the native application) and accesses this URL for the second page within the web browser application.

FIG.5is block diagram of an example computer system500that can be used to perform operations described above. The system500includes a processor510, a memory520, a storage device530, and an input/output device540. Each of the components510,520,530, and540can be interconnected, for example, using a system bus550. The processor510is capable of processing instructions for execution within the system500. In some implementations, the processor510is a single-threaded processor. In another implementation, the processor510is a multi-threaded processor. The processor510is capable of processing instructions stored in the memory520or on the storage device530.

The memory520stores information within the system500. In one implementation, the memory520is a computer-readable medium. In some implementations, the memory520is a volatile memory unit. In another implementation, the memory520is a non-volatile memory unit.

The storage device530is capable of providing mass storage for the system500. In some implementations, the storage device530is a computer-readable medium. In various different implementations, the storage device530can include, for example, a hard disk device, an optical disk device, a storage device that is shared over a network by multiple computing devices (e.g., a cloud storage device), or some other large capacity storage device.

The input/output device540provides input/output operations for the system500. In some implementations, the input/output device540can include one or more of a network interface devices, e.g., an Ethernet card, a serial communication device, e.g., and RS-232 port, and/or a wireless interface device, e.g., and 802.11 card. In another implementation, the input/output device can include driver devices configured to receive input data and send output data to peripheral devices560, e.g., keyboard, printer and display devices. Other implementations, however, can also be used, such as mobile computing devices, mobile communication devices, set-top box television client devices, etc.