System and method for authentication control for content delivery

Abstract

The present disclosure provides systems and methods for authentication control of content delivery. The method includes receiving a request for a content item from a computing device, the request including a security token associated with the computing device and an identifier of a domain group, identifying the domain group from the identifier, and retrieving a security key associated with the domain group. The method also includes decrypting a signature of the security token, identifying an authentication string, determining that the authentication string matches a server authentication string, and identifying a characteristic of the security token. The characteristic of the security token includes a confidence score. The method further includes comparing the confidence score of the security token to a threshold, determining that the confidence score does not exceed the threshold, and preventing the content from being sent to the computing device.

Description

[0001] This application is a divisional application of the invention patent application filed on September 3, 2019, with application number 201980006218.9 and entitled "System and method for authentication control of content delivery". Background Technology

[0002] People can shop online instead of going to physical stores. While people visit different web pages and domains to shop, in many cases, third parties associated with those web pages and domains can provide content to the computing devices people use to access those web pages. Third parties can provide content in response to requests from computing devices. In some cases, malicious parties may send requests for content during cyberattacks (e.g., denial-of-service attacks, distributed denial-of-service attacks, replay attacks, timed attacks, etc.).

[0003] For various reasons, including security policies imposed by the operating system, third parties, such as content providers, may not have access to information about the computing device to which they are providing content. As a result, third parties may be unable to determine whether the device requesting content is a user browsing the internet or a malicious party. Therefore, malicious parties may use fraudulent requests and execute various types of cyberattacks to trick third parties into providing content to them. Thus, third parties may want to verify that the device is associated with a legitimate user. However, in many cases, if a device or user attempts to provide authentication information or other data indicating that the computing device is not involved in a cyberattack or malicious party, the computing device may unintentionally disclose more information about the computing device or the domain associated with it than intended. Worse still, in some cases, malicious parties may eavesdrop on or intercept communications between the computing device and third parties or content providers, and may gain access to the user's personal information or information about the computing device. Summary of the Invention

[0004] A method for authentication control of content delivery is disclosed, comprising: receiving (402) a request for a content item from a computing device (218) by a server device (232), the request including a security token and its domain associated with a central server; retrieving (404) a security key of the central server from the domain associated with the central server or a database of the server device by the server device; decrypting (406) a signature of the security token by the server device using the security key; identifying (408) an authentication string associated with the security token from the decrypted signature in the security token by the server device; determining (410) that the authentication string matches an expected authentication string by the server device; in response to determining that the authentication string matches an expected authentication string, identifying (414) a confidence score of the security token by the server device, the confidence score indicating the likelihood that the computing device is not associated with a malicious entity; determining (416) that the confidence score does not exceed a threshold; and in response to determining that the confidence score does not exceed the threshold, blocking the transmission of the content item to the computing device by the server device.

[0005] A server device (232) for authentication control of content delivery is disclosed, comprising: communicating with a first client device (218) of a plurality of client devices; and a processor (234) configured to: receive, via a network interface and from a first computing device, a request for a content item, the request including a security token and its domain associated with a central server; retrieve a security key of a central server from a database of the domain associated with the central server or the server device; decrypt a signature of the security token using the security key; identify an authentication string from the decrypted signature in the security token, the authentication string being associated with the security token; identify the authentication string from the decrypted signature in the security token, the authentication string being associated with the security token; determine that the authentication string matches an expected authentication string; in response to determining that the authentication string matches an expected authentication string, identify a confidence score of the security token, the confidence score indicating the likelihood that the computing device is not associated with a malicious entity; determine that the confidence score does not exceed a threshold; and in response to the determination that the confidence score does not exceed the threshold, block the transmission of the content item to the computing device.

[0006] The systems and methods discussed herein provide a method for authentication control of content delivery, enabling a content server to determine whether a request for content originates from a computing device associated with a malicious entity without exposing information about the computing device or user. When a computing device accesses various web pages, creates user accounts associated with those pages, logs into those user accounts, and / or has authenticated communication via those web pages, the server associated with the web page can maintain a confidence score associated with the computing device. This confidence score indicates the degree of certainty that the computing device is not associated with a malicious entity (e.g., associated with a user accessing the web page for content rather than performing a cyberattack), and each server possesses this degree of certainty. In some implementations, when the computing device is determined to be unrelated to a malicious entity with a degree of certainty exceeding a threshold, the web page server can sign a security token with a group signature associated with a set of servers (e.g., a server association) and store the security token in the computing device's browser. This security token includes the identifiers of the set of servers associated with the group signature.

[0007] In some implementations, to protect the privacy of the computing device sending the content request, the server providing the security token to the requesting computing device can provide the computing device with a certificate associated with a subgroup of a server association, which the computing device can use to anonymously sign the request. The server can divide the computing devices with information about them into subgroups (e.g., subgroups of a server association). The server can associate a group signature with each subgroup. When it is determined with a higher-than-threshold certainty that the requesting computing device is not malicious, the server can provide each subgroup of computing devices with a subgroup's certificate, allowing the computing devices to sign requests that can only be verified using a public encryption key associated with the group signature. In the content request, the computing device can include both the server association's group signature and the subgroup's group signature. Because the signature does not include information that individually identifies the computing device or the server providing the signature (besides information about the server association to which the signing server is associated), the content server may not be able to identify which specific server provided the security token or which computing device sent the request.

[0008] When accessing another webpage, a computing device can send a content request to a content server that includes a security token. The content server can determine if the security token is valid (e.g., by using a security key associated with this set of servers to decrypt the security token's signature and verifying successful decryption). If the security token is valid, the content server can determine if it meets a certain criterion (e.g., whether the security token's confidence score exceeds a threshold). If the security token is valid and meets the criterion, the content server can serve the content to the requesting computing device. If the security token is invalid or does not meet the criterion, the content server can prevent content from being sent to the computing device (e.g., not serving any content to the computing device).

[0009] Advantageously, by implementing the systems and methods discussed herein, a computing device can provide a content server with verification received from servers of various websites, indicating that the computing device is legitimate or not associated with a malicious attacker. The computing device can do this without providing identification information about the requesting computing device or the server to which the verification is provided. While the content server can identify the server group associated with a group signature received by the content server, the server group may include many servers, and the content server will not be able to identify an individual server from among these many servers based on the group signature of the group. Furthermore, to anonymize the computing device and prevent it from being individually identified by the content server, the computing device can sign the security token with a second set of signatures associated with a subset of computing devices associated with the server (e.g., those that have visited the website associated with the server). This second set of signatures keeps the requesting computing device anonymous, making it impossible for the content server to identify the computing device from content requests containing the same signature.

[0010] One aspect described herein describes a method for authentication control of content delivery. The method may include: receiving a request for a content item from a computing device by a server device, the request including a security token associated with the computing device and an identifier of a domain group associated with the security token; identifying the domain group by the server device based on the identifier; retrieving a security key associated with the domain group by the server device; decrypting a signature of the security token by the server device using the security key; identifying an authentication string associated with the security token by the server device; determining that the authentication string matches a server authentication string; and, in response to determining that the authentication string matches the server authentication string, identifying features of the security token by the server device, wherein the features of the security token include a confidence score indicating the likelihood that the computing device is not a malicious entity. The method may further include: comparing the confidence score of the security token with a threshold by the server device; determining that the confidence score does not exceed the threshold; and, in response to determining that the confidence score does not exceed the threshold, blocking the delivery of content to the computing device by the server device.

[0011] In some implementations, the threshold may be associated with the identification of the domain group. Comparing the confidence score of the security token with the threshold may further include: in response to identifying the domain group based on the identifier, the server device identifies a threshold associated with the identification of the domain group; and comparing the confidence score with the threshold.

[0012] In some implementations, the confidence score may be calculated by a server associated with the domain group in response to an identifier of browsing activity of the computing device on a website associated with at least one domain in the domain group. In some implementations, the identifier of browsing activity may include the number of times an account is created on the website, the number of times the user logs into the website, the number of times the user visits the website, the number of interactions on the website, or previous instances of authenticated communication.

[0013] In some embodiments, the method may further include: receiving a second request for second content from a second computing device by a server device, the second request including a second security token associated with the second computing device and a second identifier of a second domain group associated with the second security token; identifying the second domain group from the second identifier by the server device; retrieving a second security key associated with the second domain group by the server device; decrypting a second signature of the second security token by the server device using the second security key; identifying a second authentication string associated with the second security token by the server device; and determining that the second authentication string matches a second server authentication string. The method may further include: in response to determining that the second authentication string matches the second server authentication string, identifying a second feature of the security token by the server device. The second feature of the security token may include a second confidence score indicating a second probability that the second computing device is not associated with a malicious entity. The method may further include: comparing the second confidence score of the second security token with a second threshold by the server device; determining that the second confidence score exceeds the second threshold by the server device; and sending the content to the second computing device by the server device in response to determining that the second confidence score exceeds the second threshold.

[0014] In some implementations, the second authentication string may include a timestamp. The method may further include: having a server device identify the time of the timestamp; having the server device compare the time with a current time; having the server device determine the length of time between the time and the current time; having the server device compare the length of time with a third threshold; and having the server device determine that the length of time is less than the third threshold. In response to determining that the length of time is less than the third threshold, the content may be further sent to a second computing device.

[0015] In some embodiments, the method may further include: receiving a second request for second content from a second computing device by a server device, the second request including a plurality of second security tokens associated with the second computing device, each second security token being associated with a different domain group associated with a second identifier. The method may further include: for each of the plurality of second security tokens: identifying a second domain group from the second identifier by the server device; retrieving a second security key associated with the second domain group by the server device; decrypting a second signature of the second security token by the server device using the second security key; identifying a second authentication string associated with the second security token by the server device; determining that the second authentication string matches a second server authentication string; and incrementing a counter by the server device in response to determining that the second authentication string matches the second server authentication string. The method may further include: comparing the count with the second threshold by the server device; determining that the count exceeds the second threshold by the server device; and sending content to the second computing device by the server device in response to determining that the count exceeds the threshold.

