Browser attestation challenge and response system

Systems and methods for screening unauthorized devices are provided. More particularly, a challenge that includes a first set of data can be generated. The challenge can require a browser of a requesting device to perform a browser task with respect to the first set of data to generate a second set of data. The challenge can be provided to the requesting device and a response to the challenge can be received. The response can include the second set of data generated by the browser of the requesting device through performance of the browser task. It can be determined whether the browser of the requesting device is an authorized browser based, at least in part, on the second set of data. Whether or not the requesting device is authorized to access a resource can be based, at least in part, on whether the browser is an authorized browser.

FIELD

The present disclosure relates generally to online challenge-response schemes and, more particularly, to systems and methods that limit access to online resources by verifying browser authenticity through challenges and responses.

BACKGROUND

Trust is an asset in web-based interactions. For example, a user must trust that an entity provides sufficient mechanisms to confirm and protect her identity or other confidential information in order for the user to feel comfortable interacting with such entity. Further, an entity that provides an online resource must be able to block automated attacks that attempt to gain access to the online resource for malicious purposes. Automated programs, known as “robots” or “bots”, can attempt to gain access to a web resource. Thus, sophisticated authentication mechanisms that can discern between a resource request originating from a human being and a request generated by a bot are vital tools in ensuring that online resources are protected from automated attacks and developing the necessary relationship of trust between a resource provider and a user.

SUMMARY

One aspect of the present disclosure is directed to a computer-implemented method to screen for unauthorized devices. The method includes receiving, by one or more computing devices, a request from a requesting device to access a resource, The method further includes generating, by one or more computing devices, a challenge for the requesting device. The challenge can include a first set of data, and the challenge can require a browser of the requesting device to perform a browser task with respect to the first set of data to generate a second set of data. The method also includes providing, by the one or more computing devices, the challenge to the requesting device. The method includes receiving, by the one or more computing devices, a response to the challenge from the requesting device. The response can include the second set of data generated by the browser of the requesting device through performance of the browser task with respect to the first set of data. The method also includes determining, by the one or more computing devices, whether the browser of the requesting device is an authorized browser based at least in part on the second set of data. The method includes determining, by the one or more computing devices, whether the requesting device is authorized to access the resource based at least in part on whether the browser of the requesting device is an authorized browser.

Another aspect of the present disclosure is directed to a computing system for screening unauthorized devices. The system includes one or more processors and one or more memory devices. The one or more memory devices can store computer-readable instructions that when executed by the one or more processors cause the one or more processors to perform operations. The operations include receiving a request from a requesting device to access a resource. The operations further include generating a challenge for the requesting device. The challenge can include a first set of data, and the challenge can require the requesting device to perform a verification task with respect to the first set of data to generate a second set of data. The operations also include providing the challenge to the requesting device and receiving a response to the challenge from the requesting device. The response can include the second set of data generated by the requesting device through performance of the verification task with respect to the first set of data. The operations include determining whether a request to access the resource was sent by a browser of the requesting device based at least in part on the second set of data.

Yet another aspect of the present disclosure is directed to one or more tangible, non-transitory computer-readable media storing computer-readable instructions that when executed by one or more processors cause the one or more processors to perform operations. The operations include receiving a request from a requesting device to access a resource. The operations further include generating a challenge for the requesting device. The challenge can require a browser of the requesting device to perform a browser task without human input to generate a set of browser data based at least in part on a browser-type associated with the browser. The operations include providing the challenge to the requesting device and receiving a response to the challenge from the requesting device. The response can include the set of browser data generated by the browser of the requesting device through performance of the browser task without human input. The operations also include determining whether the browser-type associated with the browser is an authorized browser-type based at least in part on the set of browser data. The operations include determining whether the requesting device is authorized to access the resource based at least in part on whether the browser-type associated with the browser is an authorized browser-type.

Other example aspects of the present disclosure are directed to systems, apparatus, tangible, non-transitory computer-readable media, user interfaces, memory devices, and electronic devices for screening for unauthorized devices using browser-based verification challenges.

DETAILED DESCRIPTION

Example aspects of the present disclosure are directed to limiting access to online resources by verifying browser authenticity. For instance, a computing device (hereinafter, “requesting device”) can request access to an online resource. Bots typically do not request access to online resources through authentic browsers. To verify whether the request is coming from such a browser, a verification system can provide a verification challenge to the requesting device. In particular, the challenge can include one or more instructions prompting the requesting device to perform a browser task. The requesting device can perform the browser task to generate a response to the challenge and then provide the response to the verification system. The verification system can determine whether the browser of the requesting device is an authorized browser (e.g., one not typically associated with bots) based on the response. In the event that the browser is an authorized browser, the requesting device can be permitted to access the requested online resource.

