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?
Tracking me harder isn't going to make those sites go away.
I still think the approach is harmful overall.
The idea that I must be "vouched for" by a "trusted third party" by providing extensive details about my system, in order for my browser to send a HTTP request is in direct opposition to privacy and my interests.
That it's being proposed by a company that owes it's entire existence to web crawling is ironic.
It turns the web from an open platform into one where the big players have complete control over which devices and software are permitted.
----
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.
I'm trying to figure out how to balance assuming the best and treating every comment as if it's an individual argument, while also not being completely naive to the fact that a nontrivial number of the people making these arguments are very often blatantly pro-DRM and are asking me to just pretend that they're not. It's definitely not everyone, but...
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...
I feel like you're potentially overcomplicating that? What I'm getting at is that:
A) You can basically build the equivalent of a bash curl script pretty easily if individual browsers aren't blocked (which Google says it doesn't want to do, but... that's my point, they will). Guaranteeing OS integrity doesn't matter unless you go on to restrict which browsers can run and weed out the efficient headless browsers. If any headless browser gets attestation support (and I've had proponents try to tell me that headless browsers will be supported) then that's likely game over for attestation as a bot detector.
B) You can build mostly the equivalent of a bash curl script inside of a webextension (or honestly, not even, you can make requests in a loop automated within your browser's dev-tools). You don't need to leave the monitor or anything hooked up and you don't need to do anything particularly fancy and you don't need to emulate user input or build a complicated farm. Your web browser is a terminal with all of the capabilities of Bash and more.
My instinct is that any website that was vulnerable to a quick and easy bash script before is going to be just as vulnerable to a `for` loop run inside the browser dev tools.
----
It's tricky to talk about because the actual answer is what you say: ("absolutely, it very literally tries to guarantee integrity") -- that attestation will involve significantly more restrictions than proponents are pretending it will impose. But if I take the proponents at face value, and if I believe that this is about guaranteeing OS integrity and blocking root and it's not going to block headless browsers or extensions -- in that world I don't think this necessitates setting up a bunch of device farms? I think it just means you run Headless Chromium or Firefox, maybe with a remote debugger if you want to be fancy, and then you have it spam requests. Bear in mind that this will be on desktop as well; it's not only phones that would be sending attestation signals. Desktop Chromium and Firefox are incredibly easy to script.
Maybe it makes that slightly more expensive since you have to actually run a browser, but I don't think you need a rack of phones and I'm not sure that the compute cost of running a browser can be considered prohibitive? Maybe I'm underestimating the margin that bot farms operate at and forcing them to run a browser would be enough to drive some out of business. But I kind of suspect you just use one of the desktop browsers that has attestation and write your "bash" script equivalent inside of that browser and everything works mostly the same.
Am I missing something? It doesn't seem like that big of a deal whether or not you can use curl.
And the only real way to get around that is for some websites to turn off the ability to have the browser arbitrarily execute code with full access to browser/page APIs whenever the user hits F12.
What is does do, is afford the major players total control over which devices and individuals are allowed to access the web.