[0016] In some implementations, the request may further include a second security key. The method may also include: retrieving the second security key from the request and by the server device in response to an authentication string matching a server authentication string; decrypting a second signature of the security token using the second security key by the server device; identifying a second authentication string associated with the security token by the server device; and determining that the second authentication string matches a second server authentication string by the server device. In response to determining that the second authentication string matches a second server authentication string, a confidence score may be further performed.

[0017] In some implementations, the second security key may be associated with a subgroup of the domain group. The subgroup of the domain group may be associated with multiple computing devices associated with domains within the domain group. In some implementations, the second security key is associated with a computing device.

[0018] Another aspect described herein describes a server device for authentication control of content delivery. The server device may include a network interface communicating with a first client device among a plurality of client devices, and a processor. The processor may be configured to: receive, via the network interface and from a first computing device, a request for a content item, the request including a security token associated with the computing device and an identifier of a domain group associated with the security token; identify the domain group based on the identifier; retrieve a security key associated with the domain group; decrypt a signature of the security token using the security key; identify an authentication string associated with the security token; determine that the authentication string matches a server authentication string; and, in response to determining that the authentication string matches the server authentication string, identify features of the security token, wherein the features of the security token include a confidence score indicating the likelihood that the computing device is not a malicious entity. The processor may also be configured to: compare the confidence score of the security token with a threshold; determine that the confidence score does not exceed the threshold; and, in response to determining that the confidence score does not exceed the threshold, prevent content from being sent to the computing device.

[0019] In some implementations, the threshold may be associated with the identification of the domain group, and wherein the processor compares the confidence score of the security token with the threshold by: identifying the threshold associated with the identification of the domain group; and comparing the confidence score with the threshold.

[0020] In some implementations, the confidence score may be calculated by a server associated with the domain group in response to identifiers of browsing activity of a computing device on a website associated with at least one domain in the domain group. In some implementations, identifiers of browsing activity may include the number of times an account was created on the website, the number of times the user logged into the website, the number of times the user interacted on the website, and the number of times the user accessed the website.

[0021] In some embodiments, the processor may further be configured to: receive, via a network interface and from the second computing device, a second request for a second content item, the second request including a second security token associated with the second computing device and a second identifier of a second domain group associated with the second security token; identify the second domain group from the second identifier; retrieve a second security key associated with the second domain group; decrypt a second signature of the second security token using the second security key; identify a second authentication string associated with the second security token; determine that the second authentication string matches a second server authentication string; and, in response to determining that the second authentication string matches the second server authentication string, identify a second feature of the security token. The second feature of the security token may include a second confidence score indicating a second probability that the second computing device is not associated with a malicious entity. The processor may further be configured to: compare the second confidence score of the second security token with a second threshold; determine that the second confidence score exceeds the second threshold; and, in response to determining that the second confidence score exceeds the second threshold, send content to the computing device via the network interface and to the second computing device.

[0022] In some implementations, the second authentication string may include a timestamp. The processor may also be configured to: identify the time of the timestamp; compare the time with the current time; determine the length of time between the time and the current time; compare the length of time with the third threshold; and determine that the length of time is less than the third threshold. Further in response to determining that the length of time is less than the second threshold, the processor may send the content to a second computing device.

[0023] In some implementations, the processor may also be configured to receive a second request for a second content item from the second computing device via a network interface. The second request may include a plurality of second security tokens associated with the second computing device, each second security token being associated with a different domain group associated with a second identifier. For each of the plurality of second security tokens, the processor may be configured to: identify a second domain group from the second identifier by the server device; retrieve a second security key associated with the second domain group; decrypt a second signature of the second security token using the second security key; identify a second authentication string associated with the second security token; determine that the second authentication string matches a second server authentication string; and increment a counter in response to determining that the second authentication string matches the second server authentication string. The processor may also be configured to: compare the count with a threshold; determine that the count exceeds the threshold; and, in response to determining that the count exceeds the threshold, send content to the second computing device via the network interface.

[0024] In some implementations, the request may also include a second security key. The processor may also be configured to: retrieve the second security key from the request in response to a match between the authentication string and the server authentication string; decrypt the second signature of the security token using the second security key; identify the second authentication string associated with the security token; and determine that the second authentication string matches the second server authentication string. Further in response to determining that the second authentication string matches the second server authentication string, the processor may identify a confidence score.

[0025] In some implementations, the second security key may be associated with a subgroup of the domain group, and wherein the subgroup of the domain group is associated with a plurality of computing devices associated with domains within the domain group. In some implementations, the second security key is associated with a computing device.

[0026] An optional feature of one aspect can be combined with any other aspect. Attached Figure Description

[0027] Details of one or more embodiments are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of this disclosure will become apparent from the specification, drawings, and claims, in which:

[0028] Figure 1 It is a block diagram of two sequences according to some implementation methods, each sequence including a computing device requesting content from a content server;

[0029] Figure 2A This is a block diagram of an implementation of an authentication control system for content delivery, based on some implementation methods.

[0030] Figure 2B This is a block diagram of an implementation of a system for authentication control of content delivery using a central server, according to some implementation methods.

[0031] Figure 3 This is a flowchart illustrating a method for authentication control for content delivery according to some embodiments;

[0032] Figure 4 This is a flowchart illustrating a method for authentication control of content delivery using a central server, according to some embodiments.

[0033] In each of the accompanying drawings, the same reference numerals and designations indicate the same elements. Detailed Implementation

[0034] When a third party provides content to a client device through a content server, the third party may not be able to determine whether the device requesting the content is associated with a user browsing the internet or a malicious party executing a cyberattack (such as a denial-of-service attack, a "click fraud" attack (e.g., a content request solely aimed at increasing payments to a content provider or publisher, rather than a legitimate content request, etc.), a fraudulent content request, or a similar content request that is illegitimate or unrelated to a legitimate user or request). Therefore, a malicious party may use fraudulent requests to induce the third party to provide content to them. Fraudulent requests may be part of a cyberattack against the third party (e.g., a denial-of-service attack, a distributed denial-of-service attack, a replay attack, a timed attack, etc.). In this case, the third party may want to verify that the device is associated with a legitimate user.

[0035] To verify that a client device is associated with a legitimate user, a content server associated with a third party may rely on other servers that may have information about the client device (e.g., information provided by the client device through creating and / or logging into an account on a website associated with the server, accessing the website, and / or through authentication communications performed via that website). These other servers may provide authentication information to the client device that proves the client device is not associated with a malicious entity. In a request for content, the client device may provide authentication information to the content server indicating that the server has determined the client device is likely not associated with a malicious party. A client device sending a content request may be unable to send the request without providing identification information about the client device or the server that provided the authentication information. Methods for separating internet users from malicious third parties can enable content servers providing content, and in some cases, eavesdroppers intercepting requests, to independently identify the data collection capabilities of the requesting content and / or the server providing authentication information to the client device.

[0036] For example, first refer to Figure 1In some embodiments, block diagrams of two sequences 102 and 114 are shown, each sequence 102 and 114 including a computing device that sends a content request to a content server. Sequence 102 may be a sequence including a client device 104 having a user interface for an application such as a browser application. In some cases, the browser application may not present output (e.g., a headless browser). Client device 104 may request content from content server 108. Malicious entities may use the browser application to perform various network attacks against the content server (e.g., denial-of-service attacks, distributed denial-of-service attacks, replay attacks, timed attacks, etc.). For example, in a network attack, a malicious party may use a browser application to browse the Internet without loading image or video files. The browser application may continuously request content from content server 108 without displaying the content. Content server 108 may serve content to the browser application without determining whether the request originates from a malicious entity. Sequence 114 may be a sequence of another client device 116 having a browser application that requests content from content server 120 in a network attack. Content server 120 can receive the request, determine that the request may be associated with a malicious entity, and block the delivery of content to the browser application.

[0037] At sequence 102, client device 104, using a browser application and accessing a website, may send a content request to content server 108. The browser application's user interface may be displayed on monitor 106 when the webpage loads. Through the browser application, client device 104 may send a fraudulent content request to content server 108 (e.g., a request associated with a cyberattack). Content server 108 may not have a method to determine that the request originates from a client device associated with a malicious entity and may serve content to the malicious entity via content selector 110. Monitor 112 may display the browser application's interface after receiving the content. Therefore, content server 108 may have served content to a malicious entity. Although referred to as "fraudulent," as discussed above, the request can be considered illegitimate in any way, such as a malicious denial-of-service attack, a spoofed request from a faulty device, a request unrelated to a legitimate user, a "click fraud" request, or any other type of request that should not be responded to normally.

[0038] Conversely, sequence 114 illustrates an example sequence in which client device 116 sends a similar fraudulent content request to content server 120. However, in sequence 114, client device 116 may include a security token or code generated by client device 116 based on a token or code received by client device 116 from the server. In response to determining that client device 116 is not related to a malicious entity with a probability exceeding a threshold, the server may have provided the security token or code. The security token or code may include one or more signatures, such as one or more group signatures. Such a signature may be associated with a server association that distributes certificates to servers within that association, which the servers can use to sign the security token.

[0039] The certificate signature can be decrypted using only the security key associated with the server association (e.g., a public encryption key). An additional signature can be associated with a subgroup of the server association, to which the client device is a member. The server that signs the security token and provides it to the client device can group each client device associated with the website associated with the server into separate groups. The server can provide a certificate to the client devices in each subgroup, enabling the client device to sign the security token with a signature that can only be decrypted using the security key associated with that subgroup. When requesting content from content server 120, client device 116 may include: a security token comprising a signature from the server that provided the security token; a signature associated with the subgroup to which client device 116 is associated; and a security key associated with the subgroup, which content server 120 can use to verify the subgroup's signature.