More particularly, a requesting device can attempt to access an online resource through a computing device. As used herein, a requesting device can be a laptop computer, desktop computer, smartphone, tablet, wearable computing device, server, or any other suitable computing device. A requesting device can have a user associated therewith. However, in the event a bot is utilized, a user may not be associated with the requesting device.

In order to access the online resource, the requesting device can first be required to interact with a computerized verification system to attest the browser of the requesting device, thereby preventing bots from damaging the online resource. For instance, the verification system can provide a challenge to the requesting device, and the requesting device can gain access to the online resource if the requesting device “passes” the challenge. In some implementations, the challenge can require the requesting device to perform a browser task that causes the requesting device to generate a response that can be used to determine if the browser is authorized to access the online resource.

For instance, the challenge can include a first set of data and can require a browser of the requesting device to perform a browser task with respect to the first set of data to generate a second set of data. In some example implementations, the browser task can include executing a set of JavaScript instructions that can cause the requesting device to generate an indication of a Document Object Model (DOM) of the browser of the requesting device. As another example, the browser task can cause a browser of the requesting device to render a Scalable Vector Graphics (SVG) image. As yet another example, the challenge can include a hash function and the browser task can include application of the hash function to various data, as will be discussed further below.

In some implementations, the challenge-response protocols can be essentially invisible such that it is not readily visible by a user, and is thus minimally intrusive from the standpoint of the user. Moreover, the browser task required by the challenge can be performed without human input. The challenge can be provided to the requesting device attempting to gain access to the online resource.

The requesting device can generate one or more responses to the challenge. A response can include a second set of data generated by the browser of the requesting device through the performance of the browser task. For instance, if the browser task includes executing a set of JavaScript instructions requiring the generation of an indication of a Document Object Model (DOM), the second set of data can provide the indication of the Document Object Model (DOM) of the browser of the requesting device. As another example, if the browser task includes rendering a Scalable Vector Graphics (SVG) image, the second set of data can include the rendered image. As yet another example, the browser task can include applying a hash function to various data, including, for example, the indication of the DOM of the browser, the SVG image, or other items generated in response to portions of the challenge other than the hash function. Thus, in some implementations, the challenge can include a first stage and a second stage, where the first stage requires the requesting device to perform a first browser task to generate an intermediate answer (e.g., an indication of the DOM of the browser) and a second stage requires the requesting device to apply a hash function to the intermediate answer to provide a hashed answer (e.g., a hash of an indication of the DOM of the browser). In such implementations, the second set of data, included in the response, can include one or more hashed answers. After generation of the response, the requesting device can provide the response to the verification system.

The verification system can receive the response from the requesting device and determine whether the browser of the requesting device is an authorized browser. For instance, the verification system can compare the second set of data (included in the response) to target data. The target data can, for example, include one or more previous responses associated with one or more authorized browser-types.

Based at least in part on the comparison of the second set of data to the target data, the verification system can determine if the browser of the requesting device is an authorized browser. As an example, the verification system can identify a browser-type associated with the browser of the requesting device based at least in part on the comparison of the second set of data to the target data. The verification system can determine whether the browser-type associated with the browser is an authorized browser-type. For instance, certain browser-types that are not generally utilized by bots can be considered authorized browser-types. The verification system can determine that the browser is not an authorized browser if the browser-type associated with the browser of the requesting device is not an authorized browser-type. However, in the event that the browser-type associated with the browser of the requesting device is an authorized browser-type, the verification system can determine that the browser is an authorized browser.

The verification system can determine whether the requesting device is authorized to access the online resource based, at least in part, on whether the browser of the requesting device is an authorized browser. For example, if the browser is an authorized browser, the verification system can grant the requesting device access to the online resource. However, in the event that the verification system determines that the browser is not an authorized browser; the verification system can deny the requesting device access to the online resource. Moreover, in the event that the verification system determines that the request is not associated with a browser and/or that no browser is associated with the requesting device, the verification system can deny the requesting device access to the online resource. Additionally, and/or alternatively, the verification system can generate and provide another challenge to the requesting device that was denied access to the online resource.

According to another aspect of the present disclosure, the verification system can generate a challenge that includes a plurality of portions. Each portion can include one or more seeds, where each seed represents or otherwise includes a different browser task to be performed and/or the respective data upon which the task should be performed. Thus, in some implementations of the present disclosure, the verification system can generate challenges that require multiple browser tasks to be performed. The multiple browser tasks can be independent or dependent (e.g., sequential).

