Respectfully, that response is kind of a roller-coaster. It's hard to know where to even begin.
> device controlled [...] unmodifiable [...] nonaproved hardware
Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing. Conflating device control to browser restrictions is also nonsensical given that the whole point of the web is that sites are browser neutral, and (again with exception of user-hostile features like DRM) browser forks are largely undetectable. Building a website that reliably blocks Linux is hard, borderline impossible. Even blocking scrapers is a losing battle, with a bit of work Headless Chromium is virtually undetectable (which of course it is, because if it was easy to detect headless browsers nobody would be arguing that "trusted" environments were necessary to stop scrapers and headless access). The user agent string is user controlled and I can easily set it to anything I'd like. A user agent string is not even remotely comparable to attestation. The web is not the way that HTML renders, the web is the platform, not just HTML.
> Sites can already detect adblocking without attestation. There is no evidence that the precense of an adblocker will be a signal to whether an environment is trustworthy. That is not the purpose of the API.
Sites can't reliably detect adblocking without lots of work, there's not an easy API for that. And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking, look at native apps on mobile platforms that support attestation. Native apps like Netflix already refuse to run on rooted devices. Their reason for that is to lock down possible circumvention of the client or redirection of the video stream. It's a content decision made to block users from altering the client/content (ie, exactly what adblockers do).
Attestation for native applications has never been a rare thing that only banks used. And also, heck banks, banks don't need attestation. I should be able to load my banking app on a rooted Android device. Banks are not an excuse to take away that ability away from me.
What the "purpose" of the API is doesn't really matter. How it will be used matters. Device attestation is regularly abused on Android devices, there is no evidence that this will be different. But like I said, maybe the people proposing it don't have bad intentions, maybe they're just naive. Either way the outcome is going to be the same.
> No, it won't. You just have to use a different API.
uBlock Origin already objectively runs worse on Chrome than Firefox. Gorhill has stated numerous times that Manifest V3 will make this worse. Also I'm familiar with Manifest V3's API differences between Firefox/Chrome's implementation, and I agree with him, Chrome's Manifest V3 API is worse for adblockers.
This is denialism, Manifest V3 makes adblockers less effective.
> Look at the reponse to FLOC. Despite increasing user's privacy many people forgot upset because they greedily want the web to cater to only them and not to people who rely on advertising
And there it is, makes me feel like clarifying the above points was a waste of time. Objection to this is greedy because we've forgotten about the people who rely on advertising.
I mean, come on. You can't even consistently keep up the charade of arguing that this isn't about adblockers for two comments before accidentally slipping into arguments that the advertisers are the real victims. When you write that sentence, you have to on some level realize that it's not going to make people trust the proposal more.
> Similarly with Web DRM people panicked because they didn't want DRM because they only care about themselves and do not care about people who want their content to be protected.
This sentence is also just a great way to convince people you're sincere when you argue that a proposal isn't meant to lock down devices or introduce HTML-level DRM -- no notes. ;)
----
I will give you this: If for some inexplicable reason you've come out of Web DRM, and Manifest V3, and FLOC, and Topics, and Web Audio changes, and a lack of mobile extension support, and AMP, and First-Party Sets, and the Conversion Measurement API, and on and on -- and somehow you believe those proposals were all good and worked out great and nobody had anything to complain about, then I buy that you would probably also look at this proposal and wonder why people were getting worked up.
The issue is that I have no idea how on earth anyone paying attention to the direction of the web could come to the conclusion that those proposals didn't have problems. But if somehow you've magically been able to do that, then I understand why the pushback to this proposal probably seems weird to you.