[0040] Content server 120 may be a server that receives content requests and provides content to the requesting client device. Content server 120 may receive a content request, including a security token and a double-joint signature, from client device 116 and determine whether the signature is authentic. Content server 120 may verify whether client device 116 is associated with a malicious entity using identifier verifier 122. As will be described in more detail below, identifier verifier 122 may use a security key to verify the two-joint signature of the security token. If the signature verification is successful, identifier verifier 122 may identify the confidence score provided by the server in the security token, which the server stores in client device 116. In addition to other information (e.g., information about the server association to which the server is associated), identifier verifier 122 may also use the confidence score to determine whether the client device is likely (e.g., reaching a threshold) to be unrelated to a malicious entity. If identifier verifier 122 determines that client device 116 is likely associated with a malicious entity, content selector 124 of content server 120 may not provide content to client device 116 or provide content associated with low value.

[0041] Display 118 may be shown as the output of a browser application running on client device 116 while the webpage is loading, prior to client device 116 requesting content from content server 120. Display 126 may display the output of content server 120 if content server 120 determines that client device 116 may be associated with a malicious entity. As shown, display 126 may not include content from content server 120 because content server 120 may have determined that client device 116 may be associated with a malicious entity and refused to provide content in response to the request. Although not shown, content server 120 may selectively send content to client device 116 if it determines that client device 116 may not be associated with a malicious entity.

[0042] Advantageously, as illustrated in sequence 114, because client device 116 can provide a security token to content server 120 to authenticate itself as a client device potentially unrelated to malicious parties, content server 120 can filter client devices to which it provides content and avoid providing content to malicious entities. The double-signature in the security token helps protect the privacy of client device 116 and the data collection capabilities of the server providing the security token to the client device. The security token indicates that the server has determined with sufficient probability that the client device is unrelated to malicious entities. Therefore, content server 120 can identify with a certain probability whether the client device associated with the content request is unrelated to malicious entities. Content server 120 can avoid providing content to client devices potentially associated with malicious entities and provide content to client devices potentially unrelated to malicious entities.

[0043] In addition to protecting the privacy of the client device requesting content, the systems and methods described herein can provide protection for confidential information (e.g., data collection capabilities and relationships) of servers within a server association that provides security tokens indicating that the client device is not associated with a malicious party. Because the security token includes a group signature from the server association rather than the signatures of individual servers, the content server providing the content or other malicious parties (e.g., eavesdroppers) may not be able to individually identify the server or the number of client devices associated with each server. Therefore, both the content server and the malicious party may be unable to individually identify the server providing the security token, or the relationship between the requesting client device and the server.

[0044] Finally, the systems and methods described herein can also help servers in various server associations identify client devices that may not be associated with malicious parties accessing and connecting to the server (e.g., hosted on the server). Once a server has determined that a client device may not be associated with a malicious party, it can track the client device's activity and mark the client devices it trusts by storing security tokens in the client device's browser. Servers can use the rules and processes of the server associations they are affiliated with to determine which client devices they trust.

[0045] For example, now refer to Figure 2AThis illustration shows an implementation of an authentication control system for content delivery according to some embodiments. System 200 is shown as including domain servers 202 and 209, network 216, client device 218, and content server 232. Client device 218 can browse the Internet by accessing web pages and domains associated with different third parties and their servers. Client device 218 can browse the Internet via network 216. Network 216 may include a synchronous network or an asynchronous network. When client device 218 browses the Internet, client device 218 can receive security tokens from servers (e.g., domain servers 202 and 209) associated with the various websites accessed by client device 218. The security token can instruct the server providing the security token to be certain that client device 218 is not a malicious entity. Client device 218 can provide the security token to content server 232 in a content request when accessing another website. As described in more detail below, content server 232 can recognize the security token and determine whether the security token provides sufficient information for content server 232 to provide content to client device 218. If content server 232 determines that client device 218 is not associated with a malicious entity, content server 232 may provide content to client device 218 in response to a request. However, if content server 232 determines that client device 218 may be associated with a malicious entity, content server 232 may not provide content to client device 218 or may provide content of low value.

[0046] Domain servers 202 and 209 may each include one or more servers or processors configured to determine, with a certain degree of certainty (e.g., confidence score), whether client device 218 is associated with a malicious entity, and to provide authentication to client device 218 (e.g., via a security token) if either domain server 202 or 209 is sufficiently confident that client device 218 is not associated with a malicious entity. As described herein, a domain server can be described as a domain server, a server, or any other device associated with a website and capable of providing a security token to the browser of a client device. Domain servers 202 and 209 may each be associated with a group of servers forming a server association. Upon joining a server association, each of domain servers 202 and 209 may receive a digital certificate C. serverDomain servers 202 and 209 can use their respective digital certificates to sign messages that, in some cases, can be decrypted using only the server association's published security keys (e.g., public encryption keys). The server association can associate and publish security keys that various client devices can use to verify group signatures performed by servers associated with the server association. The server association may include a group manager server. The group manager server can publish security keys that other devices can retrieve to decrypt and verify messages signed by servers of the server association. Advantageously, by using the server association's group signature, devices verifying group signatures cannot individually identify the server of the server association that signed the message with the group signature.

[0047] For example, in some implementations, domain server 202 is shown as including processor 204 and memory 206. In brief, through processor 204, domain server 202 can be configured to identify client devices (e.g., client device 218), calculate a confidence score indicating that the client device is not associated with a malicious entity, compare the confidence score to a threshold, and provide a security token to the client device in response to a confidence score exceeding the threshold. One or more components within domain server 202 can facilitate communication between each component within domain server 202 and external components (such as client device 218 and content server 232). Domain server 202 can include multiple connected devices (e.g., as a server library, a set of blade servers, or a multiprocessor system), each device providing some of the necessary operations. Domain server 209, processor 210, memory 212, and application 214 can be similar to and perform similar operations as the respective components 204, 206, and 208 of domain server 202.

[0048] In some embodiments, processor 204 may include one or more processors configured to execute instructions on modules or components in memory 206 within domain server 202. In some embodiments, processor 204 may run modules within memory 206. In some embodiments, memory 206 is shown as including application 208. Application 208 may include applications, servers, services, daemons, routines, or other runnable logic to identify client devices accessing a website associated with domain server 202 (e.g., a website with a domain associated with domain server 202). Application 208 may identify client devices based on the client device's browsing activity on the website. For example, a client device may create a user account on the website. Application 208 may identify the client device from the account information of the user account. Application 208 may identify each instance of a client device logging into a user account. In some embodiments, application 208 may identify the client device at each instance of a client device accessing the website. Each time a client device logs into a user account and / or accesses the website, application 208 may increment and maintain a counter.

[0049] Application 208 can determine a confidence score, which indicates the likelihood that a client device is not associated with a malicious entity. Application 208 can determine the confidence score based on the client device's browsing activity and various rules associated with the server association of domain server 202. Each server in the server association can implement the same rules to determine the confidence score for various client devices. For example, a server association rule might instruct that if a client device creates a user account on a website, the server associated with that website can allocate 40% of the confidence score to that client device. Another rule might instruct that the confidence score increases by 5% each time a client device logs into a user account. Therefore, if a client device creates an account on a website and logs into that account five times, the server associated with that website can allocate 65% of the confidence score to that client device.

[0050] In another example, user accounts can be associated with values. Server associations can have rules indicating that higher values ​​are associated with higher confidence scores (e.g., a value of 100,000 might be associated with a 70% confidence score, while a value of 10 might be associated with a 5% confidence score). A server within a server association can identify values ​​associated with a user account from the user account's account information and use these rules to determine the confidence score of the client device associated with that user account. In some cases, servers can use rules to evaluate various combinations of account information (e.g., values ​​and account creation; account creation and login counts; values, account creation, login counts, previous instances of authentication communications, interaction history, etc.) to determine the confidence score of a client device. Different server associations can have different rules and determine the confidence score of a client device based on different account information or data. Server associations can implement any number of rules to determine the confidence score of a client device.

[0051] Servers within the Server Consortium can use any type of method to determine a client device's confidence score. For example, a server can use user account information and other information (such as values, creation time, website type, login count, site visit count, etc.) as signals to implement a machine learning model (e.g., neural networks, random forests, support vector machines, etc.) to determine a confidence score indicating the likelihood that a client device is not associated with a malicious entity. The machine learning model used to determine the confidence score can be trained using supervised, unsupervised, or semi-supervised methods and continues to be trained using real-time data as the model determines probabilities for client devices as they visit websites associated with various servers and perform various interactions on those websites. In another example, the server can implement a lookup table in a database and compare account information against that lookup table. The lookup table can be in a cloud database accessible to each server within the Server Consortium. If a user account is associated with specific user account information (e.g., values ​​exceeding a threshold, login count, etc.), the server can determine the confidence score associated with that user account information from the lookup table.

[0052] Once application 208 determines the confidence score of client device 218, it can compare the confidence score to a threshold. The threshold may be a predetermined threshold set by an administrator, indicating that application 208 has collected sufficient data and has sufficient confidence that client device 218 is not a malicious entity. The predetermined threshold may be associated with a server association of domain server 202 (e.g., each server in the server association may implement the same threshold). In some implementations, the predetermined threshold may be specific to the servers in the server association. If application 208 determines that the confidence score exceeds the predetermined threshold, it may store a security token in the browser of client device 218 (described in more detail below). If application 208 determines that the confidence score does not exceed the predetermined threshold, it may not store the security token in the browser. In some implementations, application 208 may store the security token in the browser of client device 218 without comparing the confidence score associated with client device 218 to the threshold.

[0053] When application 208 stores the security token in the browser of client device 218, application 208 may include a determined confidence score of client device 218 in the security token (e.g., as metadata of the security token, as an identifier in the security token header, etc.). In some implementations, the server may also include the identifier of the server association to which the server is associated in the security token (e.g., in the security token header). Application 208 may use the certificate received by domain server 202 when joining the server association to sign the security token. Advantageously, by using a certificate associated with the server association to sign the security token, the client device or server receiving the security token (e.g., content server 232) can verify that the server associated with the server association provided the security token including the information determined by the server, without being able to identify the server providing the security token alone. Therefore, a malicious party (e.g., an eavesdropper) or other devices such as the content server may not be able to determine the relationship between the client device receiving the security token and the server providing the security token.