In some implementations, the seeds may also be of different types. As one example, the one or more seeds can include one or more static seeds that can, for instance, remain constant among the challenges. For example, every challenge provided by the verification system will include the one or more static seeds, while other seeds may change or rotate (e.g., randomly) among different challenges provided over time. As another example, the one or more seeds can include one or more known seeds with known responses. The seeds can also include one or more seeds for crowdsourcing and/or seeds to generate noise. Thus, at least some of the seeds may be used for crowdsourced data collection rather than verification of the requesting device. After sufficient crowdsourced data has been collected, the crowdsourcing seeds can be changed into seeds which are used for preforming requesting device authentication.

Thus, the present disclosure provides systems and methods for limiting access to online resources by verifying browser authenticity. In such fashion, the risk of exposing online resources to bots can be reduced through less obstructive challenge-response protocols. For example, an online consumer review service that receives a request to access an online product rating tool can utilize the verification system to protect the integrity of the product rating. The verification system can attest the browser of a requesting device through invisible challenges including browser tasks that do not require human input, thereby reducing potential bot exposure while allowing human users to access the online rating tool with less interruption.

With reference now to the Figures, example aspects of the present disclosure will be discussed in more detail. For instance,FIG. 1depicts an overview of an example system100for providing challenges. In particular, system100can include a resource provider102, a computerized verification system104, a target database106, a resource108, and a requesting device110. In some implementations, resource provider102and verification system104can communicate with each other over a network.

Resource provider102can be associated with an online or other resource108. By way of example, resource provider102can be associated with a consumer rating service with one or more consumer rating tools. However, the resource provider102can provide access to any number of different types of resources108, including any data, tools, services, information, files, or other forms of resources for which verification prior to access is desired. The resources108(and/or the data associated therewith) can, for example, be stored in a database associated with resource provider102.

Resource provider102can receive a request from requesting device110for access to the online resource108(e.g., consumer rating tool). In response to the request, resource provider102can coordinate with verification system104to provide a verification challenge to requesting device110.

Verification system104can be implemented using one or more computing devices, such as, for example, one or more servers. Verification system104can be configured to generate verification challenges and to provide such challenges to requesting device110in response to, for example, a request from requesting device110. In some implementations, the challenges can be browser task based challenges. For instance, a challenge can include a first set of data and can require a browser of requesting device110to perform a browser task with respect to the first set of data. The browser task can include a set of instructions that can, upon execution, cause requesting device110to generate a second set of data.

For instance, as indicated above, the challenge can include a hash function and the browser task can include application of the hash function to various data. Additionally, and/or alternatively, the browser task can include a set of JavaScript instructions that can cause, upon execution, requesting device110to generate an indication of a Document Object Model (DOM) of the browser of requesting device110. As another example, the browser task can require a browser of requesting device110to render a Scalable Vector Graphics (SVG) image.

In some implementations, the challenge-response protocols can be essentially invisible. For instance, verification system104can be configured to generate an invisible challenge, such that the challenge is not readily visible by a user. In some instances, the browser task (and/or its instructions) can be viewed in the html language associated with the browser; however, a user associated with requesting device110cannot readily view the browser task without such inspection. Additionally, and/or alternatively, the browser task required by the challenge can be performed without human input. For instance, the browser task can include applying a hash function to various data, for example, an indication of a DOM of the browser, an SVG image, or other items generated in response to the challenge. Requesting device110and/or the browser can perform the browser task (e.g., apply the hash function) to generate a response without input from a user of requesting device110. In this manner, requesting device110can generate a response to a challenge with less user interruption.

Verification system104can be configured to provide a challenge to requesting device110. In some implementations, verification system104can be configured to directly provide the challenge to requesting device110. In some implementations, verification system104can be configured to indirectly provide the challenge to requesting device110via resource provider102. For example, the resource provider102can utilize an application programming interface (API) to request and receive a challenge from the verification system104and then provide the received challenge to requesting device110.

Verification system104can be configured to receive a response to the challenge. For instance, verification system104can be configured to directly receive a response to the challenge from requesting device110. In other implementations, the verification system104indirectly receives a response from requesting device110via resource provider102. For example, the resource provider102can utilize the API to provide the received response to the verification system104and then receive an indication of the validity of the response from the verification system104.

