Google has proposed a new web standard called Web Environment Integrity. You may have read about it on other sites, here's why the proposal could be a disaster for the web.
What is Google's Web Environment Integrity proposal?
Google has published an explainer that gets down to the nitty-gritty of its proposal. It outlines the importance of websites and trusting the client environment they run in, i.e. your web browser and operating system and their methods to protect user data, intellectual property, etc.
The goal for Web Environment Integrity seems to be to prevent fake interactions on websites, aka bots. Google wants to help websites verify that the visitor to their domain is not a robot, but an actual user.
The Mountain View company points out that users are concerned about the authenticity of interactions on social websites, i.e. fake interactions (likes, comments) that are used to promote news, posts, products, etc. The document mentions that it is an expensive ordeal for websites to run, and that advertisements help ease their burden, and that ads are meant for humans, i.e. users and not fake clicks by bots. It also quotes other examples, such as players of online games, who may want to know whether other players on the platform are using legitimate software that enforces the game's rules. This is essentially talking about anti-cheating tools to prevent cheaters from ruining the experience.
Google also played the security card, claiming that users may get tricked into installing malware that mimics genuine apps like banking apps, which in turn could steal the user's data, identity or runs a phishing attack. It wants to prevent bulk hijacking attempts, bulk account creation, password guessing attempts (password stuffing), and detect compromised devices where the user's data could be at risk.
Google says that these issues could be prevented by verifying if the request (attempt to access the website) came from the official app or other trustworthy software. It claims that websites need to differentiate between a trusted and untrusted environment (read environment = browsers).
In a nut-shell, Web Environment Integrity seems to be designed as an anti-fraud tool. While that may sound nice on paper, Google's examples are a sales pitch delivered by a salesman, to push their product as something positive, when in fact it benefits only themselves and their advertisers.
The explainer takes inspiration from existing native attestation signals such as Apple's App Attest and the Google Play Integrity API. As Ars Technica points out, Play Integrity (formerly known as SafetyNet) is an API in Android which apps can use to check if the phone has been rooted or not. The API will flag the device if it discovers that the device is rooted, and apps that use the API may refuse to run. This is pretty common in banking apps, games and some streaming service apps. These apps assume that the user could game the system with root access to phish banking data, cheat at games, etc. There was a time when we could use Magisk to hide the root status to pass SafetyNet, but it seems like ages ago. Google nearly killed custom roms when it started flagging unlocked bootloaders as a security risk.
Now imagine if the same thing happens on the web. It could affect the entire internet quite badly, but we'll get to this in a bit.
How Web Environment Integrity API could be implemented?
Websites will use a Web Environment Integrity API, this will allow them to verify the authenticity of visitors. When a user tries to access a web page, the site will request a token that attests the client environment. A third-party server that acts as the attester, i.e. attest to the device a web browser/operating system is running on, will test your device and sign a token (if your device passes the test). This token contains the attestation with a private key.
The attester's public key will be available to everyone. If your browser/device is attested, it becomes a trusted environment, but if it fails the check, it is seen as untrusted. The attester's server returns the token to the originating web page, and the web server checks if the token came from an attester that it trusts and verifies the token, and check its signature with the public key. If everything goes well, you will be able to access the website.
In layman's terms, when you visit a website in your browser, the site will ask a third-party service to verify the integrity of your computer or mobile phone which was used to access the website, before allowing you to view the page.
Theoretically, instead of a 404 error, could we actually see an error like "You cannot access the website because your browser/device has been modified" ? I almost can't believe what I am writing about here, has it really come down to this? And I thought AMP, FLoC were bad ideas.
Why you should be worried about Web Environment Integrity API
Web Environment Integrity API is a form of DRM (Digital Rights Management). It takes away the freedom of user choice, and could negatively impact the privacy of users.
DRMs in browser are not new, Google's Widevine is commonly used by streaming services such as Netflix, Amazon Prime, etc. to protect their data (from being downloaded). You may have noticed that trying to capture a screenshot on your phone may result in a blank screen if the video is protected, that's because the DRM prevents you from recording the media. You could argue that there is some sort of logic there, because those are paid services, and that they want to prevent users from accessing the media for free.
With Web Environment Integrity API however, regular websites could kick you off, simply because you are not using the web browser that they approve on the operating system, because they think it is unsafe. You can't just change the user agent. So, is Web Environment Integrity API not a DRM for websites? It is, this is an insane level of gatekeeping.
And if an attester checks your computer and browser, stores the data in a token and this is sent to the website that requested the token, does that not qualify as fingerprinting? Google's explainer claims that the "attestation payloads will only include information about device and application integrity, as attesters will not have access to the profile information in applications." Nice try, but I'm not entirely convinced by the words of a company that makes it revenue by selling ads.
The document states that Web Environment Integrity will only depend on the underlying hardware and software stack. It will not restrict a browser's functionality, including extensions. Is that supposed to be good news, to soften the blow, perhaps?
Here's the bigger problem. Who decides which browser is trusted? A third-party attester will, but who selects the attester? How does a company qualify to be one? There are no guidelines or rules for that in place, probably because the proposal listed on Chromestatus is still cooking, it's not ready yet.
Take a look at the example given in the explainer. It clearly describes Google Play as an attester. Google has a significant foothold in the smartphone market with Android, and its default browser, Chrome. It also leads the desktop browser market share. Does this automatically grant it the powers of the attester? Well, that does seem to be the case, and it could decide which browsers should be trusted or not be trusted.
Did you know that Apple already has an attestation system in place? It is called Private Access Tokens, and shipped with Safari, iOS 16, macOS 13 Ventura. This article by Tim Perry provides an in-depth analysis of why attestation of browsers is bad.
The proposal seems to be largely in favor of advertisers, rather than users. Google has actively fought against ad blockers, and Manifest V3 could just be the tip of the iceberg which the company wants to control the web with. Remember that conversation between Captain America and Nick Fury in the Winter Soldier where they talk about freedom, this entire scenario reminds me of it.
Mozilla opposes Web Environment Integrity API
A Mozilla representative has commented that the organization opposes the Web Environment Integrity API, it believes any attempt to restrict common web standard choices are harmful to the open web ecosystem. It also notes that detecting non-human traffic could adversely affect assistive technologies, automatic testing, and archiving & search engine spiders. While it agreed that detecting fraud and invalid traffic is a problem, Mozilla says that Web Environment Integrity API is not the solution for the issues.
Vivaldi slams Google's Web Environment Integrity API proposal
Vivaldi has published a much stronger response to criticize the Web Environment Integrity proposal. It poses some questions, such as would Microsoft be the gatekeeper on the Windows Store? Will Apple be the attester on Mac? It also speculates about how this could affect Linux user, whether Canonical, the parent company of Ubuntu, would become the attester for all Linux distros?
There is some concern about browser makers not choosing to implement the API, this would likely fail the attestation process, leaving them with no choice.
The article mentions that the European Union law will likely not allow a few companies to dictate which browsers should be allowed and which shouldn't. That process would be slow, meanwhile Google could rush into things and start implementing the API before the Parliament decides to act. In an interview with The Register, Jon von Tetzchner, the CEO of Vivaldi, slammed Google's idea by saying "A big part of the reason why there is a problem is the surveillance economy, and the solution to the surveillance economy seems to be more surveillance."
Hopefully other browser vendors like Brave, DuckDuckGo, Opera will join the fight against Web Environment Integrity API. Apple already has its own attestation method, and I doubt Microsoft will oppose this if it could somehow use it to shamelessly promote Edge.
As it stands, Web Environment Integrity is an obscene attempt at tightening the noose on users' choice and privacy.
What's your take on it?
Thank you for being a Ghacks reader. The post Google's Web Environment Integrity could be a disaster for the web appeared first on gHacks Technology News.
0 Commentaires