[0054] In some implementations, application 208 can randomly group identifiers of various client devices associated with the website of application 208 (e.g., user accounts on the website, users logged into the website, users who have visited the website, etc.) into groups (e.g., subgroups of server associations). To randomly group identifiers, application 208 can hash the account identifiers (e.g., using SHA-2, SHA-256, MD5, etc.) so that client devices and associated user accounts can remain anonymous and / or heterogeneous. Advantageously, by randomly grouping client device identifiers, the server can segment identifiers without using common characteristics of the client devices. Therefore, content servers and malicious parties may be unable to identify or collect any private information about client devices based on the common characteristics of groups of identifiers.

[0055] In some implementations, application 208 can segment identifiers based on the identification data of each client device. For example, application 208 can segment identifiers based on the location of the associated client device when creating a user account on the associated client device, based on values ​​associated with the user account when creating its user account on the client device, or based on previously visited websites when creating its user account on the client device. Application 208 can use data associated with the user account that remains fixed when grouping identifiers, allowing identifiers to remain in the same group.

[0056] Application 208 can group various client device identifiers into groups such that the number of client devices in each group exceeds a threshold. This threshold can be a predefined threshold set by the administrator, preventing individual identification of client devices based on their group affiliation. For example, Application 208 can divide each group into groups containing more than 10... 5 The number of identifiers. The predetermined threshold can be associated with any number of identifiers.

[0057] For each group, domain server 202 can act as a group manager via application 208, and distribute browser certificates to client devices associated with that group via a security token stored in the browser on the client device by application 208. The client device can use the browser certificate to sign messages sent by the browser with the group signature of the group to which the browser is associated. Application 208 can also distribute subgroup security keys to client devices within the security token. The subgroup security key can be a security key that another device can use to decrypt group signatures created by the client device. Application 208 can use C... serverThe security token is signed using a server association group signature to encrypt the authentication string (e.g., a hash of the string, such as the plaintext of the message that application 208 sends with the security token, or subgroup security). Application 208 may also send both the subgroup security key and the browser certificate in the security token with an expiration time (e.g., time of existence). Therefore, in addition to the confidence score and the identifier of the server association associated with domain server 202, application 208 may also include the browser certificate, C... browser Subgroup security key, K group Signature with Server Association

[0058] S(K group C server )

[0059] S can be a signature function, K group It can be a subgroup security key and an authentication string encrypted in the signature, C server This could be a certificate used by the server to provide a group-signed certificate in a security token stored in the client device's browser by application 208. Application 208 may also provide the expiration dates of both the security key and the browser certificate in the security token. In some implementations, application 208 can use C... server Encryption K group Previously about K group Execute the hash function. Applying a 208 hash can encrypt any string in the signature (e.g., the plaintext of the message accompanying the signature, a timestamp, a random number, etc.).

[0060] Client devices 218 may include any type and form of media device or computing device, including desktop computers, laptop computers, portable computers, tablet computers, wearable computers, embedded computers, smart TVs, set-top boxes, consoles, Internet of Things (IoT) devices or smart appliances, or any other type and form of computing device. The client devices (multiple devices) may be referred to in various ways as clients, devices, client equipment, user devices, computing devices, anonymous computing devices, or any other such terms. The client devices (multiple devices) may receive data via any suitable network, including local area networks (LANs), wide area networks (WANs) such as the Internet, satellite networks, cable networks, broadband networks, fiber optic networks, microwave networks, cellular networks, wireless networks, or any combination of these or other such networks. In many embodiments, the network may include multiple subnetworks that may be the same or different types, and may include multiple additional devices (not shown), including gateways, modems, firewalls, routers, switches, etc.

[0061] Client device 218 may include one or more client devices configured to request and receive content from content server 232 without providing content server 232 with identification information of client device 218 or any of domain servers 202 and 209. In some embodiments, client device 218 is shown as including processor 220 and memory 222. One or more components within client device 218 may facilitate communication between each component within client device 218 and external components such as content server 232, domain servers 202 and 209, and various other computing devices (not shown).

[0062] In some embodiments, processor 220 may include one or more processors configured to execute instructions on modules and / or components in memory 222 within client device 218. Memory 222 is shown as including browser 223. Browser 223 may connect to the Internet via network 216 and access websites that request content from various content servers, such as content server 232. In some embodiments, browser 223 is shown as including token receiver 224, token calculator 226, and token generator 228. Memory 222 and browser 223 may include any number of components. By executing the operation of each component 224, 226, and 228 by running instructions on the modules in memory 222, processor 220 may prevent content server 232 (or any other content server) from individually identifying client device 218 or a domain server (e.g., domain server 202 or domain server 209) that provides a security token to client device 218 based on information in a content request made by client device 218.

[0063] Browser 223 is shown as including token receiver 224. Token receiver 224 may include applications, servers, services, daemons, routines, or other runnable logic to receive security tokens from various servers (e.g., domain servers 202 or 209). When performing browsing activity on a website associated with a server, token receiver 224 may receive security tokens from the server. In each security token, token receiver 224 may receive the security token and retrieve from the security token the server association identifier of the server that provided the security token, the browser certificate, the subgroup security key, the server association group signature, and the expiration time of the browser certificate and subgroup key, and store them in a database (not shown). Once the expiration time is reached (e.g., the browser certificate and subgroup key have expired), token receiver 224 may remove (e.g., discard) the browser certificate and subgroup key from the database.

[0064] Upon receiving a security token, token receiver 224 can identify the server association's identifier and retrieve the server association's group security key. Token receiver 224 can retrieve the group security key from a database within storage 222 or from a published website associated with the server association's group manager server. Token receiver 224 can retrieve the group security key and use it to verify the group signature.

[0065] S(K group C server )

[0066] Token receiver 224 can verify the group signature by decrypting the group signature with the group security key and comparing the subgroup security key with the decrypted signature. If token receiver 224 determines that the subgroup security key matches, then token receiver 224 can determine that the group signature is authentic.

[0067] When accessing a website, browser 223 may request content from content server 232. To prove to content server 232 that client device 218 is not a malicious entity, browser 223 may include a client security token in the content request. Because browser 223 may receive multiple security tokens from various servers while browsing the internet, browser 223 may need to calculate via token calculator 226 which subset of security tokens to include in the content request. Browser 223 may need to do this without providing a security token that allows content server 232 to individually identify client device 218 from the intersection of client devices associated with the server association associated with the security token. For example, there could be 10,000 client devices associated with a server association associated with shoes, 5,000 client devices associated with a server association associated with basketball, 2,500 client devices associated with a server association associated with tennis, and 1,000 client devices associated with an association server associated with pianos. Only five client devices may have received security tokens from the shoe-related server association and the piano-related server association, while 2,000 client devices may have received security tokens from the basketball-related server association and the shoe-related server association. Content server 232 can identify client device 218 based on the security tokens from the shoe and piano associations, while client device 218 can remain anonymous if browser 223 sends the security tokens from the shoe and basketball associations to content server 232. As described below, token calculator 226 can determine which security tokens to send to content server 232 so that client device 218 can remain anonymous in content requests.

[0068] Token calculator 226 may include applications, servers, services, daemons, routines, or other runnable logic to calculate which security tokens should be included in content requests to content server 232. Token calculator 226 may identify the identifier of each server association associated with the security tokens stored in browser 223. In some implementations, token calculator 226 may send the identifier to a central server (not shown) that can determine the number of client devices associated with each server association, and in some cases, the number of client devices associated with each intersection of server associations. To determine the number of client devices associated with each server association or intersection of server associations, the central server may receive indications from client devices indicating that they are associated with a server association or group of server associations. The central server may increment and maintain a counter for each client device associated with each server association and / or intersection of server associations, with each client device sending an indication to the central server that the client device is associated with a server association or group of server associations. Based on the counter counts, the central server may determine the number of client devices associated with intersections between any number of server associations and / or the number of client devices associated with each server association. The central server can determine and send the token calculator 226 the number of client devices that send the identifier to each server association and the intersection of the server associations.

[0069] In some implementations, instead of sending the number of client devices associated with each server association to token calculator 226, the central server may send the value of a Boolean variable (e.g., a variable with possible values ​​of yes and no or 1 and 0) indicating whether the number of client devices associated with each server association or subset of server associations exceeds a threshold. The threshold may be set by an administrator. Token calculator 226 may receive the value of the Boolean variable and determine, based on the value, whether there are enough client devices associated with a server association or subset of server associations to remain sufficiently unidentifiable. Advantageously, if the central server only sends the Boolean variable to token calculator 226, client device 218 may be unable to determine the number of devices associated with a server association or subset of server associations.

[0070] Once the token calculator 226 receives the number of client devices associated with each server association and the intersection of server associations, it can identify a subset of security tokens associated with the intersection of server associations that is associated with a number of client devices exceeding a threshold. This threshold can be a predetermined threshold set by an administrator, allowing client devices 218 to remain anonymous in content requests. The token calculator 226 can compare the count of each subset of security tokens to the threshold to determine which subset of security tokens is associated with a sufficient number of client devices exceeding the threshold. The token calculator 226 can then select a subset of security tokens to send a content request to the content server 232, which is associated with a sufficient number of client devices exceeding the threshold. In some implementations, the token calculator 226 can select a subset of security tokens associated with a maximum number of client devices.

[0071] Once the token calculator 226 selects a security token or a subset of security tokens to send to the content server 232, the token generator 228 can generate a client security token and send that client security token to the content server 232. The token generator 228 may include applications, servers, services, daemons, routines, or other runnable logic to generate client security tokens and send them along with content requests to the content server 232. The token generator 228 can identify the security tokens selected by the token calculator 226 to send to the content server 232 and generate a client security token for each selected security token or a client security token including all or part of the data of the selected security token.

