Privacy protection application and device error detection

By blinding the context application data on the application executed on the client device, and combining digital certificate data and device trustworthiness data, it is solved, and the problem in the prior art is difficult to effectively detect errors in the client device and application while protecting user privacy, achieving more robust error detection and higher privacy protection.

CN113853603BActive Publication Date: 2025-05-27GOOGLE LLC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202080005624.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-04-23
Filing Date
2020-05-12
Publication Date
2025-05-27
Estimated Expiration
2040-05-12

AI Technical Summary

Technical Problem

The prior art is difficult to effectively detect errors in client devices and their associated applications while protecting user privacy, especially when faced with errors caused by malicious entities.

Method used

The context application data is obtained by the application executed on the client device and blinded it to generate the blinded context application data. At the same time, digital certificate data about the application and device trustworthiness data are obtained, and this data is provided to the trust evaluation server. The trust evaluation server determines device trustworthiness and application authenticity and provides digital signatures and instructions to the application. The application then provides signatures and indications to the error detection server to determine errors in the application and device.

Benefits of technology

This enables more robust error detection on client devices and applications without damaging user privacy, enhances the evaluation of device trustworthiness and application authenticity, thereby improving the accuracy of error detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113853603B_ABST
    Figure CN113853603B_ABST
Patent Text Reader

Abstract

Methods, systems, and apparatus, including a computer program encoded on a computer storage medium, for detecting errors in a client device and its associated applications while protecting the privacy of a user of the device. The method may include obtaining contextual application data for an application on a device and blinding it. Data about a digital certificate for the application and device trustworthiness data are obtained and provided to a trust assessment server along with the blinded data. This server may provide an indication that the device is trustworthy and the application is reliable, and may digitally sign the blinded data. The digital signature may be verified, and unblinded contextual application data may be obtained. If the unblinded data matches the contextual application data, the application may provide the digital signature, indication, and unblinded contextual application data to an error detection server, which in turn may indicate that the application is error-free.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross - reference to related applications

[0002] This application is an international application and claims the benefit of IL Application No. 274165, filed on April 23, 2020. The disclosure of the foregoing application is incorporated herein by reference in its entirety. Technical field

[0003] This specification generally relates to detecting errors in a client device and its associated applications while protecting the privacy of a user of the client device. Background art

[0004] A client device may use applications (e.g., a web browser, a native application) to access a content platform (e.g., a search platform, a social media platform, or another platform that provides content). The content platform may provide digital content for display within an application launched on the client device.

[0005] In some cases, an application executed on a client device may interact with a content platform in a manner that, for example, deviates from a normal or expected interaction with the content platform or disrupts / compromises the operations and / or security of the content platform. Such interactions may be the result of errors in the application and / or the client device. In some cases, such errors may be caused or injected by malicious entities that may have compromised or inappropriately modified the application (including its software development kit (“SDK”)), the underlying client device, and / or the data provided from the application to the content platform. Summary of the invention

