Modified client environments can pose significant challenges for developers. While jailbreaking, rooting, and modification in general aren’t necessarily harmful, hackers modify client environments to access unauthorized content and perform other inappropriate actions. In the Android environment, Play Integrity API protects app developers and users by checking whether a client has been modified. An equivalent API hasn’t existed for web - until now. Google recently prototyped Web Environment Integrity API, which secures browser integrity and prevents hacking. However, many people are concerned that, like Chrome’s Manifest V3 API (MV3), Web Environment Integrity API will restrict ad blockers in the name of security. To find out if these concerns are warranted, let’s delve deeper into Environment Integrity API.

‍

What is Web Environment Integrity API?

Web Environment Integrity API attests key attributes about the environment a client code is running on. For example, the API can reveal that an end user is operating a web client on a secure Android device, or that another user is browsing on a jailbroken iPhone. Most importantly, the API can detect various security breaches and problematic scenarios, with example use cases such as:

• Detect social media manipulation and fake engagement.
• Detect non-human traffic in advertising to improve user experience and access to web content
• Detect phishing campaigns (e.g. webviews in malicious apps)
• Detect bulk hijacking attempts and bulk account creation.
• Detect large scale cheating in web based games with fake clients
• Detect compromised devices where user data would be at risk
• Detect account takeover attempts by identifying password guessing

‍

How does Web Environment Integrity API work?

‍

‍

Web Environment Integrity API utilizes integrity tokens to communicate with and validate the client environment. These tokens are used as “proof” that a client environment is safe. Three main players are involved in the validation process: the website (client code), the third-party attestation API, and the server. A simplified analogy is going through security before a flight, where the website is a passenger, the attestation API is the scanner, and the server is the security officer. Similar to how a passenger is determined as a non-threat before boarding a flight, clients (end users) are “scanned” to ensure they are not harmful before accessing a website.

‍

The main steps of the process are:

1. A user loads a website.
2. The client code issues an integrity token (containing a payload) by calling a third-party attestation API.
3. The client code then sends a request to the server with the integrity token.
4. The server can validate the client's environment with the provided integrity token.
5. The user accesses the website.

For more details, check out the explainer on GitHub.

‍

Web Environment Integrity API and ad blocking

Neither the example use cases nor the technical functionalities of Environment Integrity API inherently restrict ad blocking. However, it’s theoretically possible for integrity tokens to collect information about which clients are using ad blockers. As Chrome’s developer, Google could then become a gatekeeper and restrict access to webpages for clients using ad blockers. Similarly, website developers (publishers) could actively issue integrity tokens and payloads in such a way as to determine whether the client is using an ad blocker. Like Google, the publishers could gate-keep their content and effectively create ad block walls to prevent access for ad-block users.

‍

At this point, it’s unclear what exact information will be stored in the tokens, so it’s too early to determine whether ad blockers will be prohibited. For what it’s worth, the proposal stated that Web Environment Integrity “does not restrict the indicated application’s functionality”. Until Google releases further details, ad blockers will have to wait and see to what extent they may be impacted.

‍