[0072] For each selected security token, token generator 228 can generate a client security token including a browser signature using the following equation.

[0073] S(random number || timestamp, C) browser )

[0074] S can indicate a signature function. || Describes a method for concatenating the values ​​of separate strings into a single string, or assembling a message that includes multiple other messages. Token generator 228 can determine a random number using an incrementing counter (e.g., corresponding to time, messages sent between client device 218 and content server 232, etc.). The random number can be synchronized between client device 218 and content server 232 so that content server 232 knows the random number used by token generator 228 in the signature. In some implementations, client device 218 can send all or part of the random number along with the content request to content server 232, allowing content server 232 to recognize the random number and decrypt the security token. The timestamp can be the time when token generator 228 sends the client security token to content server 232. C browser This can be a certificate associated with a subgroup associated with client device 218, received by browser 223 when it receives the corresponding security token from the server. Token generator 228 can use C... browser The concatenated random number and timestamp are signed. In some implementations, the token generator 228 can be used with C... browser A hash function (e.g., SHA-256) is performed on the concatenated random number and timestamp before signing them.

[0075] In addition, the token generator 228 may include the subgroup security key and K received by the token receiver 224 in the content request. group and signature

[0076] S(K group C server )

[0077] As mentioned above, K group It can be a secure key that can be decrypted and whose signature can be verified.

[0078] S(random number || timestamp, C) browser )

[0079] C server This could be a certificate, which the server storing the selected security token in browser 223 uses to sign the selected security token with a group signature from the server association. Token generator 228 may also include a server association identifier associated with the selected security token in the client security token (e.g., in the header of the client security token) and a confidence score included with the selected security token. Token generator 228 can generate a client security token and send it to content server 232 along with a content request.

[0080] Content server 232 may include one or more servers or processors configured to receive content requests; determine with a certain degree of certainty whether the content request is sent by a client device unrelated to a malicious entity; and, if content server 232 determines that client device 218 is likely unrelated to a malicious entity, send content to client device 218. For example, in some embodiments, content server 232 is shown as including processor 234 and memory 236. Briefly, through processor 234, content server 232 may be configured to receive client security tokens or subsets of client security tokens from client device 218, identify the identifier of the server association associated with each client security token, retrieve the security key associated with the server association, decrypt the client security token with the security key, verify that the client security token is associated with the server association, determine whether the confidence score of the client security token exceeds a threshold, and, if content server 232 determines that the client security token is associated with the server association and the confidence score exceeds the threshold, send content to client device 218.

[0081] One or more components within content server 232 can facilitate communication between each component within content server 232 and external components such as client device 218 and content server 232. Content server 232 may include multiple connected devices (e.g., as a server library, a set of blade servers, or a multiprocessor system), each device providing some of the necessary operations.

[0082] In some embodiments, processor 234 may include one or more processors configured to execute instructions on modules or components in memory 236 within content server 232. In some embodiments, processor 234 may run modules within memory 236. In some embodiments, memory 236 is shown as including token receiver 238, verifier 240, application 242, sender 244, and signature database 246. Each of components 238-246 may cooperate to determine that the client device that sent the content request is likely not malicious and send the content to the client device. Components 238-246 may make this determination based on the content of a client security token included by client device 218 in its content request.

[0083] Token receiver 238 may include an application, server, service, daemon, routine, or other runnable logic capable of receiving content requests from client device 218, which includes a client security token or a subset of client security tokens calculated by client device 218. The request may also include an identifier of a server association, or a set of identifiers of a server association that provides a security token or a subset of security tokens. Token receiver 238 may receive the request and identify the client security token and the identifier of the server association associated with the client security token. As described above, the client security token may each include a group signature associated with the server association of the server that signed the security token, a signature associated with a subgroup of the server association, and a security key for decrypting the signature of the subgroup of the server association (in some cases, the security key of the subgroup may be publicly available on a website associated with the server that signed the security token). In some embodiments, the client security token may include the identifier of the server association associated with the client security token.

[0084] Verifier 240 may include an application, server, service, daemon, routine, or other runnable logic capable of verifying the signature of a content request from client device 218. Verifier 240 may identify the server association from the request (e.g., from the request header or from the client security token) and retrieve a security key (e.g., a public encryption key) associated with the server association. If the security key is stored in signature database 246, verifier 240 may retrieve the security key from signature database 246, or verifier 240 may retrieve the security key from the website of a server association's server (e.g., the website of a group manager server of the server association). Verifier 240 may use the retrieved security key to decrypt the client security token (e.g., the signature of the client security token).

[0085] To verify the digital signature, verifier 240 can decrypt the signature associated with the server association and identify the decrypted signature string as the authentication string. The authentication string can be a hash of the plaintext of the request, a hash of a random number and / or a timestamp, etc. The authentication string can also be a hash of a subgroup security key. If the authentication string is a hash of a subgroup security key, verifier 240 can identify the subgroup security key sent with the content request and perform a hash function on the subgroup security key to obtain the expected authentication string. Content server 232 and client device 218 can be synchronized such that they both perform the same hash function on the same data to obtain a matching authentication string. In some implementations, verifier 240 can concatenate a random number and / or a timestamp into the requested content to obtain a concatenated string and hash the concatenated string to obtain the expected authentication string. Verifier 240 can compare the expected authentication string with the authentication string decrypted by verifier 240 to determine if they match. If the authentication string matches, verifier 240 can determine that the server associated with the server association associated with the identifier provided the signature, and sender 244 can send the content to client device 218. Because the server association signature can be a group signature, verifier 240 may not be able to identify which server in the server association provided the signature for the client security token. If the authentication string does not match, verifier 290 can determine that the signature was not provided by the server associated with the server association associated with the identifier. Therefore, sender 244 can send a signal indicating that no match was found to client device 218 and prevent content from being sent to client device 218.

[0086] In some implementations, once verifier 240 authenticates the server association's signature, verifier 240 can verify the second signature by decrypting a second signature of the client security token using the subgroup security key provided by client device 218 in the content request. Verifier 240 can decrypt the second signature to obtain a second authentication string. The second authentication string may be a hash value of a random number concatenated with a timestamp and / or a hash value of a random number, timestamp, and plaintext concatenated with the request. Content server 232 may synchronize with client device 218 such that content server 232 can use the same timestamp and random value to obtain the expected authentication string. The timestamp may be associated with the time when client device 218 sends the request or the time when content server 232 receives the request. Content server 232 (e.g., via verifier 240) may also know to perform the same hash function as client device 218 on the concatenation of timestamp and random value to obtain the expected authentication string. Verifier 240 may compare the expected authentication string, including the hashed timestamp and random number, with the decrypted authentication string of the signature associated with the subgroup of the server association. If verifier 240 determines that a match exists, verifier 240 can determine that the signature was signed by a member of a subgroup of the server association, but cannot identify which member provided the signature. However, if verifier 240 determines that no match exists, verifier 240 can determine that the request is not genuine, and sender 244 can send a message to client device 218 indicating that no match exists, thereby preventing content from being sent to client device 218.

[0087] In some implementations, client device 218 can transmit a timestamp along with the content request to content server 232. Therefore, client device 218 and content server 232 do not need to synchronize their internal clocks. Furthermore, client device 218 can generate random numbers. In such an instance, client device 218 can send the random number along with the content request to content server 232, allowing content server 232 to know the random value used to verify the second set of signatures.

[0088] In some implementations, to stop network attacks such as replay attacks, verifier 240 can identify the timestamp of the authentication string and compare it with the current time (e.g., the time when content server 232 receives the content request). Verifier 240 can subtract the timestamp from the current time to calculate the duration. Verifier 240 can compare the duration with a predetermined threshold set by an administrator to determine if the duration exceeds the threshold. If the duration exceeds the threshold, verifier 240 can determine that the content request is stale and block the delivery of content. However, if the duration does not exceed the threshold and the signature is valid in other ways (e.g., the authentication string matches), verifier 240 can determine that the signature is valid.

[0089] In some implementations, client device 218 may use its private encryption key instead of the signature provided by the group signature of a subgroup of the server association to provide the signature along with the client security token. Alternatively, in addition to using the group signature provided by the subgroup of the server association, client device 218 may also use its private encryption key to provide the signature along with the client security token. In such implementations, content server 232 may use client device 218's public encryption key to decrypt the signature and authenticate the decryption using authentication techniques similar to those described above (e.g., determining whether the authentication string of the signature matches the expected authentication string).

[0090] In some implementations, once verifier 240 determines that the signature associated with a server association, a subgroup of the server association, and / or the client device is authentic (e.g., has been verified against the expected authentication string), application 242 can determine whether the content request, including the client security token, contains sufficient information to determine whether client device 218 is not related to a malicious entity with a sufficiently high probability exceeding a threshold. To do this, application 242 can identify and analyze the characteristics of the client security token. These characteristics may be an identifier and / or metadata associated with the client security token that provides information about the type of data of the domain server that provided client device 218 with the security token to determine whether client device 218 is likely not related to a malicious entity. The characteristics of the client security token may include, but are not limited to, a confidence score indicating the probability that client device 218 is not related to a malicious entity as determined by the domain server, the data used by the domain server to determine the confidence score, the rules applied by the domain server to the data to determine the confidence score, the identifier of the server association to which the domain server is associated, etc.

[0091] Application 242 can identify the characteristics of the client security token and determine whether there is sufficient information to authenticate the request and client device 218 for content delivery by sender 244. To determine if there is sufficient information, application 242 can compare a confidence score associated with the client security token to a predetermined threshold set by the administrator. If the confidence score exceeds or meets the predetermined threshold, application 242 can determine that there is a sufficiently high probability that client device 218 is not a malicious entity, and sender 244 can send content to client device 218. However, if the confidence score does not exceed the predetermined threshold, application 242 can determine that there is not a sufficiently high probability (or sufficient information) to determine that client device is not a malicious entity, and application 242 or sender 244 can block content delivery to client device 218. Advantageously, by implementing a threshold set by the administrator of content server 232, if the domain server provides a security token to the client device without sufficient confidence to satisfy content server 232, content server 232 can further filter out requests from malicious parties. Content server 232 can perform its own screening to protect itself from cyberattacks instead of relying solely on domain servers to determine whether client devices are associated with malicious entities.

