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.