The response can include a second set of data generated by the browser of requesting device110through the performance of the browser task. For instance, the second set of data can provide the indication of the Document Object Model (DOM) of the browser of requesting device110, a rendered Scalable Vector Graphics (SVG) image, and/or one or more hashed answers, as further described herein.

As shown, verification system104can be configured to access target data from a target database106. In example implementations, target database106can be a single database located in a single location, or can include multiple databases spread across multiple locations. As verification system104generates challenges and receives responses, it may store the challenge-response pair in the target database106. The target data can include, for example, one or more previously received responses to one or more challenges and the data associated therewith. Additionally, and/or alternatively, the target data can include one or more known responses to one or more challenges and the data associated with the one or more known responses.

By way of example, target data can include previously received and/or known indications of browser DOM, SVG images, hash values, and/or other portions of a response for each verification challenge. The responses included in the target data can include metadata, a pointer, a link, and/or some other type of identifier by which verification system104can identify which responses are associated with a particular challenge. The responses can be collected and stored in target database106by verification system104using crowdsourcing techniques. Additionally, and/or alternatively, verification system104can cluster the responses to effectively group them. Thus, in some implementations, crowdsourced answers can be clustered to identify a “correct” answer indicated by the crowdsourced data.

Moreover, the responses stored in the target data can be associated with a browser-type. The browser-type can be associated with the browser of requesting device110that provided the stored response. The known responses can be associated with one or more browser-types of one or more browsers that are known to generate a known response to a given challenge. The responses and/or associated browser-types can include metadata, a pointer, a link, and/or some other type of identifier by which verification system104can identify the browser-type associated with a response. Certain browser-types can be considered authorized browser-types. For instance, browser-types that are not generally utilized by bots can be considered authorized browser-types.

Verification system104can be configured to determine whether a browser exists on requesting device110. For instance, verification system104can be configured to determine whether the request to access resource108was sent by a browser of requesting device110based, at least in part, on examination of the second set of data. If requesting device110is unable to perform the browser task and/or generates a second set of data that does not indicate a browser exists, verification system104can determine that the request for resource108was not sent by a browser of requesting device110. In such a case, verification system104can deny requesting device110access to resource108. If requesting device110is able to perform the browser task and/or generate a second set of data that indicates a browser may exist, verification system104can determine whether the browser is an authorized browser.

In addition, if the response indicates that that requesting device has a browser, the verification system104can be configured to further determine whether the browser of requesting device110is an authorized browser based, at least in part, on the response. For instance, verification system104can be configured to receive a response to a challenge from requesting device110. The response can include the second set of data generated by the browser of requesting device110through performance of the browser task. Verification system104can be configured to compare the second set of data (included in the response) to the target data to determine whether an authorized browser exists.

For example, if the browser task of a challenge includes rendering a Scalable Vector Graphics (SVG) image, the second set of data generated by the browser of requesting device110through performance of the browser task can include least a portion of the rendered image or a hash of at least the portion of the rendered image. The target data of target database106may include one or more previously received rendered images that were received by verification system104in response to a same or similar challenge. Each of the one or more previously received rendered images can be associated with a browser-type that identifies the type of browser of requesting device110that provided the one or more previously received images. Verification system104can, for instance, compare the rendered image included in the second set of data to the one or more previously received rendered images of the target data to determine which browser-type is associated with the browser of requesting device110currently requesting access to resource108.

If the browser-type associated with the browser of requesting device110is not an authorized browser-type, verification system104can be configured to determine that the browser is not an authorized browser. If, however, the browser-type associated with the browser of requesting device110is an authorized browser-type, verification system104can be configured to determine that the browser is an authorized browser. Verification system104can be configured to authorize requesting device110to access requested resource108, for instance, if it is determined that the browser of requesting device110browser is an authorized browser.

FIG. 2depicts a flow diagram of an example method (200) to screen for unauthorized devices according to example embodiments of the present disclosure. Method (200) can be implemented by one or more computing devices, such as one or more of the computing devices depicted inFIG. 5. In addition,FIG. 2depicts steps performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the steps of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, or modified in various ways without deviating from the scope of the present disclosure.

At (202), method (200) can include receiving a receiving a request from requesting device110to access resource108. For instance, verification system104can receive a request from requesting device to access resource108. In some implementations, verification system104can receive a request to engage in a verification process to access resource108. As such, the request to engage in the verification process can be the request to access resource108.

At (204), method (200) can include generating a challenge requiring a browser task. For instance, verification system104can generate a challenge for requesting device110that has requested access to resource108. The challenge can allow verification system104to determine whether or not requesting device110should be authorized to access requested resource108.