[0092] In some implementations, instead of applying the same predetermined threshold to the confidence score of each client security token, application 242 can apply the confidence score of the client security token to thresholds associated with each server association to which the client security token is associated. The threshold associated with each client security token can be associated with the trust level that content server 232 has with the server association associated with the client security token. For example, content server 232 can have a high trust level with a server association associated with shoes. Therefore, this server association can be associated with a low confidence score threshold (e.g., 60%). In another example, content server 232 can have a low trust level with a server association associated with instruments. Therefore, the server association associated with instruments can be associated with a high confidence score threshold (e.g., 90%). The trust level can correspond to the criteria used by the server association to determine the confidence score of various client devices. As described below, the trust, criteria, and thresholds for various server associations can be stored in the feature database 246 of content server 232. Application 242 can compare the confidence score of the client security token with a threshold associated with the server association of the server that determines the confidence score to determine whether to provide content to the client device 218 when the client device 218 requests content.

[0093] In some implementations, application 242 may identify a confidence score for the client security token by determining its own confidence score indicating the likelihood that client device 218 is not a malicious entity, based on features of the client security token received by server 232 in a content request. Application 242 may use any method to determine the confidence score. For example, application 242 may implement a machine learning model (e.g., a neural network, random forest, support vector machine, etc.) to determine the binary output indicating the likelihood that client device 218 is not a malicious entity. Application 242 may signal the machine learning model that it receives as a feature of the client security token. Examples of signals include, but are not limited to, the confidence score of the client security token, the server association associated with the server providing the security token, the data the server uses to provide the security token, the rules the server applies to the data to provide the security token, etc. The machine learning model may be trained using supervised, unsupervised, and / or semi-supervised methods, and it becomes increasingly accurate as it is trained with real-time data. The machine learning model may provide a percentage indicating the likelihood that client device 218 is not a malicious entity. Application 242 may compare this percentage to a threshold. If the percentage exceeds the threshold, the sender 244 may send content to the client device 218. However, if the percentage does not exceed the threshold, the sender 244 may prevent the content from being sent to the client device 218 or may provide the client device 218 with content associated with low value.

[0094] In some implementations, application 242 can enforce a series of rules based on the characteristics of the client security token received by content server 232 in a content request from client device 218 to determine whether to provide content to client device 218. For example, the rules could instruct that if a request including a client security token associated with a specific server association includes enough client security tokens to exceed a threshold, then the request may only include sufficient information for content server 232 to send content to client device 218. Application 242 can increment and maintain a counter for each client security token received by content server 232 along with the content request, and if the counter count exceeds a threshold, application 242 sends content to client device 218. If the count does not exceed the threshold, application 242 can prevent content from being sent to client device 218, or sender 244 can send content associated with low value. The rule could instruct that the client security token must be associated with a different server association, the same server association, or a combination of the same and different server associations for sender 244 to send content.

[0095] The signature database 246 can be a dynamic database that includes information about various server associations, such as security keys associated with the server association (e.g., public encryption keys), and standards that the content server 232 needs to meet to determine whether the client device 218 is not malicious for various server associations. The signature database 246 can be a graph database, MySQL, Oracle, Microsoft SQL, PostgreSQL, DB2, document storage, search engine, key-value store, etc. The signature database 246 can be configured to store any amount of data and can consist of any number of components. When the token receiver 238 receives a client security token that includes the identifier of the server association associated with the website, the security key stored in the signature database 246 can have already been retrieved by the token receiver 238 from the server associated with the website. By storing the security keys for various server associations in the signature database 246, the content server 232 can verify the server association's signature more quickly because the content server 232 does not need to retrieve the corresponding security key from the server and / or the server association's website. Alternatively, the content server 232 can retrieve the security key from the signature database 246.

[0096] As described above, the criteria required for content server 232 to determine whether client device 218 is likely unrelated to a malicious party may include requirements specific to each server association. Content server 232 may have different trust levels for each server association. Therefore, the requirements for the criteria to be met for each server association may differ based on the trust level. The requirements, trust levels, and thresholds associated with each server association may each be stored in the feature database 246. Advantageously, by storing and implementing different criteria for authenticating client device requests, content server 232 can avoid content authentication client device requests, including those with client security tokens associated with server associations, without a robust system for determining which client devices are associated with malicious entities. Content server 232 can filter client security tokens to accept only those associated with security associations trusted by content server 232.

[0097] Sender 244 may include an application, server, service, daemon, routine, or other runnable logic to send content to a client device (e.g., client device 218) in response to a content request and after determining that the client device has a sufficient probability of not being malicious. If application 242 determines that the requesting client device has a insufficient probability of not being malicious (e.g., if the confidence score does not exceed a threshold), sender 244 may not send content to the requesting client device (e.g., sender 244 may block content from being sent to the client device). If application 242 determines that the requesting client device has a sufficient probability of not being malicious, sender 244 may identify the content and send it to the requesting client device.

[0098] In some implementations, various contents can be associated with different values. If application 242 determines with sufficient probability that the requesting client device is not a malicious entity, sender 244 may send content associated with high value. However, if application 242 determines that the requesting client device has insufficient probability of being unrelated to a malicious entity, sender 244 may choose to send content associated with low value to the requesting client device.

[0099] Figure 2B This is a block diagram of an embodiment of a system 250 for authentication control of content delivery using a central server, according to some implementations. In some embodiments, system 250 is shown as including a domain server 252, a network 260, client devices 262, a central server 274, and a content server 282. Domain server 252 is shown as including a processor 254, memory 256, and applications 258. Domain server 252 and its corresponding components may be similar to those described in reference to [reference needed]. Figure 2A Domain server 202 is shown and described. Network 260 may be similar to network 216. In system 250, client device 262 can receive a security token from domain server 252, which is calculated using a method similar to that described above. Client device 262 can send the security token to central server 274. As described below, central server 274 can verify that the security token is valid and send a central server security token to client device 262. Client device 262 can request content from content server 282, including the central server security token in the request. Content server 282 can authenticate the central server security token and provide the content to the requesting client device.

[0100] Client device 262 can be compared with reference Figure 2AThe client device 218 shown and described is similar to a client device. Client device 262 is shown as including a processor 264 and memory 266. Memory 266 is shown as including a browser 268. Browser 268 can browse various web pages on the Internet and send content requests to a content server (e.g., content server 282). Browser 268 is shown as including a token receiver 270 and a transmitter 272. Through token receiver 270 and transmitter 272, once domain server 252 determines, based on a confidence score threshold, that client device 262 is likely not malicious, browser 268 can receive a security token from domain server 252. Domain server 252 can sign the security token using its private key with the following signature:

[0101] S(domain of domain server || random number, C) server )

[0102] The security token is then sent to client device 262. In the signature, S can be a signature function, the domain of the domain server can be a domain name associated with domain server 252 or a server that otherwise provides the signature, the random number can be a known value between client device 262 and domain server 252 as described above, and C... server The certificate may be used by domain server 252 to provide the signature. In some implementations, the signature is a group signature of the server association as described above. Instead of sending the received security token along with the content request to content server 282, sender 272 may send a security token, which in some implementations includes the domain name of domain server 252 and a random number of the signature, to central server 274 for authentication before client device 262 requests content from content server 282.

[0103] Central server 274 may include one or more servers or processors configured to authenticate security tokens received by client device 262 from domain server 252. Central server 274 is shown as including processor 276 and memory 278. Memory is shown as including application 280. Through application 280, processor 276 can authenticate security tokens provided to central server 274 by client device 262, generate central server security tokens, and send central server security tokens to client device 262.

[0104] Application 280 may include applications, servers, services, daemons, routines, or other runnable logic to authenticate security tokens and provide central server security tokens to client device 262. Application 280 may receive a security token issued by domain server 252 from client device 262 and verify whether the security token is signed by domain server 252. Application 280 may retrieve the public key of domain server 252 (e.g., via a database (not shown) of central server 274 or from domain server 252) and use the public key to decrypt the signature of the security token to obtain a decrypted hash. Application 280 may compare the decrypted hash with an expected decrypted hash (e.g., a concatenated string of domain and timestamp associated with domain server 252). If the hashes match, application 280 can determine that the security token is authentic and signed by domain server 252. Therefore, application 280 can generate a central server security token using the central server's private key, which includes the following signatures:

[0105] S (Central Server Domain || Timestamp || Random Number, K) central server )

[0106] S can be a signature function, || can be a concatenation of two string functions, the central server domain can be a domain name associated with central server 274, the timestamp can be a timestamp as described above, the random number can be a random number as described above, and K... central server This could be the private key used by the central server 274 to provide signing. Application 280 can generate a central server security token and send it to the client device 262.

