I apologize for an off-topic request, but if it's not past the edit window could you go over your comment and clean up the references/formatting? I think you may have had some errors copying and pasting quotes from my comment to reply and may have pasted more of my comment than you intended; this is very difficult to follow.
---
> 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.
> [...] 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?
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.
>but if it's not past the edit window could you go over your comment and clean up the references/formatting?
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.
> That is true, and hopefully things like this proposal will incentivize LineageOS to pursue getting their OS approved.
If Google is in charge of deciding which OSes get approved, then this is about blocking OSes. I'm sorry. You can not in one breath argue that this isn't about blocking anyone and in the next breath argue that everyone needs to get their OS approved by Google.
> The current proposal is focused on the OS you are using and not on blocking certain browsers.
The current proposal does not describe attestation requirements, you're reading into this document something that is never specified. In fact, the current proposal explicitly calls out browser blocking as a possibility and calls that an unsolved problem: "Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements. This leads to any browser running on the given OS platform having the same access to the technology, but we still have the risks that 1) some websites might exclude some operating systems, and 2) if the platform identity of the application that requested the attestation is included, some websites might exclude some browsers."
The proposal does not offer a concrete plan for preventing either scenario, it throws out a few ideas and then says, "we'll have to see." The proposal also does not at any point state that browsers will not be blocked. It states that any browser that "meets requirements" should be allowed. It does not specify what those requirements are, and there's no evidence offered in the document that a browser like Headless Chromium would qualify for them.
> And again there is no blocking going on.
We keep dancing around this, it's false. It's false given even the assumptions you've brought up. You yourself admit that OSes would be blocked. There is no reason to give a signal to a website about whether an environment is trusted other than to aid with blocking. Even the most charitable interpretation of this spec involves blocking. Every single risk listed in the spec involves blocking.
Please stop saying that this isn't about blocking, attestation as a concept is about blocking based on tampering signals.
> 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.
I'm sorry, you think this is would be a good thing? You think that giving a website the ability to deny access if I don't have a trusted antivirus installed is in any way appropriate for the Open web?
> Malware on a user's machine can do the last 3.
I don't know if you're deliberately being obtuse about this, but very obviously malware is not what anyone is thinking about when they talk about cheating in video games or blocking bots from social websites.
> Be upset at sites that do that then.
Or, be upset at the people who give them the capability and encourage them to do so.
> Anyone can become an attester.
The proposal in fact says the opposite, that there will be a small number attesters and they'll be vetted by browsers.
> In that case I would recommend you to have Arch sign those drivers.
No. It's not Google's business if the drivers are signed. It's not my browser's business if those drivers are signed. It is none of their business what OS they're running on or what drivers are loaded.
> Attestation has nothing to do with preventing people from rooting their device. You still have the same autonomy to root your device.
I'm not sure what to respond to this with other than that it's obviously incorrect. Attestation in fact both can be used to directly prevent rooting and can be used to indirectly prevent rooting by shutting down services on rooted devices. Like... I don't know what argument to give you if you don't see a causal relationship between the two. Attestation is about blocking services and imposing consequences on modified devices, including rooted devices.
> 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.
You're just kinda saying things. There is nothing in the proposal that indicates this. Attestation has never worked this way in any context.
> 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.
Oh my goodness, this is on a technical level just not how modern attestation works. It's designed to be incredibly difficult to circumvent, and hardware-level attestation makes that even more difficult. You can't just remove the checks, you need to be able to generate a signed attestation key. Please look up how TPMs work.
> 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.
No, the opposite. This is unreleased. It never got to the point where it works for Chrome's adblocker. It didn't get to any point. It got triaged a year ago and there's been zero activity on it since; CNAME uncloaking for extensions does not exist in Chrome. And to argue that the Chromium team cares about adblocking in one sentence and to say that it's everyone else's job to implement fixes is utterly absurd.
The reality is that Chrome has worse adblocking than Firefox and that they are lagging behind on extension features. There is no reason to believe that will change in the near future.
----
I'm just going to kind of group some stuff together here:
> Considering rooted devices might negatively impact their business it is their business. [...] 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. [...] Imagine if there was a way to check if a user has antivirus installed and has ran a recent scan. [...] [etc]
This conversation started out as "nobody is trying to restrict anything" and whenever I actually poke at the edges of that, I find you offering excuses for why certain OS setups should be restricted. People should "just" get all of their custom drivers signed. If LineageOS isn't an authorized ROM, that's their fault, not Google's.
Your reply here is littered with technical misinformation and with assertions about how this will play out that seem to be based entirely on hopes and dreams rather than any technical mitigations or policies. But the bigger issue is that underneath all of it, you are trying to convince me that Google is not trying to limit device autonomy -- and the truth is, you do not support device autonomy in the way that Google's critics do.
It is bad for a custom ROM to have to get Google's permission to get signed or treated as a trusted app environment. That should not be Google's choice to make. It is bad for websites to have insight into whether or not an OS has a virus scanner installed. It is bad to require Open Source drivers to go through a validation process with Chrome. It is bad to punish users with rooted devices by throwing additional captchas at them. These are outcomes that are bad for user agency, user freedom, and user autonomy. And they will lead to worse outcomes including degraded adblocking performance and less user agency over devices.
Now, you're trying to convince me that they won't. But the underlying issue here is, once again, you disagree with me about what degraded adblocking performance even looks like. In your mind, it's not Google's responsibility to fix those problems, it's an Open Source project and someone else should do it for them. In your mind, blocking 20% fewer ads than another a browser is no big deal, it's not worth complaining about. And you can't get through one of your replies without going to bat for advertisers, basically saying that it would be irresponsible for Google to make user-privacy improvements in Chrome without thinking about the impact on advertisers.
The big issue here is not that we disagree about what the policy says (although we clearly do). What I'm seeing in your reply is that "critics are overreacting" on some level means "the user-freedom, privacy, and autonomy requests that they have are unreasonable."
So no, I don't trust Google's motivations and you probably can't convince me otherwise, because looking at the things you keep saying in these comments -- your list of acceptable outcomes from this policy are different from my list of acceptable outcomes. What you view as user abuse is different from what I and many Google critics view as user abuse. And it is not overreaction or ignorance or fearmongering that causes Google critics to advocate against this change. It's that critics have a different value system about user autonomy than you do.
---
> 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.