>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.