Google Abandons Web Environment Integrity API
theregister.com
theregister.com
I'm not as dismissive of this as the Register is; it's definitely less harmful than the original proposal, but it's still DRM, and now it's no longer going through a standards process so we just don't have a ton of details about how it will work.
I honestly feel like this announcement should probably be getting more skepticism than I've seen from the news sites reporting it. I'm not saying it's just as bad, I'm just saying we should question how much this is going to help security for end users or whether this is just going to to turn into more DRM to let embedded webapps act like native apps.
Embedded webview is a web browser. This allows them to launch an API for remote attestation as a working implementation in a web browser and ship it to developers and users -- and that's a big chunk of standardization right there.
----
I'm not thrilled with it for Android either, but if I could trust that it was only ever going to stay in Android webview then I'd feel at least a little better about it. But Google has no way to credibly commit to that, and they've given no details or retrospectives about WEI. We get like 2 paragraphs in an email thread and 2 sentences in a press release that just says, "yeah, we're not working on that anymore." It's very difficult to trust that.
For example this could be used by Google to allow apps to embed a Google login page without them being able to access the users credentials or steal the full-access auth token (although this is still a bad idea for a variety of ways including click jacking, confusing overlays, conditioning the user to type their password into untrusted apps... but the raw capability is interesting and could potentially have "reasonable" use cases)
The problem with embedding Google login pages probably isn't user credential stealing as much as it's phishing? Webviews don't show the URL on Android, so what about this change prevents me from sending you to a "Google" log-in page that harvests your credentials using an old-fashioned phishing attack?
Okay, I can't steal the credential directly from the actual Google log-in, but is that how most malicious actors are stealing log-in information today? I wouldn't have guessed that, but :shrug: maybe I'm wrong. It seems like for all the problems you bring up, standardizing a feature to use user-controlled browsers for a subset of auth requests for native apps would be way better. Or (for all of my skepticism about them) using passkeys. Both would provide more opportunities to encourage developers/companies to do auth the "right" way -- via limited access tokens where credentials aren't shared between apps.
Don't get me wrong, embedded log-in forms in apps are dangerous for user security, but it seems like there are far better solutions to that problem that don't have any of the downsides of attestation?
----
Edit: Also, I'm realizing as I'm typing this that "non-approved apps shouldn't be able to load certain web pages" would be a far better candidate for a user-permission with sensible defaults rather than a server setting. Browsers have CORS requests today, the key point being that as a user, if I want to, I can override them. It changes the entire model from being "prove to the server that you're trustworthy" to "here is a recommendation to the client (in this case the Android OS) on how to keep the user safe, and if you want to ignore it, fine, but you probably shouldn't by default."
I still am not sure this would solve phishing and I'm not sure it would be a meaningful increase in security, but I'm realizing that if this wasn't attestation and Android was announcing that they were rolling out user-controlled permissions and routing tables for the system webview that would allow you to specify allowed domains on system/app level, I would only have praise for that announcement.
Could copy CORS for servers to set defaults; webview would do a preflight check for app IDs based on the system and refuse to load the webpage if the "CORS" request fails. I'd support that as a web standard, off the top of my head I don't think it would have almost any of the downsides of attestation since it would ultimately be up to the user-agent whether to respect the restriction, not the server.
I really like the engineering concept of encouraging developers to fall into a "pit of success" and I wonder if having an alternate auth flow that genuinely avoids most of these problems beyond the very narrow "developers can access the context of the current web page" problem would be better. We really shouldn't do embedded login forms at all, we should encourage developers to move away from them.
I'd support a web standard that made it easier to use the user-controlled actual browser to handle auth requests by apps. That would at least give the user visual access to the URL which would fend off some phishing attacks. And (assuming the FIDO Alliance shapes up and actually addressed current problems with spec) passkeys would be even better for this since cross-environment authentication that doesn't transfer credentials and is invulnerable to (most) phishing is passkey's entire deal.
I don't want to make a hard claim because I don't know the research, but I would not take it as a given that a change that as a side-effect encourages developers to embed login forms is a net benefit for user security.
Honestly I'm not sure why oauth became such a thing and mutual SSL did not. Most "social login" use cases don't need a token that grants any access to anything from the idp. Just proof of id, which could be done in the background by your browser/OS service though some standardized cert renewal process.
What I'm asking is whether or not the Play Integrity API supports remote attestation on its own today (ie, before any of the webview changes ship). Or I guess, more specifically, is there a challenge-response API currently for the Play Integrity API that a remote server could use?
If yes, then sure, I buy that this is not really adding anything new. If no, then adding a webview API does seem to me like a meaningful expansion of Android's DRM capabilities.
https://www.xda-developers.com/safetynet-hardware-attestatio...
This was mentioned earlier in the thread if someone wants to follow the source.
Really messed up having something so far reaching and giving it such an innocuous name a normal person couldn't possibly understand the implications of. Definitely an evil mind behind that one.
To this day some ceremonials of Parliament like the King's Assent to promulgate legislation are still in Norman French.
When you buy it, it's your hardware, not theirs.
You can take apart the hardware and do anything you want with it. Replace any of chips, use any of the components to make your own console, etc. It’s not Sony or Microsofts fault you don’t have the technical chops for it.
The principal at work here is that if you own it, you can do what you want with it.
It is also Sony and Microsoft's fault if they go after you legally for doing what you want with hardware you bought.
Security is about making sure that something happen via a certain path, without things going wrong in ways that can be abused.
Web Integrity effectively enables a way for, say, a bank to validate that the request isn't coming from botnet VMs spun up in the cloud, but rather an actual device with an actual human behind it. In fact, many websites already try to accomplish this with fingerprinting, which is why certain browsers and VPNs are already effectively blocked from the web.
Yes, it has the effect of limiting your freedom and privacy, but there is a definite security gain here that will lower the likelihood of account compromise.
Security != privacy; and security != freedom. Often there's a tradeoff. Security engineers are employed by their company to increase security - not freedom, and not privacy (unless mandated by regulation), hence the bias you typically see from them.
https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes...
It would only ensure that the laptop user does not run software that is not approved by Google or similar, a DRM, as Trojans will continue to find ways to disguise themselves and insert themselves into authorized processes.
The company would find difficult to run custom software not covered by such DRM. In time, the Web Environment Integrity API organisation would say that there are too many authorisation requests or similar and demand economic compensation from developers to be included in the authorized filter scans, at time the supposed initial objective is not accomplished, as this DRM does not ensure the laptop is not infected.
A good example is Xbox, for which there is no known custom software, which in turn guarantees the lack of cheating software.
I am quite sure that the client programs need to be cooperating for the WEI to be practical.
the problem is not the User wanting to download your content, bypassing ads, or spoofing Geo location using VPNs, or sharing of passwords.
The real issue is with the Providers/Vendors relying on the Web as a Cheap Ways & Means to quickly access, conquer the market.
The web is a generic platform, powered by general-purpose tech and methods, therefore it's "open", "cheap", and easily accessible, that's why it's popular and adopted globally.
There are tradeoffs - choose web for being cheap, open and accessible, or chose to build expensive, risky custom standalone services.
The tables are stacked against us.
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
That makes it _really_ hard to believe they're debating in good faith.
Anyway the entire thread makes it sound like they're temporarily backing down but still intenting to implement something similar in the future:.
Apparently rights of way are tough to determine on this road that's well over a century old, but the Forest is working on it.
In the meantime, the doctors' business were figuratively destroyed and their property vandalized. [I don't approve of illegal actions.]
And I think they're genuinely confused by the reaction of the general public. They are so far out of touch, they just can't understand.
Google pushing things like this and being surprised by the violent backlash has the same feel.
There's no backlash. Is there anyone stating to stop buying Google Ads? Moving to Firefox (since there's no else alternative non-Google-chromium-based browser out there)? Except the HN audience, if course.
There's no danger from "users" for Google. Because their users are huge enterprises paging billions for ads. Not us.
DRM is what banks love. Recently, there're several major banks' mobile apps in Singapore stopped working as they started scanning all apps installed on a device, and some they don't like (MS Authenticator, for instance; F-Droid, and any opensource apk from there, also any developers installed app). This is nightmare as mobile bank apps are a first class citizen now. Web just does not open without push dialog. Not sms otp anymore, but the app push dialog. The only way to handle it is to buy a cheapest android and install all bank apps there.
I've actually noticed and increased number of "this is it, I move to FF" posts, here and on Reddit. Since FF fixed their main performance problems, switching is not particularly burdensome anymore; and now the assumption that Google is "evil" has reached the same level of popularity that Microsoft used to have at the peak of their powers.
I think we're in a similar position as early-00s opensource: commercially fledgling, but establishing a solid mindstream in geek circles that will shape the future in unpredictable ways that are not favourable to Google.
> Recently, there're several major banks' mobile apps in Singapore stopped working as they started scanning all apps installed on a device, and some they don't like
This seriously triggers me. I can't even enable developer mode on my phone without these apps flipping out.
Banks in my country (Brazil) have a long standing tradition of doing this. Even on PCs they have these asinine "security plugins" for browsers. You literally cannot log into their systems without the goddamn thing installed. Not a single person managed to explain to me what they do, so years ago I was bored at work and tried my hand at reverse engineering the plugin to figure out why it made the computer so unusably slow.
I caught it intercepting every single network connection.
Didn't bother to check anything else. Just assumed it was phoning home with private information and started treating it like the malware it is from then on. Actually switched banks to one which didn't require this crap. These freaking banks think their "fraud prevention" justifies anything.
There's a package for this "banking security tool" in the Arch User Repository.
https://aur.archlinux.org/packages/warsaw
https://aur.archlinux.org/packages/warsaw-bin
Who the hell knows what this thing does nowadays? Maybe it doesn't monitor people anymore, it's been years and we even have a GDPR equivalent now. But I will never install it.
I take it this is not the case, and theyre still making you install malware?
Check this out. They even have a Linux support page, complete with screenshots depicting it running as root.
https://seg.bb.com.br/duvidas.html?question=10
https://seg.bb.com.br/img/faq/linux/verificar_modulo2.png
I looked it up the package I posted above and found a gist with the unpacked contents:
https://gist.github.com/fititnt/8d94b0574c6a4ec7e8c4088c6474...
Literally asks for your root password, downloads some proprietary software off the internet and runs them without even computing checksums or anything.
Corporation that made this thing is owned by Diebold, the corporation that made our voting machines. Bone chilling.
Right, let me just put my tin foil hat.
Why did they roll it back, then?
Why do they want to silence opposition? Because their position does not stand up to scrutiny.
We need a stronger response to their arrogance. Something that will affect network performance and intercept revenue. We can start by blocking them at the DNS level. Host with Google? Too bad your choice in tech sucks.
no, they don't. Google just criminally accused the opposition to their new "internet law" of being doing so in order to continue committing crimes.
The behavior from Google fits the same bill. The way they're doing it is just the difference between FOSS 'communities' and multi billion dollar corporations.
They likely have psychs on staff to manipulate the narrative around their totalitarian software and services.
That is not want was said. People making direct and indirect threats against the author are not acting in good faith and want to just silence the author without anyone fairly evaluating the proposal.
>Why do they want to silence opposition?
Threats are not productive for deciding if a proposal should be adopted. They are just noise. Wanting to get rid of noise and focus on signal is not "silencing opposition."
Indeed that would be the case if that were so, yet it looks like what actually occurred here is the author is abusing the labelling of bullying and criminal in order to falsely tar all disagreement as that.
This labelling abuse is itself a bullying act designed to intimidate and shame into silence any disagreement by misrepresenting it as a threat. Which is itself a threat: agree with me or I will accuse you of evil and silence you.
That's what it seemed like at the time. Let's note that the quoted comments are from a months' old thread.
Do you have any evidence to support your claim about there being direct and indirect threats?
Read the Github issue and you will see people irrationally freaking out about this, indirectly and directly threatening to sue the author, etc. The people disagreeing and bring up problems were much more civilized until it went vital and then it turned into a cess pool of unproductive discussion.
Yes, and that's the problem the GP is pointing out. We're a social species that's predisposed to defend a victim, that's why playing the victim is a very successful bullying tactic.
First thing they should stop taking for granted the right to make proposals. Which obviously leads to the fact that they should accept when their BS is rejected.
"We are introducing web DRM to protect users from those evil people out there..."
The hell you are.
While benefiting unethical businesses like Google? That's called a cartel.
I cannot imagine the level of cognitive dissonance required to simultaneously believe you are passionate about the open web, and push something like WEI.
Either they're flat out lying about their "passion", or they've internalized some very contradictory ideas. Not sure which is worse.
Of course then there's:
> Attacks and doxing make me personally MORE likely to support stronger safety features in chromium, as such acts increase my suspicion that there is significant intimidation from criminals who are afraid this feature will disrupt their illegal and/or unethical businesses, and I don't give in to criminals or bullies.
Which makes me think they're just lying. Or, at best, they don't understand basic logic. Personal attacks and doxing are unacceptable, but just because people who do bad things hold a certain opinion, it doesn't mean everyone who holds that opinion does bad things. Or even that more than a small, vocal minority do.
But ultimately Google is an advertising & surveillance capitalism company. If you're going to work there, and on one of most of their public-facing products, it's pretty likely you're going to eventually do shady things in service of the company's main revenue streams. Your continued employment depends on it.
> Either they're flat out lying about their "passion", or they've internalized some very contradictory ideas. Not sure which is worse.
After observing Google for many years, I've figured out that when Googlers say "the open web", what they mean is "running in a browser, not a native app". So anything that makes apps running in a web browser more competitive with native apps is "good for the open web", even if it reduces openness. I think for a lot of people this is not even bad faith; it's just how language is used inside Google, and people pick it up and it shapes their thinking.
Imagine a world where EME was not accepted as a standard.
1. Browsers do nothing to support DRM and sites like Netflix recommend people to just use a native app to experience the full Netflix experience. This weakens the open web by having sites leave the web and opt to move users to the mobile web instead.
2. Browsers adopt a closed standard for DRM. This weakens the open web because now a care use case of the web now uses a closed standard instead of an open one.
It would be easier if it was just Netflix using this crap like you imply. Nowadays, a good 10% of the websites have a popup "this page has DRM content, do you want to enable it?", I'm assuming it's used for advertising fingerprinting and malware even more than videos.
So yeah, requiring a netflix app is an improvement on the current situation.
> 2. Browsers adopt a closed standard for DRM. This weakens the open web because now a care use case of the web now uses a closed standard instead of an open one.
DRMs aren't the open web, they are the closed web, regardless if there's a specification or not, that doesn't change a thing.
And having an open specification for it lowers the cost of deploying them (as we've seen now, it's in a lot of places) which is bad.
If you are botherd by popups I'm sure you can disable them. I've never seen a popup asking me to enable DRM when I browse the web.
>DRMs aren't the open web
EME has a standardized javascript API for people to use. This is a public standard developed openly.
>And having an open specification for it lowers the cost of deploying them (as we've seen now, it's in a lot of places) which is bad.
Allowing copyright holders to have their hard work be protected is a good thing and allows for them to be willing to share them more if they can trust they won't be stolen from. Artists want control over how their art is used. Saying tough luck and that they should just deal with it being stolen is not productive and is ignoring their needs.
If only that had actually happened.
what does that even mean? we are talking about internet arguments here right? how does "safety" even enter the conversation? this guy sounds off his rocker.
> find ways to reduce the harms of invalid traffic across the whole web
crazy talk.
Curiously your HN profile says "removed due to doxing, because people are awful" so I'd like to think you at least would have the empathy to imagine someone experiencing something similar to what you experienced. Internet arguments can hurt people; period.
This is a complicated issue. I view work as a mutual exchange: I work on software in exchange for money. It is a bonus when I think the software or mission is genuinely cool. That said, I'm not one to be highly moralizing about it. I'd quit if someone asked me to do something illegal, and I will (and have) generally refuse to do work that is just simply morally bankrupt (And I have been tested on this. Early in my career, I refused to remove annual subscription renewal reminders for a subscription service. I didn't suggest that I would quit if it were done, but I voiced my disapproval and made it clear I wouldn't do it. We didn't wind up doing this, thankfully.) But, I will generally work on things that I don't agree with. I'm vocal about it, but work is work.
But y'know, people have livelihoods to maintain. It's easy to say this if you live alone, have plenty in the bank, a great safety net, and a great network. (Not that all of that applies to me, but for sake of argument.) Certainly the job market is also tighter and the future of software engineering as a career is uncertain in some regards. So outright refusing to do work could be a scary prospect. Even being vocal about it and rocking the boat may be scary.
But that said, this being the case does not make the answer any less certain. While harassment and toxicity that crosses certain lines is not something I think people should justify, I certainly understand the why: working on something like WEI triggers an immune response from the proponents of the open web. And while I'm sure many people would prefer to do things "right", I think that there is an overwhelming feeling that the open web is hostage to the big corporate interests, and that the open web proponents are strongly outnumbered and outgunned in the modern world. And Google never played fair anyway, so they probably don't feel especially enticed to either.
So I think it's natural. What's going to happen is that this will probably continue to escalate, and I can't really say I strongly blame anyone. Google is probably happy to push this responsibility onto employees knowing it could be very mentally taxing, employees with increasingly poor career prospects will not want to rock the boat, and disgruntled "internet activists" who feel pushed to their limits are unlikely to care tremendously about the emotional damage they cause (it's not like the Internet is really known for its kindness to begin with.)
I'm thinking it's gonna be a good time to pivot away from computer careers these next few years...
This was mostly a media/social media storm in a teacup. With bad press because its Google.
Chromium is huge because its open source, so the bar is higher than Macos, Safari & Windows.
But it didnt make this proposal much different/worse than any of the others that already exist and are enforced.
At least we got some hilarious statements like "its not needed because bots identify themselves by their user agent!"
But is PAT good? Well no. It's bad for similar but ultimately different reasons. But until Chrome adopts it, it's just not scary.
The health of the open web depends on not having different user agents being treated as second-class citizens. Not only that, but locking the internet behind CAPTCHAs and remote attestation to fight bots is bad because it will always be playing favorites to bots like Google's. Today, and in the past, we've already seen what it looks like when the Internet does this. But it's just not going to be an acceptable solution to bots. If the Internet of the future is a hellscape of big corps controlling literally everything that remains with cryptographically enforced adblock, Yes I'd happily see it burn down instead. I don't really care if other people would prefer that to nothing, because to me its a worthless future and a waste.
Attestation is not a real option that's really on the table.
If they don't want harassment or threats, they should maybe stop messing with people's stuff...
As a recap, websites never see any information about your device but basically receive a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with. There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS, where there are a relatively large number of trusted providers including some like LetsEncrypt that are non-profit and considered a public good. In that sense it would allow quite a bit of flexibility in what 'untampered' means based on the trust source which would be a good thing.
IMO the dialogue around this was incredibly disappointing. I understand and support the hesitation around a proposal like this that could do harm to the web, but people were basically attacking these people and having meltdowns in the GitHub comments.
Given how much large platforms have struggled to fight bots, and that it's only going to get worse with the rise of AI, I think something like this is going to end up being a necessity eventually. This won't be the last we will see of something like this.
Where "untampered with" means blocking anyone with an adblocker installed, using accessibility tools, or running Linux. DRM for the whole web is Bad.
This would effectively exclude FOSS as a second class citizen when accessing the modern web.
My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web. And, there's at least a possible outcome where we have many trusted providers that maintain the core parts of the open web that we love while giving these providers some better solution than what exists now.
As for why would they trust Brave? I imagine it'd be similar to TLS now, where website owners probably wouldn't even think about this and they'd just use CA chains provided by browsers, operating systems, etc.
> Given how much large platforms have struggled to fight bots, and that it's only going to get worse with the rise of AI, I think something like this is going to end up being a necessity eventually.
I want my browser experience to be focused on solving _my_ issues. Helping trillion dollar big tech companies fighting bots is honestly very low in my priority list of browser (anti)features.
You won't ever have that with browser builds because there's nothing like that to tie them to.. (user agent string?). There will be no basis upon which to build trust except for market share, and to gain market share you have to already be trusted.
Also, for WEI to work, you need to certify a lot more then just the build of the browser.... You need to certify all of the shared libraries it pulls in (including the userspace graphics libraries), everything that runs in kernel mode, the firmware, and the actual hardware.
I would assert that the idea you are proposing is simply not going to happen. There is just no way that anything other than an unmodified build of a big-name browser running on an OS from a big-name vendor gets certified.
Why do you want a one way street?
What is that important issue?
I'm much more worried about abusive service providers, which this will enable. A browser is a user agent. It ought to act on behalf of the user, not some random website I'm visiting.
There is no issue. In general the companies who encounter this "issue" the most are already making plenty of money. They have billions of dollars available to fight bots and they're free to use them if they think it's worth it. No one writes sophisticated bots for Mom&Pop websites, there's nothing to be gained from doing so.
The problem is that the APIs for botting are the same APIs that are used for browser automation and extension support and that are implemented by experimental browsers that are building new tools for the web.
You're correct to bring up that people didn't trust Google; that's part of it. But there's a more fundamental problem: there is no way to restrict someone from using APIs to automate a browser without also killing a lot of more traditionally accepted use-cases for those APIs.
Every accessibility API and presentation API is an adblocking API. Every web extension and request redirector is a bot API. Google didn't seem to understand this; they came into the discussion believing that as long as they could get people to believe Google wouldn't abuse the API, everything would be fine (whether or not that was an honest claim is another discussion, the problems with WEI were numerous). But beyond the discussions of Google's motivations, at a fundamental level what critics were saying was that there was no such thing as a working version of this API that would be effective at reducing bots without reducing user freedom. Making the API more Open or getting more implementers on board wouldn't change that.
It simply isn't possible to truthfully verify to a server that a user environment is "trusted" without blocking the user from accessing normal browser APIs.
If you are that naive look where Android is now today.
Despite being open source and having some alternative distributions, many banking and other "serious" institutions apps only work on official builds blessed by Google. They also block screenshots and remote screen.
All thanks to Android\Google Play Protect DRM.
If DRM is added to the web expect these same institutions to be early adopters so they can restrict access to their websites to only the browsers controlled by big tech and only without extensions.
Banks don't have to restrict their apps against unauthorized Android builds and rooted devices with Play Protect but they do. There is nothing to gracefully degrade when your goal is actually to just restrict access.
If we're willing to give that stuff up in order to bring native apps back to the web, then we can save a lot of time and effort and just redefine the web to include mobile apps and get Google to re-label all the native apps in the Play Store as webapps and change nothing else. Then those apps will technically be on the web! No developer changes even needed, the web won! /s
The problem is not that the banks aren't on the web. The problem is that the banks deny user-agency. That's the problem I want to fix by bringing apps to the web. My goal is not to get the bank app served over an HTTP request, I don't care about that part. I don't care if the bank's interface was written in Java or Javascript. I don't care if the bank is caching data in service workers or on disk.
My goal is to get the bank app to respect user-agency, that's the part I care about.
If we make the web into a native environment, then it doesn't matter anymore whether or not app developers are using it. The web forcing developers to support user freedoms is the primary reason we want webapps. The web is a means to an end, not an end in and of itself.
Unless you're calling extra low resolution graceful? I wouldn't when there's no reason for it. And things that use the Google DRM on phones usually just shut off.
So what is this DRM actually accomplishing? Well, it makes it so that on platforms that don't support the DRM, piracy is actually a better user experience. All it did was create an additional(if minor) incentive for Linux users to just download the stuff for free instead of paying for Netflix.
Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent. I am the user and the owner of the machine, I am entitled to "tamper" with anything I want.
Says who? The government? At the end of the day, any voluntary interaction between two entities is a two way street. Either side can refuse to engage with the other side for any reason.
The proposal didn't include anything like that and I don't see how it possibly could while still meeting its goals... It seems to me that WEI's goals are fundamentally incompatible with letting end users compile their own software.