[0107] In some implementations, the security token sent by client device 262 to central server 274 may also include the identifier of the server association to which domain server 252 is associated, and a confidence score used by domain server 252 to determine that client device 262 may not be related to a malicious entity. Application 280 can identify the server association and confidence score, and perform operations similar to those referenced... Figure 2A The technology described is similar to that performed by content server 232 to determine whether to authenticate the security token and provide a central server security token. Advantageously, by using a central server 274 to authenticate the security token, the domain server, client device, and content server can each rely on a trusted server to authenticate the security token. Neither the domain server nor the client device can provide identification information to the content server. Alternatively, the client device can obtain the authentication information from a trusted device (e.g., Figure 2B The central server 274 provides an authentication token to the content server 282.

[0108] via token receiver 270, client device 262 can receive a central server security token from central server 274 and use the central server security token in content requests to content server 282. Sender 272 of client device 262 can associate (e.g., attach) the central server security token to the content request and send the request to content server 282.

[0109] Content server 282 may include one or more servers or processors configured to authenticate a central server security token received by client device 262 from central server 274. For example, in some embodiments, content server 282 is shown as including processor 284 and memory 286. Processor 284 may execute instructions in memory to receive the central server security token, authenticate the central server security token, and provide content to client device 262 based on successful authentication. In some embodiments, to perform these processes, memory 286 may include token receiver 288, authenticator 290, and transmitter 292.

[0110] Token receiver 288 may include an application, server, service, daemon, routine, or other runnable logic to receive a content request, including a central server security token, from client device 262. Token receiver 288 may receive the request and identify the signature of central server 274 in the request, enabling verifier 290 to determine whether client device 262 has a sufficient probability of being unrelated to a malicious entity.

[0111] Verifier 290 may include an application, server, service, daemon, routine, or other runnable logic to authenticate the central server security token and verify that client device 262 is likely unrelated to malicious entities. Verifier 290 may recognize the signature of central server 274 and retrieve the security key (e.g., a public encryption key) associated with central server 274 from the database of content server 282 or the website of central server 274. Verifier 290 may also recognize the central server domain, the timestamp corresponding to the time central server 274 signed the central server token, and a random number. Verifier 290 may create a concatenated hash of each of these values ​​using a hashing technique similar to the one used by central server 274 when signing the central server security token. Verifier 290 may use the security key of central server 274 to decrypt the signature to obtain the hash and compare this hash with a hash generated by verifier 290 using the central server's timestamp, random number, and domain name. If verifier 290 determines that a match exists, verifier 290 may determine that the signature is valid. Therefore, in an implementation where the central server 274 determines whether the security information is sufficient to indicate that the client device 262 is highly likely to be unrelated to malicious actors, the sender 292 can send content to the client device 262 in response to a request. The sender 292 can be similar to... Figure 2A The sender 244 is shown and described. However, if the verifier 290 determines that no match exists, the verifier 290 may determine that the signature is invalid, and the verifier 290 may prevent the content from being sent to the client device 262 in response to the request.

[0112] In some implementations, content server 282 may not trust the security token sent by central server 274 for authentication by client device 262. In such an implementation, content server 282 may receive information from a domain server (e.g., domain server 252) that provides a security token to client device 262, and verifier 290 may determine whether the domain server is trustworthy and / or whether there is sufficient information for content server 282 to authenticate client device 262 as having a sufficiently high probability of being unrelated to malicious entities, exceeding a threshold. Verifier 290 may perform actions similar to those described above. Figure 2A The application 242 shown and described uses a similar process to authenticate requests.

[0113] Now refer to Figure 3A flowchart of a method 300 for authentication control of content delivery according to some embodiments is shown. Method 300 may include any number of operations. The operations may be performed in any order. Method 300 may be performed by a server device (e.g., content server 232). In operation 302, the server device may receive a request for a content item including a security token. The server device may receive the request for the content item from the client device when the client device accesses the website. The request for the content item may include a security token and an identifier of the server association associated with the security token. The client device may have already received the security token when a server of the server association determines, based on a confidence score threshold, that the client device is not a malicious entity. The request for the content item may include multiple security tokens from servers associated with the same server association and / or servers associated with different server associations.

[0114] In Operation 304, the server device can identify the domain group of the security token. This domain group can include domains associated with servers in a server association. Each domain can be associated with a different server. The domain group can be associated with common characteristics or themes. For example, each domain can be associated with football. The server device can identify this domain group from the identifier included in the content request.

[0115] In operation 306, the server device can retrieve the security key for the domain group. This domain group can be associated with a group signature. The server associated with the domain group can sign a message (e.g., a security token) using the group signature, and another computing device cannot identify which server associated with the domain group signed the message using a self-signature. To authenticate the group signature, the server device can retrieve the domain group's security key (e.g., a public encryption key) from a website associated with the group manager server associated with the domain group.

[0116] In operation 308, the server device can use the retrieved security key to decrypt the security token. The server device can decrypt the security token by applying the retrieved security key to a signature associated with (e.g., appended to) the security token. In operation 310, the server device can identify an authentication string. The authentication string can be a string of the decrypted signature, which the server device can compare with a known value (e.g., an expected authentication string) to verify that decryption was successful, thus verifying that the server associated with the server association associated with the identifier has signed the security token using a group signature. The server device can identify the authentication string from the signature decrypted by the server device using the server association's security key. The authentication string can be or may include the plaintext message of the security token, a second security key associated with a subgroup of the server association, a random number, a timestamp, etc. In some implementations, the authentication string can be a hash value of any of the above examples.

[0117] In operation 312, the server device may determine whether the decrypted authentication string matches the expected authentication string. The server device may compare the decrypted authentication string with the expected authentication string. The expected authentication string may be provided in the security token received by the server device in the request, or it may be a string that the server device has identified and stored in its database. For example, the expected authentication string may be a second security key associated with a second signature associated with the security token. The content request may include the second security key, allowing the server device to compare the decrypted second security key with the requested second security key. In some implementations, the second authentication string may be a hash value of a string (e.g., the hash value of the second security key). The server device may know the hash function used to generate the hash value of the string and perform a similar hash function on the expected authentication string to verify a hash value match. If the hash value of the second security key does not match, in operation 314, the server device may send a signal to the requesting client device indicating that no match was found. In some implementations, the server device may stop method 300 when it determines that the authentication string does not match.

[0118] However, if the server device determines that the hash value of the second security key matches, then in operation 316, the server device can retrieve the second security key. The second security key can be associated with a subgroup of a server association. A subgroup of a server association can be a group to which the server of the server association that provides the security token places the requesting client device based on characteristics of the client device (e.g., values ​​associated with the client device's account, the physical location of the client device when the account was created, the date the client device created the account, etc.). The server can act as the group manager of the subgroup and provide a certificate to the requesting client device, which the requesting client device can use to sign the requested security token with a signature that can be decrypted using the second security key. The client device can include the second security key in the content request. The server device can retrieve the second security key from the content request, from a website associated with the server, or from the server device's database.

[0119] In operation 318, the server device can decrypt the security token using the retrieved second security key. The server device can decrypt the security token by applying the retrieved second security key to another signature associated with the security token. In operation 320, the server device can identify a second authentication string. The server device can identify the second authentication string from the signature decrypted by the server device using the second security key. The second authentication string can be a string similar to the authentication string in operation 310 (e.g., it can include plaintext messages, another security key, a random value, a timestamp, etc.). The second authentication string can include any string. For example, the second authentication string can include a random value concatenated with a timestamp indicating when the client device sent the content request.

[0120] In operation 322, the server device may determine whether the decrypted second authentication string matches the second expected authentication string. The server device may compare the decrypted second authentication string with the second expected authentication string. The second expected authentication string may be provided in the security token received by the server device in the request, or it may be a string that the server device has already stored in its database. For example, the second expected authentication string may include a random value concatenated with a timestamp. In some implementations, the second authentication string may be a hash value of a string. The server device may know the hash function used to generate the hash value and perform a similar hash function on strings containing data of the same type to verify a hash value match. If the server device determines that the second authentication string does not match, in operation 324, the server device may send a signal to the requesting client device indicating that no match was found. In some implementations, the server device may stop method 300 when it determines that the second authentication string does not match.

[0121] However, if the server device determines that the second authentication string matches, then in operation 326, the server device can identify the confidence score of the security token. The confidence score can indicate the likelihood that the client device is not malicious, as determined by the server that provided the security token to the client device. The server can determine the confidence score based on standards and rules associated with the server association to which it belongs (e.g., each server in the server association uses the same standards and rules to determine the client device's confidence score). Various server associations can determine the confidence score based on different rules and standards. The server device can identify the confidence score from the plaintext of the security token and / or content request.

[0122] In operation 328, the server device can determine whether the confidence score exceeds a threshold. This threshold can be specific to the server association associated with the security token. Based on the server device's trust level within the server association, each server association can be associated with a different threshold. For example, for a security token associated with a server association to which the server device has a low trust level, the server device can require a higher confidence score; for a security token associated with a server association to which the server device has a high trust level, the server device can require a lower confidence score. The server device can identify the threshold associated with the requested security token and compare the security token's confidence score with the threshold associated with the server association.

[0123] If the server device determines that the confidence score does not exceed the threshold, then in operation 330, the server device may send a signal to the client device indicating that the confidence score does not exceed the threshold. In some implementations, the server device may alternatively send the content item associated with the low value to the requesting client device. However, if the server device determines that the confidence score exceeds the threshold, then in operation 332, the server device may send the content to the requesting client device.

[0124] Now refer to Figure 4 A flowchart is shown for a method 400 of authentication control for content delivery using a central server for authentication, according to some embodiments. Method 400 may include any number of operations. The operations may be performed in any order. Method 400 may be performed by a server device (e.g., content server 232). In operation 402, the server device may receive a request for a content item including a security token. Operation 402 may be similar to referenced... Figure 3 Operation 302 is shown and described. However, the security token of operation 402 may be associated with a signature associated with a central server rather than a server association. In operation 404, the server device may retrieve a security key (e.g., a public encryption key) from the central server. The central server may be associated with a domain. The server device may retrieve the security key from the domain or from the central server. In some embodiments, the server device may have security keys stored in a database on the server device. The server device may retrieve the security key from the database.

[0125] In operation 406, the server device can use a security key to decrypt the security token. The server device can decrypt the security token by recognizing its signature and applying the security key to the signature. In operation 408, the server device can recognize an authentication string. The authentication string can be the decrypted signature string. The authentication string can be the plaintext of the requested message; a concatenated value including the central server's domain, timestamp, and random number; or any other string. In some implementations, the authentication string can be a hash value generated by the client device sending the request for the item using a hash function, as in these examples.

[0126] In operation 410, the server device can compare the authentication string with the expected authentication string and determine if a match exists. The expected authentication string can be a corresponding authentication string stored in the server device. For example, the server device can synchronize with the client device that sent the content request, so that both know the same random value and have similar clocks to determine the timestamp. Furthermore, the server device knows which hash function the client device used when providing the signature, and that the client device hashed a string consisting of a central server domain, a timestamp when the message was sent, and a random value. The server device can decrypt the signature using the central server's security key and hash the expected authentication string containing the same components using the same hash function used by the client device. If the hash values ​​do not match, in operation 412, the server device can send a signal to the client device indicating that no match was found, or send low-value content to the client device.

[0127] However, if the server device determines that the authentication string matches, then in operation 414, the server device can identify the confidence score of the security token. As mentioned above, the confidence score can indicate the likelihood, determined by a server in a server association that provides another security token to the client device, that the client device is not malicious. The content request may include a confidence score provided by a server in a server association (e.g., in the plaintext of the content request). The server device can identify the confidence score from the message.

[0128] In some implementations, instead of identifying confidence levels, server devices can provide content to requesting client devices based on successful authentication of a central server's signature. The central server can be a server trusted by the server devices and implementing its own standards to determine whether a security token provided by a server from a server association has provided sufficient information before storing the security token in the browser. Therefore, server devices can trust the central server and avoid additional processing when determining the likelihood that a requesting client device is associated with a malicious entity.

[0129] However, in other implementations, in operation 416, the server device can determine whether the confidence score exceeds a threshold. The threshold may be specific to the server association associated with the security token. Operation 416 can be similar to reference... Figure 3 Operation 328 is shown and described. If the server device determines that the confidence score does not exceed the threshold, then in operation 418, the server device may send a signal to the requesting client device indicating that the confidence score does not exceed the threshold or provide low-value content to the requesting client device. However, if the server device determines that the confidence score exceeds the threshold, then in operation 420, the client device may send content to the requesting client device.

[0130] Advantageously, by implementing a group signature hierarchy to authenticate content requests, server devices can filter out content requests originating from client devices of malicious entities. The group signature hierarchy allows client devices to request content from a content server without providing sufficient information for the content server to individually identify or fingerprint the client device, or to provide a security token that the content server relies on to authenticate content requests. Instead of providing a server-specific signature, the server providing the security token to the client device can remain anonymous to the content server by providing a group signature associated with a server association comprising a large number of servers in the security token. The client device can remain anonymous by providing a second group signature associated with a subgroup to which the client device is part. The subgroup can be large enough that the content server cannot identify the client device from the subgroup's signature. Therefore, a content server receiving content requests from client devices using the systems and methods described herein can serve content to client devices unrelated to malicious entities while avoiding serving content to malicious entities (e.g., entities requesting content using headless browsers). In doing so, the content server may be unable to identify the requesting client device or the server providing the security token to the client device.

[0131] In situations where the systems described herein collect or utilize personal information about users or applications installed on users' devices, users may be given the opportunity to control whether programs or features collect user information (e.g., information about the user's social networks, social behaviors or activities, occupation, user preferences, or the user's current location). Furthermore, before storing or using certain data, this data may be processed in one or more ways to delete personal information. For example, user identity may be processed to make it impossible to determine personally identifiable information about the user, or, if location information is available, the user's geographic location may be generalized (e.g., to the city, zip code, or state level), making it impossible to determine the user's specific location. Therefore, users can control how information is collected about them and how it is used by content servers.

[0132] The embodiments of the subject matter and operations described herein may be implemented in digital electronic circuits or in computer software, firmware, or hardware (including the structures disclosed herein and their equivalents) or in one or more combinations thereof. Embodiments of the subject matter described herein may be implemented as one or more computer programs (i.e., one or more modules of computer program instructions) encoded on one or more computer storage media to be executed by or control the operation of a data processing device. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals (e.g., machine-generated electrical, optical, or electromagnetic signals) to generate information for transmission to a suitable receiver device for execution by the data processing device. The computer storage medium may be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof, or may be included therein. Moreover, although the computer storage medium is not a propagation signal, it may be a source or destination of computer program instructions encoded as artificially generated propagation signals. The computer storage medium may also be one or more separate components or media (e.g., multiple CDs, disks, or other storage devices), or may be included therein. Therefore, computer storage media can be tangible.

[0133] 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.

[0134] The terms "client" or "server" include various means, devices, and machines for processing data, such as programmable processors, computers, systems-on-a-chip, or a combination thereof. Means may include special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, means may also include code that creates the runtime environment for the computer program in question, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. Means and runtime environments can implement a variety of different computing model infrastructures, such as network services, distributed computing, and grid computing infrastructures.

[0135] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language (including compiled or interpreted languages, declarative or procedural languages) and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored as part of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinating files (e.g., a file storing one or more modules, subroutines, or portions of code). A computer program can be deployed to run on a single computer, or on multiple computers located in one location or distributed across multiple locations and interconnected via a communication network.

[0136] The processes and logic flows described in this specification can be executed by one or more programmable processors running one or more computer programs to perform actions by manipulating input data and generating outputs. The processing and logic flows can also be executed by special-purpose logic circuitry (e.g., FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit)) and can be devices that can also be implemented as special-purpose logic circuitry (e.g., FPGA or ASIC).

[0137] Processors suitable for running computer programs include both general-purpose microprocessors and special-purpose microprocessors, as well as any one or more processors in any kind of digital computer. Generally, a processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for performing actions according to instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices (e.g., disks, magneto-optical disks, or optical disks) for storing data, or may be operatively coupled to receive data from, transfer data to, or both receive data from and transfer data to said one or more mass storage devices. However, a computer need not have such devices. Furthermore, a computer may be embedded in another device (e.g., a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive, to name a few). Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, 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. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0138] To provide interaction with the user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display), OLED (organic light-emitting diode), TFT (thin-film transistor), plasma, other flexible configurations, or any other monitor for displaying information to the user and keyboard), and a pointing device through which the user can provide input to the computer (e.g., a mouse, trackball, etc., or a touchscreen, touchpad, etc.). Other types of devices can also be used to provide interaction with the user; 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 voice input, speech input, or tactile input. Additionally, the computer can interact with the user by sending and receiving documents to and from the user's device; and by sending web pages to a web browser on the user's computing device in response to requests received from a web browser.