The challenge can include a first set of data and the challenge can require a browser of requesting device110to perform a browser task with respect to the first set of data to generate a second set of data. The first set of data can include, for instance, JavaScript instructions and the browser task can include execution of the JavaScript instructions. By way of example, the browser task can require requesting device110(and/or the browser of requesting device110) to generate an indication of a Document Object Model (DOM) of the browser. In another example, the browser task can require requesting device110(and/or the browser of requesting device110) to render a Scalable Vector Graphics (SVG) image. As yet another example, the first set of data can include a hash function and the browser task can include application of the hash function to various data. For instance, the hash function can be applied to the indication of the DOM of the browser, the SVG image, or other items generated in response to portions of the challenge other than the hash function.

Additionally, and/or alternatively, the challenge can include a first stage and a second stage. The first stage can, for instance, require requesting device110to perform a first browser task to generate an intermediate answer. The intermediate answer can include, for example, an indication of the DOM of the browser and/or least a portion of the rendered SVG image. The second stage can require requesting device110to apply a hash function to the intermediate answer to provide a hashed answer.

At (206), method (200) can include transmitting the challenge to requesting device110. For instance, verification system104can provide the challenge to requesting device110. In some implementations, verification system104can directly provide the challenge to requesting device110. Additionally, and/or alternatively, verification system104can provide the challenge to resource provider102and resource provider102can provide the challenge to requesting device110.

At (208), method (200) can include receiving a response to the challenge from requesting device110. For instance, verification system104can receive a response to the challenge from requesting device110. The response can include a second set of data generated by the browser of requesting device110through performance of the browser task with respect to the first set of data. For example, if the browser task includes execution of a set of JavaScript instructions to generate an indication of a Document Object Model (DOM) of the browser of requesting device110, the second set of data can provide at least an indication of a Document Object Model (DOM) of the browser of requesting device110. In another example, if the browser task includes rendering of a Scalable Vector Graphics (SVG) image, the second data set can include at least a portion of the rendered image. In yet another example, if the browser task includes performing a hash function, and the second set of data can include a hash value.

Additionally, and/or alternatively, if the challenge includes first and second stages and the second stage includes applying the hash function to an intermediate answer (generated in response to the first stage), the second set of data can include a hashed answer. The hashed answer can include, for example, a hash of the indication of the Document Object Model (DOM) or a hash of at least the portion of the rendered image.

At (210), method (200) can include determining whether the browser of requesting device110is an authorized browser. Bots may request access to online resources without the use of a browser. Accordingly, verification system104can determine whether the request to access resource108was sent by a browser at all and/or whether a browser even exists on requesting device110.

For instance, verification system104can process the response received from requesting device110to determine, for example, whether a browser exists on requesting device110and/or whether a browser generated the response (and/or the second set of data) through performance of a verification task. In this way, verification system104can determine whether a request to access resource108was sent by a browser of requesting device110based at least in part on the response (and/or the second set of data).

If no browser exists and/or the request for resource108was not sent from a browser, verification system104can deny authorization of requesting device110to requested resource108. If, however, verification system104determines that a browser exists and/or sent the request to access resource108, verification system104can determine if the browser is an authorized browser.

For instance, verification system104can determine whether the browser of requesting device110is an authorized browser based, at least in part, on the second set of data included in the response received from the requested device. In some implementations, verification system104can compare the second set of data to target data that includes one or more browser-type, as described above. The verification system can identify a browser-type associated with the browser based, at least in part, on the comparison of the second set of data to the target data. Additionally, and/or alternatively, the verification system can determine whether the browser-type associated with the browser is an authorized browser-type.

For example, the second set of data can include a rendered Scalable Vector Graphics (SVG) image and verification system104can determine whether the browser of requesting device110is an authorized browser by comparing the rendered image to one or more target images. The target images can include previously rendered images that were received from browsers associated with authorized browser-types (e.g., ones not typically associated with bots). If the rendered image matches or is similar to one or more of the target images, verification system104can determine that the browser-type of the browser is the same as, or at least similar to, the authorized browser-type associated with the target image. In such a case, verification system104can determine that the browser of requesting device110is an authorized browser. However, if the rendered image (included in the second set of data of the response) does not match or is dissimilar to one or more target images, verification system104can determine that the browser-type of the browser is not an authorized browser-type, and thus, is not an authorized browser.