[0006] Generally, an innovative aspect of the subject matter described in this specification can be embodied in a method that includes the following operations: obtaining context application data through an application executed on a client device, where the context application data represents the context of providing and interacting with content within the application; blinding the context application data through the application to generate blinded context application data; obtaining data on the digital certificate of the application and device trustworthiness data, where the device trustworthiness data includes data that can be used to evaluate the trustworthiness of the client device; providing the blinded context application data, the data on the digital certificate, and the device trustworthiness data to a trust evaluation server; the trust evaluation server receiving a data set that includes (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature of the trust evaluation server on a first data item; verifying the digital signature on the first data item; in response to verifying the digital signature on the first data item, the application unblinds the first data item to obtain the unblinded first data item; confirming that the unblinded first data item matches the context application data; in response to confirming that the unblinded first data item matches the context application data, providing the digital signature on the first data item, the first indication, the second indication, and the unblinded first data item to an application error detection server; and receiving from the application error detection server a third indication specifying that the application has no errors. Other embodiments of this aspect include corresponding methods, apparatuses, and computer programs that are configured to perform the actions of the method encoded on a computer storage device. These and other embodiments may each optionally include one or more of the following features.

[0007] In some embodiments, the method may further include: by the trust evaluation server: (1) determining that the client device is trustworthy based on the device trustworthiness data; and (2) determining that the application is genuine by comparing the data on the digital certificate of the application with the data on the digital certificates of known genuine applications; and providing by the trust evaluation server to the client device a first indication specifying that the client device is trustworthy and a second indication specifying that the application is a known application.

[0008] In some embodiments, the data on the digital certificate of the application may include the digital digest of the application package (APK) of the application; or the cryptographic hash of the APK of the application.

[0009] In some embodiments, obtaining the data on the digital certificate of the application and the device trustworthiness data including device data that can be used to evaluate the trustworthiness of the client device may include: obtaining the data on the digital certificate of the application through a trusted application or operating system executed on the client device; and obtaining the device trustworthiness data through a device trustworthiness client application executed on the client device.

[0010] In some embodiments, the first indication that the specified client device is trustworthy can be a two-bit value, where the first bit of the two-bit value indicates that the client device has not been improperly modified or altered; and the second bit of the two-bit value indicates that the profile of the client device matches the profile of a previously authenticated device.

[0011] In some embodiments, the method may further include communicating with a trust evaluation server to authenticate the digital signature in response to providing a digital signature on a first data item, the first indication, the second indication, and context application data to an application error detection server, where the digital signature is an IETF VOPRF digital signature and can be authenticated by the trust evaluation server that initially generated the digital signature.

[0012] In some embodiments, the method may further include receiving, by the application error detection server from the trust evaluation server, an operation of a fourth indication specifying that the digital signature is valid.

[0013] Generally, another innovative aspect of the subject matter described in this specification can be embodied in a method including the following operations: generating, by an application executed on a client device, a random data set; blinding the random data set by the application to generate a blinded random data set; obtaining data of a digital certificate of the application and device trustworthiness data including device data that can be used to evaluate the trustworthiness of the client device; providing the blinded random data set, the data of the digital certificate, and the device trustworthiness data to a trust evaluation server; receiving from the trust evaluation server a first data set including: (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature of the trust evaluation server on a first data item; verifying the digital signature on the first data item; in response to verifying the digital signature on the first data item, unblinding the first data item by the application to obtain an unblinded first data item; confirming that the unblinded first data item matches the random data set; in response to confirming that the unblinded first data item matches the random data set, obtaining, by the application, context application data, where the context application data represents the context of providing content within the application and interacting with the content; providing the digital signature on the first data item, the first indication, the second indication, and the context application data to an application error detection server; and receiving from the application error detection server a third indication specifying that the application has no errors. Other embodiments of this aspect include corresponding methods, apparatuses, and computer programs configured to perform the actions of the methods encoded on a computer storage device.

[0014] Certain embodiments of the subject matter described in this specification can be implemented to achieve one or more of the following advantages. The techniques described in this specification can be used to identify errors (e.g., software bugs, programming errors, defects, etc.) / malicious activities in a client device and / or an application executing on the client device. To identify such errors / malicious activities, some conventional techniques have evaluated context application data (e.g., websites visited, access times, browsers or applications used to access websites) collected from applications executing on a client device.

[0015] However, such conventional solutions are not as robust as the techniques described in this specification. This is because the techniques described in this specification utilize device trustworthiness and application authenticity determination to enhance error / malicious activity detection based on context application data. For example, the device trustworthiness and application authenticity analysis described in this specification can determine that certain activities are being performed on a modified browser (or other application emulating a browser) running on a mobile device where the activity is rooted. As another example, the device trustworthiness and application authenticity analysis described in this specification can determine that certain activities are being performed on a modified browser that is executing within an emulator. In these examples, the techniques described herein would consider the identified client device to be untrustworthy and the application (in this case the browser) to be unauthentic, which in turn can strongly indicate that the application has an error (and may even be compromised). Thus, these techniques provide an improvement over conventional systems that do not consider device trustworthiness or application authenticity.

[0016] In addition, the innovations described in this specification also utilize privacy protection techniques to verify the trustworthiness / authenticity of a client device and / or an application and to determine whether an interaction with an application indicates an error in the application. In some conventional systems, scripts collect context application data (e.g., websites visited, access times, browsers or applications used to access websites), which can be used to identify application errors. In other conventional systems, historical interactions of a user across multiple different content pages, content platforms, and applications can be aggregated to identify application errors. However, such data collection in conventional systems can also be used for user fingerprinting, i.e., for aggregating user-specific data of an application / device and monitoring the user's activities.

[0017] Conversely, the techniques described in this specification enable the trustworthiness / authenticity of a client device and / or an application to be verified and determine whether an interaction with the application indicates an error in the application, while preventing user fingerprint recognition, thereby enhancing privacy. In some embodiments, the techniques described in this specification are implemented by a fork architecture in which a trust assessment server (or server instance) verifies the authenticity / trustworthiness of the device and the application, while another application error detection server (or server instance) identifies errors based on context application data. Such a fork architecture limits the amount of user / device information shared with entities external to or separate from the client device. For example, the data required to perform device trustworthiness and application authenticity assessments is provided only to the trust assessment server and not to the application error detection server. Similarly, the data required to perform application error detection is provided only to the application error detection server and not to the trust assessment server. As further described in this specification, such information shielding between entities is achieved by using blinded signatures.

[0018] Accordingly, the disclosed techniques are advantageous in protecting sensitive user information (e.g., context application data) and ensuring user privacy, as this information cannot be linked by any entity external to the client device to the corresponding data regarding the digital certificate of the application and the device trustworthiness data. This is because the trust assessment server does not have access to the context application data, and the application error detection server does not have access to the data regarding the digital certificate of the application and the device trustworthiness data. This also prevents any attempt at collusion between the servers and learning information about the user (e.g., by matching the context application data with the data regarding the digital certificate of the application and the device trustworthiness data), and thus protects user information during the process of identifying errors in the client device and / or the associated application of the device.

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

[0020] Figure 1 is a block diagram of an example environment in which digital content is distributed to and presented on a client device.

[0021] Figure 2 is a swimlane diagram illustrating example operations and interactions of various entities referred to in Figure 1 when detecting errors in an application executed on a client device.

[0022] Figure 3A flowchart of an example process for detecting errors in an application executed on a client device.

[0023] Figure 4 A block diagram of an example computer system that can be used to perform the described operations. Detailed Description

[0024] This specification is mainly concerned with techniques for performing more robust error detection in a client device and / or its associated applications (relative to conventional systems) without compromising the user privacy of the client device.

[0025] As described throughout the specification, the improved error detection techniques use a forked architecture (further described in this specification) in which one system / server / server instance performs a trustworthiness / authenticity assessment of the device and application (e.g., the trust assessment server shown in Figure 1 ), while a second system / server / server instance detects errors in the application and / or device based on context application data (e.g., the application error detection server shown in Figure 1 ). By using such an architecture and applying blind signatures on certain data provided to these systems / server / server instances, the least amount of user / device information (e.g., only the information required to perform the operations of that system / server / server instance) is shared with any one server / system / instance. This has the advantage of preventing the data required for device and application trustworthiness / authenticity assessment from being matched by external entities (outside the client device) with context application data. Thus, this prevents any external entity from learning information about the user due to the match, thereby providing improved user privacy.

[0026] The operations / interactions of the application error detection server, the trust assessment server, and the client device in detecting errors in the application and / or the client device are summarized below and described in detail throughout the specification.

[0027] The client device first obtains a data set, including (1) context application data, which represents the context of providing content within the application and interacting with the content (e.g., user browsing history, current web page / visited websites, mouse movement, user interaction with the current domain, or any signals that a script can collect from the application, user interaction with the content displayed in the application, etc.), (2) data about the digital certificate of the application (e.g., digital digest or cryptographic hash of the application package (APK) of the application), and (3) device trustworthiness data, which includes data that can be used to evaluate the trustworthiness of the client device (e.g., type of the device used, operating system of the device, etc.). The application (or operating system / trusted application) blinds the context application data and sends the blinded data together with the device trustworthiness data and the data about the digital certificate to the trust evaluation server.

[0028] Based on the received device trustworthiness data and the data about the digital certificate, the trust evaluation server determines whether the device is trustworthy and whether the application is genuine (i.e., the application is the official version and / or a known, trusted application, e.g., has been scanned for security issues and is considered to be free of any malware or virus (or other security issues)).

[0029] Since the context application data is blinded, the trust evaluation server cannot access or decrypt the data (even if it receives the data from the application). The trust evaluation server digitally signs the blinded context application data and provides the digital signature and an indication specifying whether the device is trustworthy and whether the application is genuine to the application (or operating system / trusted application).

[0030] After receiving data from the trust evaluation server, the application (or operating system / trusted application) verifies the digital signature to ensure that the data provided by the trust evaluation server (i.e., the blinded signature) has not been modified, or corrupted or forged. Once verified, the application (or operating system / trusted application) unblinds the context application data and compares the unblinded context application data with the context application data that the application previously sent to the trust evaluation server. If a match is found based on this comparison, the application (or operating system / trusted application) provides the digital signature (from the trust evaluation server), the unblinded application data, and an indication of the trustworthiness / authenticity of the device and the application to the application error detection server. Since only an indication of the trustworthiness / authenticity of the device and the application (rather than device trustworthiness data and data on the digital certificate of the application) is provided to the application error detection server, this server is never involved in device trustworthiness data or data on the digital certificate of the application (which further protects the privacy of the user / device). Due to the blinded signature scheme employed, the trust evaluation server is also not involved in the context application data, which further protects the privacy of the user / device.

[0031] After receiving data from the application (or operating system / trusted application), the application error detection server verifies the received digital signature. Once verified, the application error detection system uses the context application data and an indication of the trustworthiness / authenticity of the device and the application to determine whether there are errors in the application and / or the client device. The application error detection system provides its determination of the existence (or non-existence) of errors to the content platform and / or the client device, which can then determine whether to restrict, constrain, or allow continued interaction between the application and the client device / or the content platform.

[0032] The following refers to Figures 1 to 4 Describe these features and additional features.

[0033] Figure 1 FIG. is a block diagram of an example environment in which digital content is assigned to a client device and presented on the client device. Example environment 100 includes a network 120, such as a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof. Network 120 connects client device 102, content platform 150, application error detection server 140, and trust evaluation server 130. Example environment 100 may include many different client devices 102, content platforms 150, application error detection servers 140, and trust evaluation servers 130.

[0034] The content platform 150 is a computing platform that enables the distribution of content. Example content platforms 150 include search engines, social media platforms, new platforms, data aggregator platforms, or other content sharing platforms. Each content platform 150 can be operated by a content platform service provider. The content platform 150 can publish its own content and make its own content available on the platform. For example, the content platform 150 can be a news platform that publishes its own news articles. The content platform 150 can also present content provided by one or more content sources / providers. In the above example, the news platform can also present content created by different authors and provided by one or more content sources. As another example, the content platform 150 can be a data aggregator platform that does not publish any of its own content but aggregates and presents news articles provided by different news websites (i.e., content sources / providers).

[0035] The client device 102 is an electronic device capable of requesting and receiving content over the network 120. Example client devices 102 include personal computers, mobile communication devices, digital assistant devices, wearable devices, smart home devices, and other devices that can send and receive data over the network 120.

[0036] The client device 102 typically includes one or more user applications (e.g., application 104), such as a web browser or a native application, to facilitate sending and receiving content over the network 120. Examples of content presented at the client device 102 include web pages, word processing documents, Portable Document Format (PDF) documents, images, videos, as well as search result pages and digital advertisements.

[0037] When the client device 102 accesses a content page provided by the content platform 150 within an application (e.g., application 104, which can be a browser or a native application), a script on the content page or native code in the application 104 requests content from one or more content sources. In response to the request for content, one or more content sources can provide content that can be provided for display within the application 104.

[0038] As outlined below and with reference to Figure 2 and Figure 3 more specifically described, one or more components of the client device 102, such as the operating system 106, the trusted application 108, and the device trustworthiness client 110, can cooperate with the trust assessment server 130 and the application error detection server 140 to identify errors in the application 104. An overview of the structure and operation of these components is provided below and described in more detail with reference to Figure 2 more specifically.

[0039] The client device 102 includes an operating system 106, which is mainly responsible for managing the device's hardware and software resources. The client device 102 also includes one or more non-transitory storage devices for storing data temporarily or permanently based on specific embodiments, applications, and / or usage scenarios.

[0040] The client device 102 includes a trusted application 108. As used in this specification, the "trusted application 108" is an application that operates within a secure environment on the client device 102 and performs certain core device services (similar to the device services performed by privileged / kernel code in the operating system). In some embodiments, the trusted application 108 can be part of the operating system 106 or a web browser, or can be implemented and / or distributed by an operating system distributor (or web browser distributor). In some embodiments, the operating system 106 can be an open-source operating system, while the trusted application 108 operates as a private / closed-source operating system. In some embodiments, the trusted application 108 can be excluded or removed from the client device 102, in which case the operations of the trusted application 108 can be performed by the operating system 106.

[0041] The trusted application 108 (or the operating system 106) can collect the application package (APK) certificate of an application (e.g., a web browser) and calculate its digital digest (a unique identifier of the certificate that is typically generated by applying a hash function to one or more fields of the certificate). This digital digest can be used to evaluate whether the application is genuine / trusted. Similarly, the trusted application 108 can calculate the cryptographic hash of the application package (APK). The APK cryptographic hash result can be used to evaluate whether the application is genuine / trusted.

[0042] The client device 102 includes a device trustworthiness client 110. When called by the operating system 106 and / or the trusted application 108, the device trustworthiness client 110 collects signals from the environment of the client device 102 alone or in cooperation with the operating system 106. Examples of signals collected by the device trustworthiness client 110 include, but are not limited to, the type of the device, the model of the device, evidence of whether the device has been rooted and / or jailbroken, the operating system running on the device, when the device was last updated, etc. These signals (collectively referred to as device trustworthiness data) can be used to determine the trustworthiness of the client device 102 (as further described with reference to Figure 2 and Figure 3 as further described).

[0043] The environment 100 further includes a trust evaluation server 130, which uses the data provided by the client device 102 to determine the trustworthiness of the client device 102 and / or the authenticity of the application 104 (as further described with reference to Figure 2 andFigure 3 (as further described).

[0044] The environment 100 further includes an application error detection server 140 that detects errors in the application 104. In some embodiments, the application error detection server 140 and the trust assessment server 130 can be separate and unrelated servers. In other embodiments, these servers can be separate instances running on a single server or system associated with a single entity. As referenced Figure 2 and Figure 3 above, the application error detection server 140 detects errors in the application based on context application data received from the client device 102 and trustworthiness determination / indications provided by / received from the trust assessment server 130. Context application data as used in this specification includes data representing the context of the provided content within the application and interacting with the content. Example context application data items include, but are not limited to, the name of the website accessed within the application, the time of accessing the website, the type of interaction of the user with the client device during the execution of the application (e.g., touch on the device screen, mouse click, swipe, scroll, keyboard input, etc.), browsing history, installed browser plugins or fonts, and the time spent viewing various parts of the content page provided within the application. Such context application data can be collected by a script when the application 104 (or native code executed within the application) accesses the content platform 150. In some embodiments, the script provides this data to the application 104 as an opaque byte array (or as another data structure that prevents the application 104 from modifying the data structure).

[0045] If the application error detection server 140 detects an error in the application 104 and / or the client device 102 based on the data received from the application 104, it can communicate a message indicating the detected error to the content platform 150, which in turn can restrict or prevent the interaction and any further actions of the application with the content platform 150. Additionally or alternatively, the application error detection server 140 can communicate the information about the detected error to the operating system 106 and / or the trusted application 108, which in turn can restrict or prevent the interaction of the application with the content platform 150.

[0046] The operations of the above components in detecting errors in the application 104 and / or the client device 102 are further described below with reference to Figure 2 the following.

[0047] Figure 2 illustrates the situation when detecting errors in the application 104 and / or the client device 102 Figure 1A swimlane diagram of example operations of the various entities / components mentioned therein and the interactions therebetween. The operations of process 200 are described below only for illustrative purposes. The operations of process 200 can be performed by any suitable device or system (e.g., any suitable data processing device). The operations of process 200 can also be implemented as instructions stored on a non-transitory computer-readable medium / storage device. Execution of the instructions causes one or more data processing devices to perform the operations of process 200.

[0048] Scripts on the content page provided within application 104 collect context application data (at 202). In some embodiments, when accessing a content page provided by content platform 150 via application 104 (e.g., a web browser) (executed on client device 102), the scripts on the content page (e.g., by invoking the application programming interface (API) of application 104) execute and collect context application data. The context application data need not be limited to the current context in which the content is presented within the application; it can also include previous contexts in which the content was presented within the application (e.g., application usage history). The scripts can package the collected context application data into an opaque byte array (or another suitable data structure that prevents entities receiving the data from modifying the data in the array).

[0049] Application 104 obtains the context application data (at 204). In some embodiments, the scripts provide the context application data to application 104 (without any prompting or in response to a request for such data from application 104). Thus, application 104 obtains the context application data from the scripts.

[0050] Application 104 blinds the context application data to generate blinded context application data (at 206). In some embodiments, application 104 can use the IETF VOPRF standard to blind the packaged context application data (e.g., an opaque byte array) to generate blinded context application data. In other embodiments, other known standards / techniques for blinding data structures can be used to generate blinded context application data. In some embodiments, application 104 can provide the blinded context application data to trusted application 108 or operating system 106 (without any prompting or in response to a request for such data from trusted application 108 or operating system 106). In other embodiments, application 104 can provide the blinded context application data to device trustworthiness client 110 (without any prompting or in response to a request for such data from device trustworthiness client 110). In some embodiments, operating system 106 or trusted application 108 can receive the context application data from the application and then blind the data.

[0051] The trusted application 108 obtains data regarding the digital certificate of the application (at 208). In some embodiments, the trusted application 108 may collect the digital certificate of the application 104 (e.g., the application package (APK) certificate) and calculate the digital digest of the certificate, or generate an APK encryption hash (or another suitable unique identifier of the certificate). The calculated digital digest, APK encryption hash, or another suitable unique identifier of the certificate constitutes the data regarding the digital certificate of the application 104. The trusted application 108 may also obtain the name of the installer package of the digital certificate, so as to inform how the application 104 is installed on the device (e.g., whether sideloaded). In some embodiments, instead of the trusted application 108, the operating system 106 may obtain the data regarding the digital certificate of the application. In some embodiments, the trusted application 108 (or the operating system 106) provides the blinded context data and the data regarding the digital certificate to the device trustworthiness client without any prompt or in response to a request for such data from the application 104.

[0052] The device trustworthiness client 110 obtains device trustworthiness data (at 210), as described in Figure 1 reference. Alternatively, the operating system 106 may obtain the device trustworthiness data instead of the device trustworthiness client 110. In some embodiments, the device trustworthiness client 110 provides the device trustworthiness data to the trusted application 108 or the operating system 106 without any prompt or in response to a request for such data from the trusted application 108 or the operating system 106.

[0053] In Figure 2 the operations 206 to 210 are shown as being executed sequentially. Although these operations may be executed in such an order in some embodiments, in other embodiments they may be executed in a different order. Alternatively, these operations may also be executed in parallel.

[0054] In some embodiments, the operating system 106, the trusted application 108, or the device trustworthiness client 110 packages the blinded context application data, the data regarding the digital certificate, and the device trustworthiness data, and provides the packaged data to the trust evaluation server 130. Alternatively, each of the application 104, the trusted application 108 / operating system 106, and the device trustworthiness client 110 may separately provide the blinded context application data, the data regarding the digital certificate, and the device trustworthiness data to the trust evaluation server 130.

[0055] The trust evaluation server 130 performs operations 212 to 218 based on the received data (i.e., blinded context application data, data regarding digital certificates, and device trustworthiness data), as further described below. The trust evaluation server 130 may perform these operations sequentially (although they do not have to be performed in the order described below) or may perform them in parallel. It should be noted that since the context application data is blinded, the trust evaluation server 130 cannot decrypt it or link it back to any specific user and their activities in the application 104. Thus, such blinding protects user privacy with respect to interactions with the trust evaluation server 130.

[0056] The trust evaluation server 130 verifies data (at 212) regarding the digital certificate of the application 104 (e.g., APK hash or digital digest). The trust evaluation server 130 includes a trusted certificate database (or another suitable data structure, such as a lookup table) that stores data regarding genuine or officially released applications. In some embodiments, the trusted certificate database includes a mapping between application digital certificates (e.g., APK certificates) and corresponding APK digital digests or APK encrypted hashes (or a suitable unique identifier of the digital certificate).

[0057] The trust evaluation server 130 determines whether the application 104 is genuine by comparing data regarding the digital certificate of the application (e.g., APK hash or digital digest) with data regarding the digital certificates of stored known, genuine applications. In some embodiments, the trust evaluation server 130 compares / looks up the digital digest or APK encrypted hash (or another suitable unique identifier of the digital certificate) of the digital certificate of the application 104 (received from the application 104) with the digital digest / APK encrypted hash (or another suitable unique identifier of the digital certificate) stored in the trusted certificate database. If a match is found based on the comparison, the trust evaluation server 130 determines that the application 104 is genuine (i.e., it is the official version of the application and / or is a known, trusted application). However, if no match is found based on the comparison, the trust evaluation server 130 determines that the application 104 is not genuine (i.e., it is not the official version of the application and / or is not a known, trusted application). In some embodiments, the trust evaluation server 130 may use a one-bit value to indicate whether the application 104 is genuine (e.g., 1 if the application 104 is genuine; 0 if the application 104 is not genuine).

[0058] The trust evaluation server 130 determines a device trustworthiness determination (at 214 and 216) based on the device trustworthiness data. In some embodiments, the trust evaluation server 130 may include a rule-based engine that uses a rule set to analyze the device trustworthiness data to determine whether the client device 102 is trustworthy. Alternatively, the trust evaluation server 130 may include a machine learning model (a supervised or unsupervised machine learning model, or another suitable statistical model) that receives the device trustworthiness data of the client device 102 and outputs the trustworthiness of the client device 102. In some embodiments, the machine learning model may be a supervised model trained using training data that includes the device trustworthiness data of multiple devices and the known, corresponding device trustworthiness of each of the multiple devices.

[0059] In some embodiments, the device trustworthiness determination (output by the rule-based engine, model, or other suitable means) may be a two-bit value. The first bit of the two-bit value indicates whether the client device has been inappropriately modified or altered (e.g., 1 indicates that the client device has not been modified / altered, while 0 indicates that the client device has been modified / altered). The second bit of the two-bit value indicates whether the profile of the client device matches the profile of a previously verified device (e.g., 1 indicates that the client device is known, while 2 indicates that the client device is unknown). Alternatively, the device trustworthiness determination may simply be a one-bit value that provides an indication of whether the client device is trustworthy. Those skilled in the art will understand that additional bits may be used to encode additional information regarding the determined trustworthiness of the device.

[0060] The trust evaluation server 130 blind-signs the context application data provided by the application 104 (at 218). In some embodiments, the trust evaluation server 130 uses the IETF VOPRF standard (or another suitable blind-signature standard or technique) to blind-sign the context application data provided by the application 104.

[0061] In some embodiments, the trust evaluation server 130 may indicate that the client device is trustworthy and / or the application is authentic by signing the blinded context application data. Conversely, the trust evaluation server may indicate that the device is untrustworthy or the application is inauthentic by simply not signing the blinded context application data. Such embodiments eliminate the need to provide additional data bits that encode information regarding the trustworthiness of the device and / or the authenticity of the application 104 determined by the trust evaluation server 130. This is because the presence of a digital signature on the blinded context data alone indicates the trustworthiness of the device and the authenticity of the application 104. Alternatively, additional bits may still be used to provide additional fine-grained details regarding the trustworthiness of the device and the authenticity of the application 104.

[0062] For purposes of illustration, the following describes Figure 2 the assumption that the trust evaluation server 130 blindly signs the context application data regardless of the device trustworthiness determination and separately provides one or more bits indicating the trustworthiness of the client device 102 and / or the authenticity of the application 104.

[0063] The trust evaluation server 130 provides to the application 104 - and the application 104 receives from the trust evaluation server 130 - the blindly signed context application data, as well as an indication (a first indication) specifying whether the client device is trustworthy and another indication (a second indication) specifying whether the application is a known, trusted application (or, in other words, whether the application is authentic). In some embodiments, the trust evaluation server 130 provides this data together in an array (or another suitable data structure), where one location in the array stores the blindly signed context application data, another location in the array stores the indication specifying whether the client device is trustworthy, and another location in the array stores the indication specifying whether the application is a known, trusted application. In some embodiments, the trust evaluation server 130 blindly signs the context application data using different signature keys based on different levels of the device trustworthiness and / or the application authenticity. In such embodiments, the trust evaluation server 130 conveys the first indication and the second indication by creating a digital signature in such a way that the signature is verified by one of a number of possible keys. For example, if the first indication and the second indication each have two possibilities, there are four possible combinations of the first indication and the second indication. In such a case, the trust evaluation server 130 can use one of 4 possible keys to generate the signature to be verified.

[0064] After receiving the data from the trust evaluation server 130, the application 104 verifies the blind signature (at 220). If the application 104 determines that the blind signature is not a valid signature signed by the trust evaluation server 130, the application 104 determines that the data received from the trust evaluation server has been corrupted and is thus unreliable. In this case, the error detection process stops. In this case, the application error detection server 140 determines that the application 104 and / or the client device 102 has an error. On the other hand, if the application 104 determines that the blind signature is a valid signature signed by the trust evaluation server 130, the application 104 unblinds the data (at 222).

[0065] If Application 104 determines that the context application data (also referred to as the first data item) for which the blinding has been removed does not match the context application data previously provided to the trust evaluation server 130, Application 104 determines that the data received from the trust evaluation server 130 is in error or has been otherwise corrupted. In such a case, the error detection process of Process 200 stops. On the other hand, if Application 104 determines that the context application data for which the blinding has been removed matches the context application data previously provided to the trust evaluation server 130, the process proceeds to Operation 224 (described below).

[0066] Application 104 provides the application error detection server 140 with the digital signature on the first data item, the first indication, the second indication, and the first data item for which the blinding has been removed at Operation 222 (at 224). When providing this data, Application 104 requests that the application error detection server 140 detect errors within Application 104 and / or the client device 102. It should be noted that by providing only the first indication and the second indication, the application error detection server 140 does not receive any device trustworthiness data that was previously provided to the trust evaluation server 130, thus protecting the privacy of the device trustworthiness data in the interaction with the application error detection server 130. Instead, a minimal amount of device and application trustworthiness / authenticity information is provided to the application error detection server 130 only in the form of the first indication and the second indication. Since the first indication and the second indication do not provide any information unique to the device or the application, the application error detection server cannot learn any specific details about the application or the client device beyond these indications. This means that even if the application error detection server and the trust evaluation server collude in an attempt to learn information about the user, this is not possible because the servers will not be able to match the context application data (known to the error detection server) to the digital certificate data and device trustworthiness data about the application (known to the trust evaluation server) for any given user.

[0067] In an implementation in which the trusted application 108 or the operating system 106 performs the blinding process on the context application data, the trust evaluation server 130 provides the blinded signed context application data to the trusted application 108 / operating system 106, along with an indication (the first indication) specifying that the client device is trustworthy and another indication (the second indication) specifying that the application is a known, trusted application (or in other words, that the application is authentic). In such an implementation, the trusted application 108 / operating system 106 verifies the blinded signature, removes the blinding from the data, and compares the unblinded data with the context application data. In such an implementation, the trusted application 108 / operating system 106 provides the application error detection server 140 with the digital signature on the first data item, the first indication, the second indication, and the first data item for which the blinding has been removed at Operation 222.

[0068] After receiving data from application 104 (or trusted application 108 / operating system 106), application error detection server 140 verifies the blinded signature (at 226). In an implementation that uses the IETF VOPRF blinded signature standard, application error detection server 140 interacts with trust evaluation server 130 to confirm the signature. This is because VOPRF blinded signatures cannot be publicly verified. In such an implementation, application error detection server 140 communicates with trust evaluation server 130 to confirm the blinded signature. If trust evaluation server 130 determines that the signature is valid, it provides an indication specifying that the digital signature is valid. On the other hand, if trust evaluation server 130 determines that the signature is invalid, it provides an indication specifying that the digital signature is invalid. In some implementations, instead of the VOPRF standard, a publicly verifiable digital signature algorithm can be used, in which case application error detection server 140 itself can verify whether the digital signature is valid (without having to contact trust evaluation server 130 (i.e., the entity that generated the digital signature)).

[0069] If application error detection server 140 determines that the blinded signature is not a valid signature signed by trust evaluation server 130, application error detection server 140 determines that the data received from application 104 has been corrupted and is thus unreliable. In such a case, application error detection server 140 determines that application 104 and / or client device 102 has an error. On the other hand, if application error detection server 140 determines that the blinded signature is a valid signature signed by trust evaluation server 130, the process continues to operation 228 (described below).

[0070] Application error detection server 140 determines whether application 104 has any errors (at 228) based on the first indication, the second indication, and the context application data. In some implementations, application error evaluation server 140 can include a rule-based engine that uses a rule set to process the data received from application 104 to determine whether any errors exist in application 104. Alternatively, application error evaluation server 140 can include a machine learning model (e.g., a supervised or unsupervised machine learning model, or another suitable statistical model) that receives the data received from application 104 at operation 224 and outputs an indication specifying whether the application has any errors (i.e., a third indication). In some implementations, the machine learning model can be a supervised model trained using training data that includes the first indication, the second indication, and the context application data for each of a plurality of devices, as well as the known corresponding indications specifying whether errors exist in the application.

[0071] In any of the embodiments described in the above paragraphs, data regarding the trustworthiness of the client device 102 and the authenticity of the application 104 can be taken into account in the final determination of the presence of errors in the application 104 and / or the client device 102. For example, if the first indication and the second indication respectively specify that the client device 102 is trustworthy and the application 104 is authentic, the application error detection server 140 can reduce the likelihood of an error existing in the application 104. As another example, if the first indication and the second indication respectively specify that the client device 102 is untrustworthy and the application 104 is unauthentic, the application error detection server 140 can increase the likelihood of an error existing in the application 104. As a result, the error detection of the application error detection server 140 is more robust than conventional techniques that do not consider device trustworthiness and application authenticity when determining application errors.

[0072] In summary, relative to conventional systems, Figure 1 the above operations of the various components and their interactions provide a more robust indication of the presence of errors in the application while protecting the privacy of the user (by exposing the least amount of information to the application error detection server 140 and the trust assessment server 130, thus minimizing or possibly even eliminating any user fingerprint).

[0073] Figure 3 is a flowchart of an example process 300 for detecting errors in an application 104 executed on a client device 102. The operations of process 300 are described below as being performed by the components of the system described and shown in Figure 1 The operations of process 300 are described below for illustrative purposes only. The operations of process 300 can be performed by any suitable device or system, e.g., any suitable data processing device. The operations of process 300 can also be implemented as instructions stored on a non-transitory computer-readable medium. Execution of the instructions causes one or more data processing devices to perform the operations of process 300.

[0074] (Executed on the client device 102) The application 104 obtains context application data (at 302). As referred to in Figure 1 and Figure 2 When using the application 104 to access a content page provided by the content platform 150, a script executes and collects context application data, which represents the context of providing and interacting with content within the application.

[0075] The application 104 blinds the context application data to generate blinded context application data (at 304). As referred to in Figure 1 and Figure 2As described above, the application 104 blinds the context application data (which can be packaged into an opaque byte array) according to the IETF VOPRF standard (or another suitable standard or blinded signature technique) to generate blinded context application data.

[0076] The operating system 106 or the trusted application 108 on the client device 102 obtains data on the digital certificate of the application and the device trustworthiness data (at 306). As referenced Figure 1 and Figure 2 As described above, the trusted application 108 (or the operating system 106) of the client device 102 obtains data on the digital certificate of the application 104, which may include the APK certificate of the application, the digital digest, the APK encrypted hash (or another suitable unique identifier) corresponding to the APK certificate or the APK binary itself, and the installer package name of the certificate. Also as referenced Figure 1 and Figure 2 As described above, the device trustworthiness client 110 (or the operating system 106) of the client device 102 obtains the device trustworthiness data, and the device trustworthiness data includes data that can be used to evaluate the trustworthiness of the client device (e.g., device type, operating system installed on the device, etc.).

[0077] The trust evaluation server 130 is provided with the blinded context application data, the data on the digital certificate (e.g., APK hash), and the device trustworthiness data (at 308). As referenced Figure 1 and Figure 2 As described above, the trusted application 108, the device trustworthiness client 110, or the operating system 106 packages the data on the digital certificate (or APK hash) together with the device trustworthiness data and the blinded context application data (which is generated in operation 304) and provides this data to the trust evaluation server 130.

[0078] The application 104 receives a data set from the trust evaluation server 130 (at 310). As referenced Figure 1 and Figure 2 As described above, the trust evaluation server 130 uses the data on the digital certificate (e.g., APK digest or APK hash) and the device trustworthiness data (received in operation 308) to determine whether the client device 102 is trustworthy and whether the application is a known and trusted application. Additionally, the trust evaluation server 130 also digitally signs the first data item, which may be the blinded context application data (also referenced Figure 1 and Figure 2is described). The trust evaluation server 130 provides to the application 104 - and the application 104 receives from the trust evaluation server 130 - a data set that includes (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is a known and trusted application, and (3) a digital signature of the trust evaluation server on the first data item (as referenced Figure 1 and Figure 2 further described).

[0079] The application 104 verifies the digital signature on the first data item in the data set (at 312). As referenced Figure 1 and Figure 2 described, the application 104 verifies that the digital signature on the first data item is a valid signature of the trust evaluation server 130.

[0080] In response to verifying the digital signature on the first data item, the application unblinds the first data item to obtain the unblinded first data item (at 314). In some embodiments, the application 104 unblinds the first data item included in the data set (received from the trust evaluation server 130 at operation 310).

[0081] The application 104 confirms that the unblinded first data item matches the context application data obtained by the application at operation 302 (at 316). As referenced above Figure 2 described, the application 104 compares the unblinded first data item with the context application data obtained at operation 302. After finding a match, the application 104 confirms that the unblinded first data item is in fact the context application data that was previously sent to the trust evaluation server 130.

[0082] In response to confirming that the unblinded first data item matches the context application data, the application provides to the application error detection server 140 the digital signature on the first data item, the first indication, the second indication, and the unblinded first data item (at 318).

[0083] The application 104 receives from the application error detection server 140 a third indication specifying that the application has no errors (at 320). As referenced Figure 1 and Figure 2As described above, the application error detection server 140 uses the data it receives from the application 104 in operation 318 to determine whether the application 104 and / or the client device 102 have any errors. If the application error detection server 140 determines that the application 104 and / or the client device 102 have an error, it provides (and the application 104 receives) an indication specifying that the application (and / or the client device) has an error. On the other hand, if the application error detection server 140 determines that the application has no error, it provides (and the application 104 receives) an indication specifying that the application (and / or the client device 102) has no error.

[0084] In some alternative embodiments, the operation can be modified by not sending the blinded context application data to the trust evaluation server to reduce some potential latency. Except for some operation differences described below, such embodiments have the same operations as those described in the reference Figure 3 For the sake of brevity, only the operation differences are described below in the description of these alternative embodiments; however, it should be noted that the remaining operations of Figure 3 and their corresponding descriptions are used in these embodiments (and for the avoidance of any doubt, those operations are incorporated herein by reference). Figure 3

[0085] Figure 3 In such alternative embodiments, the application 104 still obtains the context application data, but it does not blind the data. Instead, the application 104 generates a random data set (e.g., random numbers), and blinds the random data set to generate a blinded random data set (which replaces operation 304 in the description above Figure 3 ). The blinded random data set is provided to the trust evaluation server 130 (instead of providing the blinded context application data as described in operation 306). In addition, the trust evaluation server 130 generates a digital signature on the blinded random data set (instead of generating a digital signature on the blinded context application data as described in operation 310 in the reference above Figure 3 ). The application 104 de - blinds the blinded data to confirm that it is the same as the previously generated random data set. After confirming this, the application provides the context application data together with the digital signature, the first indication, and the second indication (as in operation 318 in Figure 3 ), and all of these data are used by the application error detection server 140 to determine whether the application 104 (and / or the client device 102) has any errors (as in operation 320 in ).

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

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

[0088] The storage device 430 is capable of providing mass storage for the system 400. In some embodiments, the storage device 430 is a computer-readable medium. In various different embodiments, the storage device 430 can include, for example, a hard disk device, an optical disk device, a storage device shared by multiple computing devices (e.g., a cloud storage device) via a network, or some other mass storage device.

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

[0090] Although an example processing system has been described in Figure 4 , embodiments of the subject matter and functional operations described in this specification can be implemented using other types of digital electronic circuitry or using computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or using a combination of one or more of them.

[0091] Embodiments of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in a combination of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more modules of one or more computer programs, i.e., computer program instructions, encoded on a computer storage medium (or media) for execution by, or to control the operation of, a data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to a suitable receiver apparatus for execution by the data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, although a computer storage medium is not a propagated signal, a computer storage medium can be the source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

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

[0093] The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system on a chip, or multiple programmable processors, computers, systems on a chip, or combinations of the foregoing. The apparatus can include special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). The apparatus can also include code that creates an execution environment for the computer program, e.g., code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and the execution environment can implement various different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0094] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may or may not correspond to a file in a file system. The program can be stored in a part of a file that holds other programs or data (such as one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (such as files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0095] The processes and logical flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logical flows can also be performed by, and the apparatus can also be implemented as, special-purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0096] By way of example, processors suitable for executing a computer program include both general and special purpose microprocessors. In general, a processor will receive instructions and data from a read only memory or a random access memory or both. Essential elements of a computer are a processor for performing actions in accordance with the instructions and one or more memory devices for storing the instructions and data. In general, a computer will also include, or be operatively coupled to receive data from, or transfer data to, one or more mass storage devices for storing data (such as magnetic disks, magneto-optical disks, or optical disks). However, a computer need not have such devices. In addition, a computer may be embedded in another device, such as a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (such as a Universal Serial Bus (USB) flash drive), etc. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, by way of example including: semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

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

[0098] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component (such as a data server), or includes a middleware component (such as an application server), or includes a front-end component (such as a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described in this specification), or includes any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication such as a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an internetwork (such as the Internet), and a peer-to-peer network (such as an ad hoc peer-to-peer network).

[0099] The computing system can include clients and servers. The clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on respective computers and having a client-server relationship to each other. In some embodiments, the server sends data (such as an HTML page) to the client device (for example, for the purpose of displaying data to a user interacting with the client device and receiving user input from the user interacting with the client device). Data generated at the client device (such as the result of a user interaction) can be received at the server.

[0100] Although this specification contains many details of specific embodiments, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of a particular invention. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented separately or in any suitable sub-combination in multiple embodiments. In addition, although the features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excluded from the combination, and the claimed combination can be directed to a sub-combination or variation of a sub-combination.

[0101] Similarly, although operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system components in the above embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0102] Accordingly, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the acts recited in the claims can be performed in a different order and still achieve the desired result. In addition, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method, comprising: obtaining context application data representing a context by an application executed on a client device, providing content and interacting with the content within the context within the application; blinding the context application data by the application to generate blinded context application data; obtaining data on a digital certificate of the application and device trustworthiness data including data capable of being used to evaluate the trustworthiness of the client device; providing the blinded context application data, the data on the digital certificate, and the device trustworthiness data to a trust evaluation server; receiving a data set from the trust evaluation server, the data set including (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature on a first data item generated by the trust evaluation server; verifying the digital signature on the first data item; in response to verifying the digital signature on the first data item, unblinding the first data item by the application to obtain an unblinded first data item; confirming that the unblinded first data item matches the context application data; in response to confirming that the unblinded first data item matches the context application data, providing the digital signature on the first data item, the first indication, the second indication, and the unblinded first data item to an application error detection server; and receiving a third indication from the application error detection server specifying that the application has no errors.

2. The computer-implemented method according to claim 1, wherein, the trust evaluation server is configured to: determine that the client device is trustworthy based on the device trustworthiness data and determine that the application is genuine by comparing the data on the digital certificate of the application with the data on the digital certificates of known genuine applications; and provide the first indication specifying that the client device is trustworthy and the second indication specifying that the application is a known application to the client device.

3. The computer-implemented method according to claim 1, wherein, the data on the digital certificate of the application includes: a digital digest of the application package APK of the application; or an encrypted hash of the APK of the application.

4. The computer-implemented method according to claim 1, wherein, obtaining data on a digital certificate of the application and device trustworthiness data including device data capable of being used to evaluate the trustworthiness of the client device includes: obtaining data on a digital certificate of the application through a trusted application or operating system executed on the client device; and obtaining device trustworthiness data through a device trustworthiness client application executed on the client device.

5. The computer-implemented method according to claim 1, wherein, the first indication specifying that the client device is trustworthy is a two-bit value, wherein: The first of the two bits indicates that the client device has not been improperly modified or altered; and The second of the two bits indicates that the profile of the client device matches the profile of a previously authenticated device.

6. The computer-implemented method according to claim 1, wherein the application error detection server is configured to: in response to receiving the digital signature on the first data item, the first indication, the second indication, and the context application data, communicate with the trust evaluation server to authenticate the digital signature, wherein the digital signature is an IETF VOPRF digital signature and can be authenticated by the trust evaluation server that initially generated the digital signature; and receive from the trust evaluation server a fourth indication specifying that the digital signature is valid.

7. A computer-implemented method, comprising: generating a random data set by an application executed on a client device; blinding the random data set by the application to generate a blinded random data set; obtaining data on a digital certificate of the application and device trustworthiness data including device data that can be used to evaluate the trustworthiness of the client device; providing the blinded random data set, the data on the digital certificate, and the device trustworthiness data to a trust evaluation server; receiving from the trust evaluation server a first data set, the first data set including: (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature on a first data item generated by the trust evaluation server; verifying the digital signature on the first data item; in response to verifying the digital signature on the first data item, unblinding the first data item by the application to obtain an unblinded first data item; confirming that the unblinded first data item matches the random data set; in response to confirming that the unblinded first data item matches the random data set, obtaining, by the application, context application data representing a context in which content is provided within and interacted with within the application; providing the digital signature on the first data item, the first indication, the second indication, and the context application data to an application error detection server; and receiving from the application error detection server a third indication specifying that the application has no errors.

8. A system comprising a client device, the client device comprising: one or more memory devices that store instructions; and one or more data processing devices configured to interact with the one or more memory devices and, after executing the instructions, perform operations including the following: obtaining, by an application executed on the client device, context application data representing a context in which content is provided within and interacted with within the application; blinding the context application data by the application to generate blinded context application data; Obtain data on the digital certificate of the application and device trustworthiness data including data that can be used to evaluate the trustworthiness of the client device; Provide the blinded context application data, data on the digital certificate, and the device trustworthiness data to a trust evaluation server; Receive a data set from the trust evaluation server, the data set including (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature on a first data item generated by the trust evaluation server; Verify the digital signature on the first data item; In response to verifying the digital signature on the first data item, unblind the first data item through the application to obtain the unblinded first data item; Confirm that the unblinded first data item matches the context application data; In response to confirming that the unblinded first data item matches the context application data, provide the digital signature on the first data item, the first indication, the second indication, and the unblinded first data item to an application error detection server; And Receive a third indication from the application error detection server specifying that the application has no errors.

9. The system according to claim 8, wherein, the trust evaluation server is configured to: Determine that the client device is trustworthy based on the device trustworthiness data and determine that the application is genuine by comparing the data on the digital certificate of the application with the data on the digital certificates of known genuine applications; And Provide the first indication specifying that the client device is trustworthy and the second indication specifying that the application is a known application to the client device.

10. The system according to claim 8, wherein, the data on the digital certificate of the application includes: The digital digest of the application package APK of the application; or The encrypted hash of the APK of the application.

11. The system according to claim 8, wherein, Obtaining data on the digital certificate of the application and device trustworthiness data including device data that can be used to evaluate the trustworthiness of the client device includes: Obtain data on the digital certificate of the application through a trusted application or operating system executed on the client device; and Obtain device trustworthiness data through a device trustworthiness client application executed on the client device.

12. The system according to claim 8, wherein, The first indication specifying that the client device is trustworthy is a two-bit value, where: The first bit in the two-bit value indicates that the client device has not been improperly modified or altered; and The second bit in the two-bit value indicates that the configuration file of the client device matches the configuration file of a previously verified device.

13. The system according to claim 8, wherein, the application error detection server is configured to: In response to receiving the digital signature on the first data item, the first indication, the second indication, and the context application data, communicate with the trust evaluation server to verify the digital signature, where the digital signature is an IETF VOPRF digital signature and can be verified by the trust evaluation server that initially generated the digital signature; and Receive from the trust evaluation server a fourth indication specifying that the digital signature is valid.

14. A non-transitory computer-readable medium storing instructions that, when executed by one or more data processing devices of a client device, cause the one or more data processing devices to perform operations, the operations include:[[]] Obtain context application data representing a context through an application executed on the client device, provide content within the context in the application, and interact with the content; Blind the context application data through the application to generate blinded context application data; Obtain data on a digital certificate of the application and device trustworthiness data including data that can be used to evaluate the trustworthiness of the client device; Provide the blinded context application data, the data on the digital certificate, and the device trustworthiness data to a trust evaluation server; Receive from the trust evaluation server a data set including (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature on a first data item generated by the trust evaluation server; Verify the digital signature on the first data item; In response to verifying the digital signature on the first data item, unblind the first data item through the application to obtain an unblinded first data item; Confirm that the unblinded first data item matches the context application data; In response to confirming that the unblinded first data item matches the context application data, provide the digital signature on the first data item, the first indication, the second indication, and the unblinded first data item to an application error detection server; and Receive from the application error detection server a third indication specifying that the application has no errors.

15. The non-transitory computer-readable medium according to claim 14, wherein, the trust evaluation server is configured to:[[]] Determine that the client device is trustworthy based on the device trustworthiness data and determine that the application is genuine by comparing the data on the digital certificate of the application with the data on the digital certificates of known genuine applications; and Provide the first indication specifying that the client device is trustworthy and the second indication specifying that the application is a known application to the client device.

16. The non-transitory computer-readable medium according to claim 14, wherein, the data on the digital certificate of the application includes:[[]] a digital digest of the application package APK of the application; or an encrypted hash of the APK of the application.

17. The non-transitory computer-readable medium according to claim 14, wherein, obtaining data of a digital certificate regarding the application and device trustworthiness data including device data that can be used to evaluate the trustworthiness of the client device includes: obtaining data of a digital certificate regarding the application through a trusted application or operating system executed on the client device; and obtaining device trustworthiness data through a device trustworthiness client application executed on the client device.

18. The non-transitory computer-readable medium according to claim 14, wherein, the first indication specifying that the client device is trustworthy is a two-bit value, wherein: the first bit in the two-bit value indicates that the client device has not been improperly modified or altered; and the second bit in the two-bit value indicates that the configuration file of the client device matches the configuration file of a previously verified device.

19. The non-transitory computer-readable medium according to claim 14, wherein, the application error detection server is configured to: communicate with the trust evaluation server to verify the digital signature in response to receiving the digital signature on the first data item, the first indication, the second indication, and the context application data, wherein the digital signature is an IETF VOPRF digital signature and can be verified by the trust evaluation server that initially generated the digital signature; and receive a fourth indication from the trust evaluation server specifying that the digital signature is valid.

20. A non-transitory computer-readable medium storing instructions that, when executed by one or more data processing devices of a client device, cause the one or more data processing devices to perform operations, the operations including: generating a random data set through an application executed on the client device; blinding the random data set through the application to generate a blinded random data set; obtaining data of a digital certificate regarding the application and device trustworthiness data including device data that can be used to evaluate the trustworthiness of the client device; providing the blinded random data set, the data regarding the digital certificate, and the device trustworthiness data to a trust evaluation server; receiving from the trust evaluation server a first data set including: (1) a first indication specifying that the client device is trustworthy, (2) a second indication specifying that the application is genuine, and (3) a digital signature on a first data item generated by the trust evaluation server; verifying the digital signature on the first data item; in response to verifying the digital signature on the first data item, unblinding the first data item through the application to obtain an unblinded first data item; confirming that the unblinded first data item matches the random data set; in response to confirming that the unblinded first data item matches the random data set, obtaining, through the application, context application data representing a context in which content is provided and interacted with within the application; Provide the digital signature on the first data item, the first indication, the second indication, and the context application data to the application error detection server; and Receive from the application error detection server a third indication specifying that the application has no errors.

Citation Information

Patent Citations

  • Digital rights management using trusted processing techniques

    CN101573936A

  • Device identification scoring

    US20150089568A1