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.
This is unbelievably silly. It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
> It's about reducing the rate of those things.
Again, this is incredibly silly. There is zero evidence this will reduce the rate of those things. Extensions are very likely the most common vector for this.
And if you genuinely can't see a clear path in this proposal where website operators will say, "we can block Headless Chromium, but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too" -- then, I don't know, it must be nice to be able to somehow trust corporations that much despite the entire history of how advertisers and corporations have interacted with the web standards process.
Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom. That is still blocking me from using a specific browser. And if your argument is that scriptable browsers aren't going to be blocked, then this entire proposal is a waste of time. This proposal will affect extensions for obvious reasons, but even if it didn't it would still be a problem.
> When Linux distributions start to actually care about security yes I do see plenty.
:) Come on. Linux security is not the reason it would be blocked in these situations, user agency to run headless browsers like Headless Chromium is the reason it would be blocked.
You're trying to shift this conversation to be about security, but security is only one of four use-cases proposed, and three of them are about preventing the user from doing actions that the website owner considers harmful. This is not primarily a security proposal, it is a proposal about blocking off user capabilities that website authors would rather the user not have.
That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Of course, it does not escape my notice that you haven't provided an argument for why Linux won't be blocked, you've provided an excuse for why Linux should be blocked. What you're telling me is "yes, your device won't support attestation and you won't be able to use your bank website on that device, but that's Linux's fault. And maybe eventually Linux will support attestation in the future."
Okay, it's nice to know I'll only be locked out using the OS I prefer for an ambiguous amount of time until it caves and meets an unspecified standard of security at some unspecified point in the future. But I'm still going to be blocked from Linux. And you've moved from "this doesn't block an OS" to "it does block an OS and that's actually a good thing to do."
> 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.
Luckily the former is the part I care about and is the primary part that is abused. Rooting an Android device is the part we're talking about and the part this has implications for. You started out this conversation by asking me to read the proposal. Let me extend the same request to you: please do some research on this.
Also, please don't make claims that aren't substantiated about how attestation will work. This proposal does not specify that attestation on Android wouldn't use the Play Integrity API. It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
Nothing in this proposal preempts them from doing that, there is no reason to trust you when you say that sideloaded apps will be able to pass attestation. The proposal specifically does not lay out what attestation requirements will be.
> Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
"Chrome works on CNAME stuff": where? The API isn't supported, what are you talking about :)
And if a nearly 20% reduction in adblocking capability doesn't matter to you, great! But don't pretend that it doesn't exist. Chrome objectively has a worse adblocking experience than Firefox. Manifest V3 will make that experience worse.
Maybe you don't care about that, which is fine for you, but "this won't affect adblocking" and "meh, what adblocking you'll have will be good enough, stop caring so much about adblocking" are very different arguments.
> It's the users who are losing privacy due to cross site tracking.
FLOC would not have stopped cross site tracking or improved user privacy. None of the proposals Google made about restricting cross site tracking needed FLOC (Firefox and Safari were able to block cross site cookies just fine without FLOC).
In addition, it's not really even accurate to say that Google is clamping down on cross site tracking; in fact First Party Sets exposes mechanisms to treat cross site cookies as if they are first party.
Chrome was last to the table on blocking common cross site tracking techniques, specifically because they refused to implement industry wide defenses until they had another user targeting solution implemented. Chrome very literally delayed user privacy improvements until they could make sure that advertisers were taken care of. They were the last browser to add those improvements because they were worried about advertisers more than users. And they immediately proposed specification changes that weakened the user protections that other browsers had already launched.
But, it's true. Since LineageOS doesn't break Android's security model they could work with phone manufacters / Google to allow LineageOS to be trusted. Then apps would not be able to tell via play integrity that it could be lineageos since it looks like any other trusted device.
>There is zero evidence this will reduce the rate of those things.
I think this is fair criticism of the proposal. If it's not effective in practice then sites won't invest time in using it since it's a pointless API.
>Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom.
This API is not about blocking headless chromium.
>but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too
Protecting against that is unrelated to this proposal.
>:) Come on. Linux security is not the reason it would be blocked in these situations
Considering most Linux users are 1 curl | bash away from installing malware that can easily pivot to root and install a kernel module to hide itself. It's related.
>and three of them are about preventing the user from doing actions that the website owner considers harmful.
Can you quote that section. I don't see it.
>it is a proposal about blocking off user capabilities that website authors would rather the user not have.
Except this proposal doesn't block any user capabilities. It simply adds a way for sites to check if the user has a secure environment.
>That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Arch could simply have in their settings app a toggle that allows you to disable trusted mode to allow you to install kernels or whatever you built yourself. Similar to how motherboards let you disable secure boot.
>it does not escape my notice that you haven't provided an argument for why Linux won't be blocked
Firstly, this proposal isn't about blocking people. Secondly, their will be many Android bsed Linux distros that will be considered secure. For the Debians and Archs of the world they will need to work with others and prove they can provide a trusted environment. I believe this is possible and I think something similar happened in relation to secureboot.
>"it does block an OS and that's actually a good thing to do."
I never said that it was a good thing to do.
>Rooting an Android device is the part we're talking about and the part this has implications for.
Rooting breaks the android security model and provides by definition an untrusted environment. Android apps may not want to deal with supporting devices that don't support the security features an Android operating system is supposed to provide.
>It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
The Play Integrity API works with apps not from the store.
> danShumway 26 minutes ago | parent | context | flag | on: Web Environment Integrity API Proposal
> It does not tell you what browser the user is using. Websites can not block a specific browser.
This is unbelievably silly. It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
> It's about reducing the rate of those things.
Again, this is incredibly silly. There is zero evidence this will reduce the rate of those things. Extensions are very likely the most common vector for this.
And if you genuinely can't see a clear path in this proposal where website operators will say, "we can block Headless Chromium, but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too" -- then, I don't know, it must be nice to be able to somehow trust corporations that much despite the entire history of how advertisers and corporations have interacted with the web standards process.
Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom. That is still blocking me from using a specific browser. And if your argument is that scriptable browsers aren't going to be blocked, then this entire proposal is a waste of time.
This proposal will affect extensions for obvious reasons, but even if it didn't it would still be a problem.
> When Linux distributions start to actually care about security yes I do see plenty.
:) Come on. Linux security is not the reason it would be blocked in these situations, user agency to run headless browsers like Headless Chromium is the reason it would be blocked.
You're trying to shift this conversation to be about security, but security is only one of four use-cases proposed, and three of them are about preventing the user from doing actions that the website owner considers harmful. This is not primarily a security proposal, it is a proposal about blocking off user capabilities that website authors would rather the user not have.
That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Of course, it does not escape my notice that you haven't provided an argument for why Linux won't be blocked, you've provided an excuse for why Linux should be blocked. What you're telling me is "yes, your device won't support attestation and you won't be able to use your bank website on that device, but that's Linux's fault. And maybe eventually Linux will support attestation in the future."
Okay, it's nice to know I'll only be locked out using the OS I prefer for an ambiguous amount of time until it caves and meets an unspecified standard of security at some unspecified point in the future. But I'm still going to be blocked from Linux. And you've moved from "this doesn't block an OS" to "it does block an OS and that's actually a good thing to do."
> 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.
Luckily the former is the part I care about and is the primary part that is abused. Rooting an Android device is the part we're talking about and the part this has implications for. You started out this conversation by asking me to read the proposal. Let me extend the same request to you: please do some research on this.
Also, please don't make claims that aren't substantiated about how attestation will work. This proposal does not specify that attestation on Android wouldn't use the Play Integrity API. It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
Nothing in this proposal preempts them from doing that, there is no reason to trust you when you say that sideloaded apps will be able to pass attestation. The proposal specifically does not lay out what attestation requirements will be.
> Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
"Chrome works on CNAME stuff": where?
https://bugs.chromium.org/p/chromium/issues/detail?id=118065...
Chrome now handles CNAME aliases internally: https://bugs.chromium.org/p/chromium/issues/detail?id=1151047.
We also now plan to support this for extensions as part of declarativeNetRequest API.
>FLOC would not have stopped cross site tracking or improved user privacy
Yes, but the plan was that after FLOC cross site cookies would not be sent. The whole point is to provide an alternative to people using cross site cookies before it gets removed.
---
> But, it's true. Since LineageOS doesn't break Android's security model they could work with phone manufacters / Google to allow LineageOS to be trusted.
There is no evidence that Google would do this. And you're talking about a hypothetical; the fact is that LineageOS is currently blocked. That is what is factually true right now. Saying that it could theoretically be trusted in the future doesn't mean that the Integrity API doesn't block it today.
It doesn't mean that attestation won't block OSes right now. You can't deny that currently the Play Integrity API blocks Android ROMs.
> This API is not about blocking headless chromium. [...] Protecting against that [(password theft)] is unrelated to this proposal.
So first off, this is opinion you, there is nothing in the proposal that indicates that scriptable browsers would be allowed and nothing that references Headless Chromium. You are assuming that Headless Chromium wouldn't be blocked, but I would love to see any statement from Google supporting that assumption.
But more importantly, you're basically saying this proposal blocks nothing at all. Think about what you're saying, this is a proposal that supposedly prevents bots and ad fraud and you're going to allow Headless Chromium? You're like one comment away from telling me, "well, the proposal isn't about guaranteeing OS integrity."
> Considering most Linux users are 1 curl | bash away from installing malware that can easily pivot to root and install a kernel module to hide itself. It's related.
No, this is very transparently an excuse. Out of the reasons for this proposal (as specified in the proposal), kernel level malware is relevant to basically zero of them. Kernel level malware is not the reason why Netflix doesn't run on a rooted Android device. Kernel level malware is not something that matters for blocking web scrapers or bots. Kernel level malware is not the vector through which ad fraud happens. Quite frankly, kernel level malware is not the biggest concern when thinking about bank account theft of phishing attacks.
The reason Linux is blocked is because Linux does not impose computing restrictions on the user.
----
> Can you quote that section. I don't see it.
See https://github.com/RupertBenWiser/Web-Environment-Integrity/..., specifically the bullet-point list under the introduction:
> [...] This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins. [...] Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment. [...] Users playing a game on a website want to know whether other players are using software that enforces the game's rules. [...] Users sometimes get tricked into installing malicious software that imitates software like their banking apps, to steal from those users.
Of those 4 proposals, only the last one (banking security) is directly related to user security, the other 3 are site policies (ad fraud/scraping, blocking bots, blocking game modifications).
> Except this proposal doesn't block any user capabilities. It simply adds a way for sites to check if the user has a secure environment.
This is borderline disingenuous. Giving website authors the ability to arbitrarily block "untrusted" environments (and specifically telling them that the purpose is to allow blocking capabilities in untrusted environments) is the same as blocking user capabilities.
It's especially absurd to deny given that mainline companies like Google will be in charge of determining what environments count as "secure" and what environments will be supported for attestation, so not only is it an API that is designed to allow websites to block clients, it is also very much going to be Google's decision whether or not a given user capability is compatible with a "trusted" environment.
----
> Arch could simply have in their settings app a toggle that allows you to disable trusted mode to allow you to install kernels or whatever you built yourself. Similar to how motherboards let you disable secure boot.
At which point it would be blocked from attestation, hence blocking user freedoms.
Also, custom-built kernels and custom user software are not side-things I can toggle on and off, my setup depends on those things. You can't go into user settings from the desktop in Arch and just turn off the kernel; if I'm using custom drivers for a monitor or input device, I can't just turn those off.
What you are saying is "your OS won't be blocked, you'll just boot into a different OS or different OS-mode without any of your custom kernels or drivers." But take a step back and think about that: the OS is blocked. And the solution you're giving me is to boot into a different OS based on a different kernel that I don't control that doesn't have my custom-compiled drivers and that might not even support my hardware. This is really silly, it's like saying that Apple Pay is fully supported on Android, you just have to boot into an iPhone.
> Rooting breaks the android security model and provides by definition an untrusted environment. Android apps may not want to deal with supporting devices that don't support the security features an Android operating system is supposed to provide.
Like I said, this is about blocking my ability to root my device. It is a reduction in user autonomy under the excuse that user autonomy to root my device makes my device untrusted.
Quite frankly, it should not be an app's choice to decide whether or not to run on a rooted device. It's none of their business whether or not my phone is rooted.
> The Play Integrity API works with apps not from the store.
Technically true in the sense that I believe Aurora spoofs Play Integrity APIs and device checks, but I'm not sure of the full details there, and in any case that's a circumvention of Google's policies, not something that Google explicitly allows. I'm not sure I understand what you mean here?
----
> https://bugs.chromium.org/p/chromium/issues/detail?id=118065...
The currently inactive issue that hasn't been updated for over a year? That's not exactly strong evidence. Let me know when the Chromium team starts working on it and merges it.
In the meantime, it is objectively true that Chrome currently has worse adblocking capabilities (particularly around CNAME cloaking) than Firefox and that it has had worse adblocking capabilities for multiple years. This is not an API that is available for extensions to use.
And the way that CNAME cloaking has played out in Chrome -- given that they are trailing behind other browsers by years does not suggest that any of the other issues with Manifest V3 are going to be better handled. The overwhelming trend here (and what this issue shows) is that Chrome is going to lag behind other browsers on adblocking.
I'm having a hard time figuring out how you're looking at an arguably orphaned issue and seeing that as evidence that the Chromium team cares about adblocking APIs or that they can be trusted to make sure that adblocking capabilities aren't broken.
> Yes, but the plan was that after FLOC cross site cookies would not be sent. The whole point is to provide an alternative to people using cross site cookies before it gets removed.
Right, that's what I said. It was for advertisers, not for users.
Firefox and Safari removed cross site cookies without supplying an alternative just fine, that was a user-focused change. Chrome refused to make a user-focused change until after it introduced a spec (FLOC, later Topics) purely for the benefit of advertisers. In addition, it introduced other specs (Same Site Sets) that weakened those same protections.
Sorry, it's past the window.
>There is no evidence that Google would do this.
There are many OEMs who have gotten their OS approved for it. LineageOS could go through the same process like everyone else to get it approved.
>the fact is that LineageOS is currently blocked. That is what is factually true right now.
That is true, and hopefully things like this proposal will incentivize LineageOS to pursue getting their OS approved.
>So first off, this is opinion you
The current proposal is focused on the OS you are using and not on blocking certain browsers. There is a section "Attester-level acceptable browser policy" saying that if there is demand that could change. Technically with the current proposal an attester could be designed to be more strict in what they will attest to. There could an attestor a website could trust that just enforces OS security and different one which is restricted to some subset of browsers.
>But more importantly, you're basically saying this proposal blocks nothing at all.
The proposal is ambiguous on what is considered a secured environment, but it seems that they are mostly concerned about OS security. Even if it does not perfectly blocks thing it could still be useful. Imagine if there was a way to check if a user has antivirus installed and has ran a recent scan. This signal would be correlated with users who have malware installed.
>Think about what you're saying, this is a proposal that supposedly prevents bots and ad fraud and you're going to allow Headless Chromium?
The proposal does not say that it prevents those things. It says that it can help with preventing those things.
>Kernel level malware is not the reason why Netflix doesn't run on a rooted Android device.
Correct. It is likely more motivated in that rooted Android devices do not adhere to the android security model and not secure to show L3 content on.
>Kernel level malware is not something that matters for blocking web scrapers or bots.
It does matter. BOTH kernel level and user level malware can scrape websites and act as bots.
>Quite frankly, kernel level malware is not the biggest concern when thinking about bank account theft of phishing attacks.
Then a future proposal can try and address the bigger concerns.
>The reason Linux is blocked is because Linux does not impose computing restrictions on the user.
It is clear that Android, which is built upon Linux, will have support for attestation. And again there is no blocking going on. Blocking users is not the goal of the proposal.
>Of those 4 proposals, only the last one (banking security) is directly related to user security, the other 3 are site policies (ad fraud/scraping, blocking bots, blocking game modifications).
Malware on a user's machine can do the last 3.
>This is borderline disingenuous. Giving website authors the ability to arbitrarily block "untrusted" environments (and specifically telling them that the purpose is to allow blocking capabilities in untrusted environments) is the same as blocking user capabilities.
Be upset at sites that do that then.
>It's especially absurd to deny given that mainline companies like Google will be in charge of determining what environments count as "secure" and what environments will be supported for attestation, so not only is it an API that is designed to allow websites to block clients, it is also very much going to be Google's decision whether or not a given user capability is compatible with a "trusted" environment.
Anyone can become an attester.
>Also, custom-built kernels and custom user software are not side-things I can toggle on and off, my setup depends on those things. You can't go into user settings from the desktop in Arch and just turn off the kernel; if I'm using custom drivers for a monitor or input device, I can't just turn those off.
In that case I would recommend you to have Arch sign those drivers.
>What you are saying is "your OS won't be blocked, you'll just boot into a different OS or different OS-mode without any of your custom kernels or drivers.
You wouldn't have to boot into a different OS. The current state of the web is what you would experience. People using a secure environment will have benefits like seeing less captchas.
>Like I said, this is about blocking my ability to root my device
Attestation has nothing to do with preventing people from rooting their device. You still have the same autonomy to root your device.
>Quite frankly, it should not be an app's choice to decide whether or not to run on a rooted device. It's none of their business whether or not my phone is rooted.
Considering rooted devices might negatively impact their business it is their business. Apps were checking for root before attestation existed. If your device is rooted you are able to remove any checks to the app itself that are blocking you from using it on a rooted device.
>Technically true in the sense that I believe Aurora spoofs Play Integrity APIs and device checks, but I'm not sure of the full details there, and in any case that's a circumvention of Google's policies, not something that Google explicitly allows. I'm not sure I understand what you mean here?
I am not talking about spoofing. For example ReVanced is a modded YouTube app that is not in the play store. If you use ReVanced and google attempted attestation they would be able to see that your device is secure, but see that the APK is not from the play store.
>I'm having a hard time figuring out how you're looking at an arguably orphaned issue and seeing that as evidence that the Chromium team cares about adblocking APIs or that they can be trusted to make sure that adblocking capabilities aren't broken.
Priorities change, but you can clearly see that it was being worked on and it did get to the point where it works for Chrome's adblocker. Since chromium is open source anyone could go ahead and finish the implementation, but it doesn't seem like many people see it as a high priority compared to other things which could be worked on.
>Firefox and Safari removed cross site cookies without supplying an alternative just fine
They have less market share so they do not have to be as responsible with changes they make. Google on the other hand could kill many businesses, break people's sites, and cause a large amount of harm if they make big changes like that without finding someway to let people transition to a suitable alternative.
>In addition, it introduced other specs (Same Site Sets) that weakened those same protections.
Chrome doesn't want to break people's sites. People have invested a lot of money in building sites and it is not trivial to just rearchitect them to work.