At (212), method (200) can include determining whether requesting device110is authorized to access resource108. For instance, verification system104can determine whether requesting device110is authorized to access resource108based at least in part on whether the browser of requesting device110is an authorized browser. For example if verification system104determines that the browser is an authorized browser, verification system104may authorize requesting device110to access resource108(e.g., an online rating tool). If, however, verification system104determines that requesting device110did not request access to resource108via a browser or that the browser is not an authorized browser, verification system104can deny requesting device110access to requested resource108.

FIG. 3depicts a flow diagram of an example method to generate a challenge according to example embodiments of the present disclosure. Method (300) can be implemented by one or more computing devices, such as one or more of the computing devices depicted inFIG. 5. In addition,FIG. 3depicts steps performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the steps of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, or modified in various ways without deviating from the scope of the present disclosure.

At (302), method (300) can include generating a random number. For instance, verification system104can use a random number generator to generate a random number.

At (304), method304can include generating a set of JavaScript instructions based on the random number. For instance, each random number can be associated with a set of JavaScript instructions. In one example, the JavaScript instructions can include instructions that when executed cause a browser to generate an indication of a Document Object Model (DOM) of the browser. In another example, the JavaScript instructions can include instructions that when executed cause a browser to render a Scalable Vector Graphics (SVG) image.

At (306), method (300) can include generating a challenge with a browser task that includes execution of the JavaScript instructions. For instance, verification system104can generate a challenge that includes a first set of data and requires requesting device110to perform the browser task with respect to the first set of data. The first set of data can include the JavaScript instructions, and the browser task can include execution of the JavaScript instructions.

Additionally and/or alternatively, verification system104can generate a challenge that includes a plurality of portions. Each portion can include one or more seeds, where each seed represents or otherwise includes a different browser task to be performed and the data upon which the task should be performed. Thus, in some implementations of the present disclosure, the verification system104can generate challenges that require multiple browser tasks to be performed. The multiple browser tasks can be independent or dependent (e.g., sequential).

The seeds may also be of different types. As one example, the one or more seeds can include one or more static seeds that can, for instance, remain constant among the challenges. For example, every challenge provided by the verification system will include the static seeds, while other seeds may change or rotate among different challenges provided over time. As another example, the one or more seeds can include one or more known seeds with known responses. The seeds can also, and/or alternatively, include one or more seeds for crowdsourcing and/or seeds to generate noise. Thus, at least some of the seeds may be used for crowdsourced data collection rather than verification of requesting device110. After sufficient crowdsourced data has been collected, the crowdsourcing seeds can be changed into seeds which are used for requesting device authentication.

In some implementations, a challenge can include a hash function and the browser task can include the application of the hash function to various data. For example, the browser task can include applying the hash function to the indication of the DOM of the browser, the SVG image, or other items generated in response to portions of the challenge other than the hash function.

In some implementations, the challenge can include a plurality of stages. For instance, the challenge can include a first stage and a second stage. The first stage can require requesting device110to perform a first browser task to generate an intermediate answer (e.g., an indication of the DOM of the browser, at least a portion of a rendered SVG image). The intermediate answer can be generated through execution of a set of JavaScript instructions. The second stage can require requesting device110to apply a hash function to the intermediate answer to provide one or more hashed answers. The hashed answers can include, for example, a hash of the indication of the Document Object Model (DOM) of the browser of requesting device110and/or a hash of at least a portion of a rendered image. In such implementations, the response to the challenge can include the one or more hashed answers.

FIG. 4depicts a flow chart of an example method (400) for verifying a requesting device according to an example embodiment of the present disclosure. Method (400) can be implemented by one or more computing devices, such as one or more of the computing devices depicted inFIG. 5. In addition,FIG. 4depicts steps performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the steps of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, or modified in various ways without deviating from the scope of the present disclosure.

At (402) a requesting device can request a resource or access to an online resource from a resource provider. At (404) the resource provider can receive the request from the requesting device.

At (406) resource provider can instruct the requesting device to engage in a verification process. At (408) the requesting device can receive the instructions from the resource provider to directly engage with the verification system. As an example, the resource provider can instruct the requesting device at (406) by redirecting the requesting device so that it directly connects with the verification system and begins the verification process.

As another example, at (406) the resource provider can provide the requesting device with a client-side script that, when executed by the requesting device, causes the requesting device to directly engage with the verification system. For example, the client-side script can be included in an inline frame, embedded object, portlet, or other embedded application or widget. In some implementations, the client-side script can be included in a plug-in provided from the verification system to the resource provider. Furthermore, in some implementations, at (406) the resource provider can provide the requesting device with a public key identifying the resource provider to the verification system.

