Assistive technologies will still work as the browsers implement platform's assistive APIs.
Automatic testing will still work because a developer isn't going to add restrictions to their own tests from their site. Unless they are testing if a captcha gets shown from an unsafe environment.
Archives, search engines, and spiders should already be respecting robots.txt. Site owners can already block those things if they don't want their site crawled.
>This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web.
The proposal allows anyone to become an attestor. There would not be a single attestor who you would have to prove your trustworthiness to.
Either this protocol is useless for its intended purpose, or banks will only accept a small handful of attestors that promise not to sign for environments where the owner has control. Being able to create a new attestor means nothing because attestation is not valuable without pre-established trust.
The fraud prevention use case requires that the browser matches what Google or Mozilla shipped, not what I choose to actually run. From 10,000 feet in the sky, there's zero difference between, say, someone who installed modified software on their phone to protect their privacy and someone who was tricked into installing malware[0]. Banks don't care about your freedom, they care about making your fraud someone else's fault.
Some of the use cases explicitly call for locking the owner out of their device too. Anticheat in games is treated as at least beneficial to honest users, but it can still be user hostile[1]. Click fraud detection shouldn't even be something that a USER agent cares about - and it's not like Google cares about that anyway[2].
Practically speaking the only Linux distros that will get an attestor that anyone will actually care about will be Chrome OS and Play-certified Android. At best, Google agrees to attest for Chrome and Firefox on non-Chrome-OS Linux and it winds up being like EME did. At worst everyone has to buy a Windows license just to use most websites anymore.
>Assistive technologies will still work as the browsers implement platform's assistive APIs.
At least until someone says "we need to keep content from being data mined for AI training[3]" and AI scrapers find out how to automate those APIs. The underlying power dynamic of attestation means that websites can just demand attestors ban screen readers, in the same way that ebook DRM already does.
[0] Casual reminder that Louis Rossman was harassed by the GrapheneOS developer for agreeing with someone that the developer asserted had harassed them. He uninstalled GrapheneOS specifically to avoid being pwned by its developer.
[1] Let me remind you of the insane cat-and-mouse game where cheaters went into the kernel, so now anticheat is in the kernel, and now cheaters find vulns in the anticheat to hide their cheats in, which now malware can use as well.
[2] https://www.theregister.com/2023/06/29/google_trueview_skept...
[3] Reddit
It means that each site can choose who they trust instead of their being a single entity dictating what users are secure or not.
>Click fraud detection shouldn't even be something that a USER agent cares about
But it is something that the web standard should think about in order to make the web a better place.
>Practically speaking the only Linux distros that will get an attestor that anyone will actually care about will be Chrome OS and Play-certified Android.
I disagree. There are several Linux distros that support secureboot showing that Linux distros are capable of showing they are trustworthy enough to Microsoft.
In what way does it make the web a better place?
----
It's worth considering that the examples that come up over and over again when people try to defend this proposal are a strong reason to believe that Google is lying or being naive when it says that the proposal won't eventually impact extensions or the ability to inspect 3rd-party code.
Because OS-level restrictions that ignore extensions and runtime modifications to websites and scriptable browsers won't help with any of these problems. And if advocates are willing to so quickly say today, "there's LLM spam, so sure, lock down the OS", they are also going to say in the future, "there's still LLM spam, the problem is worse than ever, lock down the extensions."
If you believe that blocking bots justifies attacking user agency, there's no reason to stop at blocking users from rooting their phones. The actual impactful attacks on user agency for blocking bots would be to block website inspection and website modification.
Sure, the analog loophole (or analog input loophole) will remain. But it's times more difficult than what is possible at this point in time.
> And if advocates are willing to so quickly say today, "there's LLM spam, so sure, lock down the OS", they are also going to say in the future, "there's still LLM spam, the problem is worse than ever, lock down the extensions."
There's always going to be spam, just like there's always going to be ways around DRM. The difficulty changes over time. Up to the person to decide if it's good or bad.
> If you believe that blocking bots justifies attacking user agency, there's no reason to stop at blocking users from rooting their phones.
Noone has stopped there, SafetyNet already does that.
I disagree, I don't think whether or not you can root your phone has any real impact on how hard it is to automate a request. I don't think this is the same as the analog loophole, I think it's going after a different area entirely from where most attacks are coming from.
> Noone has stopped there, SafetyNet already does that.
What I mean is that SafetyNet blocks custom ROMs, rooting, etc... and I'm seeing comments saying that's all that the spec is interested in, it's not going to target extensions or code inspection. I don't think there's any reason to be confident of that, I think it's very likely that this spec evolves to target browser extensions. Because I don't think blocking people from rooting their phones will make an observable difference in the amount of LLM spam that websites get.
I find device farms way harder to pull off than a bash curl script, to be honest.
> I think it's very likely that this spec evolves to target browser extensions.
Absolutely, it very literally tries to guarantee integrity.
> Because I don't think blocking people from rooting their phones will make an observable difference in the amount of LLM spam that websites get.
I do think it would reduce the amount of abuse that's not very sophisticated. If that's worth the rest...