If we shoot this down and every bank requires me to download a mobile app, then fine. What this is proposing is basically to turn websites into mobile apps: device controlled, unmodifiable, broken on any non-approved hardware. If that's going to be the case regardless, I'd rather just download the app, at least that would be more honest about what's actually going on, and at least I'd still be able to use my adblocker when I browse the web.
The web is an app platform which competes against other app platforms.
>device controlled, unmodifiable, broken on any non-approved hardware
That's already true of the web without this API. It doesn't change anything in regards to that.
>at least I'd still be able to use my adblocker when I browse the web
Please read the proposal. It has nothing to do with preventing adblocking or detecting people with adblockers.
I fully disagree, I don't see how anyone could credibly make this claim. The web is open and customizable and neutral in a way that native platforms are not. Part of that is full device and OS neutrality where customizations and forks of browser engines do not generally[0] signal untrustworthiness to website operators. And true neutrality for the OS and hardware and browser is incompatible with this kind of full-stack attestation.
[0]: with the exception of a few minor features like web video DRM, which... surprise. It's almost like DRM is bad for the web, and it's almost like all of the licensing and access guarantees given by Google and Microsoft were nonsense and didn't prevent web video DRM from being a giant problem.
----
> Please read the proposal. It has nothing to do with preventing adblocking or detecting people with adblockers.
I have read the proposal all the way through, and I fully disagree, regardless of the "we don't want to restrict things" asides the authors have added. It is impossible to give website operators tools that can prevent automated actions in a browser that can not also be used to prevent accessibility APIs. There is no way to guarantee to a website operator that they are in a "trusted" environment where their code is not being manipulated while still allowing an extension to manipulate that code. And adblockers are only one category of extension that would be hampered by those restrictions, but they would be hampered.
There is a zero percent chance that detecting bot traffic for advertisers will not turn into adblocking/automation restrictions over time, and for Google employees to say that this will not happen means nothing given Google's history around adblockers. We are far, far past the point where Google deserves the benefit of the doubt on this. Chromium devs have been spending that goodwill for years, and they've run out.
Chromium is already less effective at adblocking than Firefox is today, and Manifest V3 is still set to make adblocking worse -- despite employee claims that these efforts were not intended to harm adblockers. Surprise, adblockers still got harmed. And this is a trend; at this point it is not goodwill or good faith to assume that Chrome proposals are neutral towards adblocking, it is burying one's head in the sand.
This proposal has a clear end point and the most charitable thing I can say about the people behind it is that maybe they're not malicious, maybe they're just hopelessly naive. Maybe they're not trying to harm the web, maybe they've just never actually thought about the industry they're in or what the motivations are of the companies in that industry.
----
I'll add to this that "people just don't understand, please read the proposal" is not a new response to Google controversies. It gets pulled out literally every time that Google makes a controversial decision: FLOC, web audio, Manifest V3, Web DRM, the list goes on and on. It is deflection; a suggestion that people pointing out criticisms must just not be informed because otherwise they wouldn't have those criticisms. It's not that Google ever does anything bad, it's just bad at communicating or people are jumping to conclusions.
We're not jumping to conclusions, the first thing I did when learning about this was read through the entire proposal. We understand the proposal, the proposal is just bad.
>device controlled
A website is limited in what it can do by the browser it runs in.
>unmodifiable
Since responses are generated server side you can not modify what they send you.
>broken on nonaproved hardware
There are existing sites which don't support Linux or don't support mobile devices.
>true neutrality of OS and hardware is incompatible with attestation
Attestation doesn't mean that HTML now renders differently. The User Agent string already allows servers to block OSs.
>There is a zero percent chance that detecting bot traffic for advertisers will not turn into adblocking/automation restrictions over time
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.
>given Google's history around adblockers
They have worked to support ad blocker extentions and they have provided a platform to ad blocker extentions. They have banned a malicous adblocker which also committed clickfraud. They have had some anti adblock experiments on YouTube such as limiting the resolution.
>We are far, far past the point where Google deserves the benefit of the doubt on this
I disagree.
>Chromium is already less effective at adblocking than Firefox is today
It works fine for me.
>Manifest V3 is still set to make adblocking worse
No, it won't. You just have to use a different API.
>despite employee claims that these efforts were not intended to harm adblockers
They care about improving the experience of the entire chrome user base. Getting rid of poorly designed APIs is a part of making Chrome better for everyone.
>We're not jumping to conclusions
Yes. You are. Google is trying to make the web more private and secure from the current state the web is in. 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. 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. There is a theme where people get outraged because they don't understand that there are more people who use the web and have different needs than just them.
Giving people the option to protect their content or the option to use attestation as a signal doesn't prevent some idealized open web from existing. Sites that would like extra security can opt into it.
> 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.
You did it first. Attestation has nothing to do with extentions.
>Building a website that reliably blocks Linux is hard, borderline impossible
With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.
>And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking
Please share it.
>It's a content decision made to block users from altering the client/content (ie, exactly what adblockers do).
The difference is that web browsers allow extentions, but the Netflix app doesn't.
>uBlock Origin already objectively runs worse on Chrome than Firefox
I use it just fine on Chrome and do not see any ads.
>Chrome's Manifest V3 API is worse for adblockers.
It has the same API for blocking ads. The API for blocking network requests is what changed.
>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.
FLOC is about trying to get advertisers to stop invading people's privacy. You shouldn't be surprised that advertisers are a stakeholder when talking about FLOC. Advertisers are as important stakeholder in the web in general. In regards to attestation there are more stakeholders than just users and advertisers since security is important to almost any type of service on the internet.
>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
The direction is not going away from web extentions and I don't see anything going after adblock extentions.
First of all, extensions are not serverside code, so... no, that doesn't make any sense. Second of all, attestation has a lot to do with extensions because extensions are based on browser functionality, and attestation impacts which software you can run. In this case, attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs.
And attestation has even more to do with extensions when extended to websites than it normally would because if the point of this is to established "trusted" environments, then arbitrary extension access to a web page means the environment is not trusted. If you allow arbitrary extension access, you can't provide guarantees about whether someone is human or not -- extension APIs allow for automation and scraping and ad fraud. And blocking that behavior is explicitly one of the use-cases listed in this proposal for the integrity API.
If this doesn't block extensions, then it's not a useful proposal for blocking bots. Quite literally every single use-case that this proposal lists are impossible if extensions are not restricted. Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions. A "trusted environment" the way the proposal describes it can not have arbitrary extension access because extensions can do all of that stuff; from posting automated content to fraudulently clicking on ads to cheating at online games to stealing your bank password.
> With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.
Do you genuinely think that an Open Linux environment is going to support attestation? We're having a hard enough time getting Passkey to support Linux, there is zero chance that Arch Linux becomes a trusted attestation provider for the Web Environment Integrity API.
And if it did, this whole proposal would be useless, because I'd be able to use Headless Chromium on Arch Linux and just have Arch Linux say that my computing environment was secure. There is no definition of "trusted computing environment" for a website provider that doesn't involve blocking access to arbitrary user-controlled code execution at the OS and browser level.
Because if you couldn't block that access, you wouldn't have any security guarantees. The entire premise falls apart if fully user-controlled environments are supported. It would be a useless proposal.
> And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking > Please share it.
https://developer.android.com/google/play/integrity -- please do any amount of research into how this has played out.
> uBlock Origin already objectively runs worse on Chrome than Firefox > I use it just fine on Chrome and do not see any ads.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... -- this is also not very difficult to look up, I kind of feel like you should have been able to find this link yourself.
> FLOC is [another long explanation of why advertisers are the victim and FLOC is actually making the web more private]
I have to say again, I don't know if you expect this to sway anyone reading these comments, but it's not going to. No one is going to read that paragraph and think, "you know what, this person probably does care about adblockers and probably is really committed to making sure they're not harmed."
It does not tell you what browser the user is using. Websites can not block a specific browser.
>Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions
How does this affect browser modifications and extensions?
Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it does not restrict the indicated application’s functionality: E.g. if the browser allows extensions, the user may use extensions; if a browser is modified, the modified browser can still request Web Environment Integrity attestation.
>Do you genuinely think that an Open Linux environment is going to support attestation?
When Linux distributions start to actually care about security yes I do see plenty.
>Play Integrity
Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.
>this is also not very difficult to look up
Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
>another long explanation of why advertisers are the victim and FLOC is actually making the web more private
Advertisers aren't the victim in this situation. It's the users who are losing privacy due to cross site tracking.