After reading through the proposal, I really don't think it was that bad.
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.
That is definitely a possible outcome which is why I believe people are right to be concerned about a proposal like this, however my thought was that if there were many trusted providers it would drastically reduce the likelihood of a scenario like this. For example, I could imagine an organisation like Brave as a trusted provider who would almost certainly not restrict ad blockers or Linux use.
Notice Windows 11's TPM requirement and the growing infestation of Android apps with Google Play Integrity? Brave would be a signed web browser, running on a signed OS stack, launched from a signed bootloader, all with hardware attestation. This is the end goal, since any part of that chain becoming compromised means any application running within that environment can be compromised be it Chrome, Brave, Firefox or whatever.
This would effectively exclude FOSS as a second class citizen when accessing the modern web.
I'm not denying there are challenges and potential bad outcomes with this, you're asking valid questions that I don't claim to have a good answer for.
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.
> My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web.
> 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.
The security model of TLS is chained to the DNS. What one proves by holding a TLS cert is that one owns a given domain, no more no less (I mean there's EV certs but no one cares about EV certs).
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.
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.
> My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web.
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.
> 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.
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.
> 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
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.
The only DRM currently available on the web that I'm aware of relates to video.
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.
Also the banks already just plain restrict access on the web, unconditionally, by making a smartphone app a mandatory auth / confirmation factor. And the app itself, of course, makes full use of Google's attestation APIs like you describe.
So at this point allowing for the web to be nearly as secure as a native app would allow for these sites to potentially start working on the web again.
I've commented to this point in the past, but I don't care about the web winning, I care about the things that make the web the web -- user-controlled agents, being platform-agnostic, extensibility, etc...
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.
Yes, I am talking about low resolutions that they understand will be easily stolen. Websites aren't mobile apps and the intention was that this API was not to be used for blocking.
The 4K DRM'd stuff is also easily "stolen". It's not as if it's actually working. It only takes one mildly sophisticated actor to get around it, share the resulting files and then your fancy DRM is completely useless.
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.
> a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with
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.
>Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent.
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.
...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
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.
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.