[0139] The embodiments of the subject matter described in this specification can be implemented in a computing system that includes back-end components (e.g., as a data server), or middleware components (e.g., an application server), or front-end components (e.g., a client computer with a graphical user interface or web browser through which a user can interact with embodiments of the subject matter described in this specification), or any combination of one or more such back-end components, middleware components, or front-end components. The components of the system can be interconnected via any form or medium of digital data communication (e.g., a communication network). Communication networks can include local area networks (“LANs”) and wide area networks (“WANs”), the internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0140] While this specification contains numerous specific implementation details, these details should not be construed as limiting any invention or the scope of the claims, but rather as descriptions of features characteristic of particular embodiments of a particular invention. Certain features described in the context of individual embodiments in this specification may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, although features may be described above as functioning in certain combinations, and even initially claimed so, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0141] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring the operations to be performed in the specific order shown or in a sequential order, or requiring all the shown operations to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system components in the above embodiments should not be construed as requiring such separation in all implementations, 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.

[0142] Therefore, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes illustrated in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking or parallel processing may be utilized.

Claims

1. A method for authentication control of content delivery, comprising: A server device receives a request for a content item from a computing device, the request including a security token associated with a signature associated with a central server, which is associated with a domain, wherein the signature is generated by the central server; The server device retrieves the central server's security key from the database of the domain or server device associated with the central server; The signature of the security token is decrypted by the server device using a security key; The server device identifies the authentication string from the decrypted signature in the security token, and the authentication string is associated with the security token. The server device compares the authentication string with the expected authentication string and determines that the authentication string matches the expected authentication string; In response to determining that the authentication string matches the expected authentication string, the server device identifies a confidence score for the security token, the confidence score indicating the likelihood that the computing device is not associated with a malicious entity; The server device determines that the confidence score does not exceed the threshold; and In response to determining that the confidence score does not exceed the threshold, the server device blocks the transmission of the content item to the computing device.

2. The method according to claim 1, wherein, In response to determining that the client security token sent by the computing device to the central server is valid, the central server sends a security token associated with a signature associated with the central server and a domain associated with the central server to the computing device.

3. The method according to claim 1, further comprising: In response to the server device determining that the confidence score does not exceed the threshold, The server device sends a signal to the computing device indicating that the confidence score has not exceeded the threshold.

4. The method according to claim 1, further comprising: The server device determines that the confidence score exceeds the threshold; and In response to the determination that the confidence score exceeds the threshold, the server device transmits the content item to the computing device.

5. A server device for authentication control of content delivery, comprising: A network interface for communicating with the first client device among multiple client devices; and The processor is configured as follows: Receive a request for a content item via a network interface and from a first computing device, the request including a security token associated with a signature associated with a central server, the central server being associated with a domain, wherein the signature is generated by the central server; Retrieve the security key of the central server from the database of the domain or server device associated with the central server; The signature of the security token is decrypted using the security key; Identify the authentication string from the decryption signature in the security token, the authentication string being associated with the security token; Compare the authentication string with the expected authentication string and determine that the authentication string matches the expected authentication string; In response to determining that the authentication string matches the expected authentication string, a confidence score for the security token is identified, the confidence score indicating the likelihood that the computing device is not associated with a malicious entity; It was determined that the confidence score did not exceed the threshold; and In response to the determination that the confidence score does not exceed the threshold, the transmission of the content item to the computing device is blocked.

6. The server device according to claim 5, wherein, In response to determining that the client security token sent by the computing device to the central server is valid, the central server sends a security token associated with a signature associated with the central server and a domain associated with the central server to the computing device.

7. The server device according to claim 5, wherein, The processor is also configured to: In response to determining that the confidence score did not exceed the threshold, Send a signal to the computing device indicating that the confidence score does not exceed the threshold.

8. The server device according to claim 5, wherein, The processor is also configured to: Determine that the confidence score exceeds the threshold; and In response to determining that the confidence score exceeds the threshold, the content item is transmitted to the computing device.

Images