Less (LLM-generated) spam.
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.
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.