At (410) the requesting device can transmit a request directly to the verification system to engage in a verification process. At (412) the verification system can receive the request from the requesting device.

As an example, the request transmitted at (410) can be formatted according to an application programming interface associated with the verification system. For example, the request can be transmitted as a result of executing a client-side script provided to the requesting device at (406). Furthermore, in some implementations, the request transmitted at (410) can include a public key associated with the resource provider.

At (414) the verification system can generate a challenge requiring the requesting device to perform a browser verification task. As indicated above, the browser task can include, rendering a Scalable Vector Graphics (SVG) image. As another example, the browser task can include performing a hash function and/or applying a hash function to various data.

At (416) the verification system can provide the challenge, including the browser task, to the requesting device. At (418) the requesting device can receive the challenge from the verification system.

At (420) the requesting device (and/or the browser of the requesting device) can perform the browser task and generate a response to the challenge. The requesting device (and/or the browser of the requesting device) can perform the browser task without human input. The response can also be essentially invisible, as similarly indicated above. The response can include a second set of data generated by the browser of the requesting device through performance of the browser task. For example, the requesting device can generate a second set of data that includes at least a portion of the rendered image through the performance of a browser task that includes rendering a Scalable Vector Graphics (SVG) image. The Scalable Vector Graphics (SVG) image can include any shape. In another example, the requesting device can generate a second set of data that includes an indication of a Document Object Model (DOM) of the browser of the requesting device through the performance of a browser task that includes executing JavaScript instructions to generate an indication of a Document Object Model (DOM).

Additionally, and/or alternatively, the requesting device can generate a second set of data that includes a hash value through the performance of a browser task that includes performing a hash function. In some implementations, the requesting device can generate a response that includes a hashed answer that is created by applying a hash function to various data. The response can include, for example, a hash of an indication of the Document Object Model (DOM) of the browser of the requesting device and/or a hash of at least a portion of a rendered image.

At (422) the requesting device can provide the response to the challenge to the verification system. At (424) the verification system can receive the response from the requesting device.

At (426) the verification system can determine whether the request was sent by a browser and, if so, whether the browser is an authorized browser. For instance, the verification system can determine that the request was sent by a browser based, at least in part, on the second set of data generated through performance of the browser task. As indicated above, the verification system can determine whether the browser of the requesting device is an authorized browser based at least in part on the second set of data. For instance, the verification system can compare the second set of data to target data to determine whether the browser is an authorized browser, as indicated above.

At (428) the verification system can determine whether the requesting device is authorized to access the requested online resource. For instance, if the verification system determines that the browser of the requesting device is an authorized browser (e.g., one not typically associated with bots), the verification system can determine that the requesting device should be authorized to access the resource. If, however, the verification system determines that the browser of the requesting device is not an authorized browser or that the request was not sent from a browser, then the verification system can determine that the requesting device should be denied access to the resource.

At (430), if the verification system determines that the requesting device is not authorized to access the requested resource; then at (432) the verification system can deny the requesting device authorization to access the resource. The verification system can generate and provide another challenge to a requesting device that was denied access to the online resource.

If the verification system determines that the requesting device is authorized to access the requested resource, then at (434) the verification system can provide the requesting device authorization to access the resource. At (436) the requesting device can receive authorization to access the requested resource. The requesting device, the resource provider, and/or the verification system can communicate to allow the requesting device to access the online resource. This can be accomplished by using, for instance, a verification token provided by the verification system.

Method (400) illustrates one non-limiting example implementation by which a requesting device, resource provider, and/or verification system can initiate a verification process. In other implementations, the resource provider can communicate with the verification system and the verification system can provide the challenge to the resource provider. For example, the resource provider can interact with the verification system using an API. The resource provider can provide the challenge directly to the requesting device. Additionally, and/or alternatively, the resource provider can receive the response from the requesting device and/or the verification system can communicate with the resource provider to allow the resource provider to determine whether the browser of the requesting device should be authorized to access the requested resource.

FIG. 5depicts an example computing system500that can be used to implement the methods and systems according to example aspects of the present disclosure. The system500can be implemented using a client-server architecture that includes a server510that communicates with one or more requesting devices530and/or resource provider550over a network540. The system500can be implemented using other suitable architectures, such as a single computing device.

The system500includes a server510, such as a web server. Server510can host a computerized verification system configured to grant or deny authorization to access online resources. Server510can be implemented using any suitable computing device(s). Server510can have one or more processors512and one or more memory devices514. Server510can also include a network interface used to communicate with one or more requesting devices530and/or one or more resource provider550over the network540. The network interface can include any suitable components for interfacing with one more networks, including for example, transmitters, receivers, ports, controllers, antennas, or other suitable components.

