I have a weak grasp of this, but a developer working on this responded to some criticism.
If the developers working to implement this are to be believed, they are intentionally setting it up so that websites would have an incentive to still allow untrusted (for lack of a better term) clients to access their sites. They do this by intentionally ignoring any trust check request 5% - 10% of the time, to behave as if the client is untrusted, even when it is. This means that if a website decides to only allow trusted clients, they will also be refusing trusted clients 5% - 10% of the time.
The relevant part of the response is quoted here:
WEI prevents ecosystem lock-in through hold-backs
We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported.
This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior.
Additionally, and this could be clarified in the explainer more, WEI is an opportunity for developers to use hardware-backed attestation as alternatives to captchas and other privacy-invasive integrity checks.
I mean, the same thing that is happening right now, right? The point would be that websites would not be built to only allow trusted clients-- it would still have to allow all clients. If they wanted to remove this 10% thing, it’s not like the entire web would instantly stop being built to allow untrusted clients.
I’m not sure this is true (keep in mind: weak grasp). This 10% would push websites from specifically blocking untrusted clients-- but if they got rid of the 5%, it would not magically change all the websites to block untrusted clients. They’d still need to update to do this.
I don’t want to come off like I’m defending this though-- I really just don’t know enough to say.
That sounds nice but there’s no guarantee they’ll implement it, or if they do, that they won’t just remove it someday down the road. This could just be a way for them to avoid criticism for now, and when criticism has died down a bit, they can just remove it.
Thats such a weird clause to include and is likely just a honeypot. Why even bother allowing unverified browsers to connect, since it invalidates the entire purpose of the trust system? If any bad actor can simply choose to not use the trust system while still having full access, then the system is less than useless for its stated purpose (catch bots/bad faith traffic, ensure no malware) and serves only to decrease the speed and experience of legitimate users.
That opt-out clause won’t last a year once it’s mandatory in Chromium.
An attestation method that randomly fails in 5-10% of cases makes no sense. It’s not attestation anymore, it’s a game of dice. This is blatant rhetoric in response to the DRM criticism. Nobody sane would ever use such a method.
I confess I don’t really understand how it is supposed to work if it’s designed to randomly not work haha. I really hope I’ve made it clear that I lack knowledge in this.
The purpose is to make it so websites don’t require a trusted client. If they took that away after the fact, the websites wouldn’t magically switch to requiring trusted clients, wouldn’t they? It would still need to be updated for this. So we’d be pretty much where we are now, with a software change and public outcry about it.
I have a weak grasp of this, but a developer working on this responded to some criticism.
If the developers working to implement this are to be believed, they are intentionally setting it up so that websites would have an incentive to still allow untrusted (for lack of a better term) clients to access their sites. They do this by intentionally ignoring any trust check request 5% - 10% of the time, to behave as if the client is untrusted, even when it is. This means that if a website decides to only allow trusted clients, they will also be refusing trusted clients 5% - 10% of the time.
The relevant part of the response is quoted here:
And what happens when they decide to revoke that 5-10% after they got everyone onboard?
I mean, the same thing that is happening right now, right? The point would be that websites would not be built to only allow trusted clients-- it would still have to allow all clients. If they wanted to remove this 10% thing, it’s not like the entire web would instantly stop being built to allow untrusted clients.
the 10% sounds like bait. Once they’ve got everyone on board and things are running smoothly (for them), it will be muuuch harder to resist.
I’m not sure this is true (keep in mind: weak grasp). This 10% would push websites from specifically blocking untrusted clients-- but if they got rid of the 5%, it would not magically change all the websites to block untrusted clients. They’d still need to update to do this.
I don’t want to come off like I’m defending this though-- I really just don’t know enough to say.
The vast majority of them would not change the default, and a simple mandatory update would change that to 0% without them having to do anything.
Do you think Google will implement this in the end?
As soon as they are in a position to do it
That sounds nice but there’s no guarantee they’ll implement it, or if they do, that they won’t just remove it someday down the road. This could just be a way for them to avoid criticism for now, and when criticism has died down a bit, they can just remove it.
This is a very plausible concern, true.
Tho hopefully Google is force to stop this seeing how much backlash there is.
Thats such a weird clause to include and is likely just a honeypot. Why even bother allowing unverified browsers to connect, since it invalidates the entire purpose of the trust system? If any bad actor can simply choose to not use the trust system while still having full access, then the system is less than useless for its stated purpose (catch bots/bad faith traffic, ensure no malware) and serves only to decrease the speed and experience of legitimate users.
That opt-out clause won’t last a year once it’s mandatory in Chromium.
The developers working on this should not be believed and anyone who sees their resume for the rest of time should put it directly in the trash.
An attestation method that randomly fails in 5-10% of cases makes no sense. It’s not attestation anymore, it’s a game of dice. This is blatant rhetoric in response to the DRM criticism. Nobody sane would ever use such a method.
I confess I don’t really understand how it is supposed to work if it’s designed to randomly not work haha. I really hope I’ve made it clear that I lack knowledge in this.
If this is the case then what’s actually the point of it?
Yeah but that can be removed at any time. It’s a bit optimistic to think those safeguards would remain when they stand in the way of profit…
The purpose is to make it so websites don’t require a trusted client. If they took that away after the fact, the websites wouldn’t magically switch to requiring trusted clients, wouldn’t they? It would still need to be updated for this. So we’d be pretty much where we are now, with a software change and public outcry about it.