The one or more processors512can include any suitable processing device, such as a microprocessor, microcontroller, integrated circuit, logic device, or other suitable processing device. The one or more memory devices514can include one or more computer-readable media, including, but not limited to, non-transitory computer-readable media, RAM, ROM, hard drives, flash drives, or other memory devices. The one or more memory devices514can store information accessible by the one or more processors512, including computer-readable instructions516that can be executed by the one or more processors512. The instructions516can be any set of instructions that when executed by the one or more processors512, cause the one or more processors512to perform operations.

The instructions516can be executed by the one or more processors512to implement, for instance, a challenge generator520, a browser authorizer522, and device authorizer524. Challenge generator520can be configured to generate a challenge that includes a browser task. Browser authorizer522can be configured to receive responses to the challenges and to determine whether a request was sent from a browser and/or whether a browser of a requesting device is an authorized browser. Device authorizer524can be configured to determine whether to deny or grant a requesting device authorization to access a requested resource.

As shown inFIG. 5, the one or more memory devices514can also store data518that can be retrieved, manipulated, created, or stored by the one or more processors512. The data518can include, for instance, target data, challenge data, and other data. The data518can be stored in one or more databases. The one or more databases can be connected to server510by a high bandwidth LAN or WAN, or can also be connected to server510through network540. The one or more databases can be split up so that they are located in multiple locales.

Server510can exchange data with one or more requesting devices530and/or one or more resource provider550over the network540. Although one requesting device530and one resource provider550are illustrated inFIG. 5, any number of requesting devices530and/or resource providers550can be connected to server510over the network540. Each of the requesting devices530can be any suitable type of computing device, such as a general purpose computer, special purpose computer, laptop, desktop, mobile device, navigation system, smartphone, tablet, wearable computing device, a display with one or more processors, or other suitable computing device.

Similar to server510, a requesting device530can include one or more processor(s)532and a memory534. The one or more processor(s)532can include one or more central processing units (CPUs), graphics processing units (GPUs) dedicated to efficiently rendering images or performing other specialized calculations, and/or other processing devices. The memory534can include one or more computer-readable media and can store information accessible by the one or more processors532, including instructions536that can be executed by the one or more processors536and data538. For instance, the memory534can store instructions536for implementing a user interface in the event that requesting device530is a user device.

In the event the requesting device530ofFIG. 5is a user device, requesting device530can include various input/output devices for providing and receiving information from a user, such as a touch screen, touch pad, data entry keys, speakers, and/or a microphone suitable for voice recognition. For instance, requesting device530can have a display device539for presenting a user interface.

Requesting device530can also include a network interface used to communicate with one or more remote computing devices (e.g., server510, resource provider550) over the network540. The network interface can include any suitable components for interfacing with one or more networks, including for example, transmitters, receivers, ports, controllers, antennas, or other suitable components.

Similar to server510, a resource provider550can include one or more processor(s)552and a memory554. The one or more processor(s)552can include one or more central processing units (CPUs), graphics processing units (GPUs) dedicated to efficiently rendering images or performing other specialized calculations, and/or other processing devices. The memory554can include one or more computer-readable media and can store information accessible by the one or more processors552, including instructions that can be executed by the one or more processors552and data558. For instance, the memory556can store instructions556for directing a requesting device to a verification system for a verification process. The data558can include, for instance, data associated with one or more resource. The data558can be stored in one or more databases. The one or more databases can be connected to resource provider550by a high bandwidth LAN or WAN, or can also be connected to resource provider550through network540. The one or more databases can be split up so that they are located in multiple locales.

Resource provider550can also include a network interface used to communicate with one or more remote computing devices (e.g. server550, requesting device530) over network540. The network interface can include any suitable components for interfacing with one more networks, including for example, transmitters, receivers, ports, controllers, antennas, or other suitable components.

Network540can be any type of communications network, such as a local area network (e.g. intranet), wide area network (e.g. Internet), cellular network, or some combination thereof. Network540can also include a direct connection between requesting device530, server510, and/or resource provider550. In general, communication between server510and requesting device530can be carried via a network interface using any type of wired and/or wireless connection, using a variety of communication protocols (e.g. TCP/IP, HTTP, SMTP, FTP), encodings or formats (e.g. HTML, XML), and/or protection schemes (e.g. VPN, secure HTTP, SSL).