Apple already shipped attestation on the web, and we barely noticed

I kind of get both sides here. If we take the "see the best of others intentions" then a web that is populated by identified humans (and their authorised proxies!) is likely to be the "cleanest", most ideal web space we can see (a web full of sock puppets and link farms is not ideal).

The clearest end point for this is some government issued digital ID that just asserts who you are, acts as a login etc.

You can see this as a stepping stone to there. if you squint.

Is it the idealism of the 70s coke to life? No. Is it some sane compromise - I think so.

What if we cannot trust our government ? Sorry it is pretty sure that no internet is going to solve that. That's on the real world.

Whether this is bad or good really depends on the details and the overall strictness. It seems like none of the articles I've seen on the subject go into depth explaining what makes a device "legitimate."

This could be a really good thing if all it's doing is proving that your device isn't malicious, or being better able to detect whether you are a bot. If our end-user experience doesn't change but we stop filling out CAPTCHAs and seeing Cloudflare bot checker load screens, that would be a big plus.

This could be a really bad thing if it means that the web now will just widely reject alternative browsers or computers that have elevated administrative permissions.

I think if we want to see how this plays out, we can look at the Google Play store. A common example that already exists is that banking apps will block rooted Android devices, and it sounds like this attestation API will have the ability to do something similar.

In my opinion, that situation seems perfectly reasonable, and it also seems like most websites don't have the same incentive to block modified devices as higher security services like banks.

Legit for banks tends to just mean that basic security rules are being enforced, like app separation and credential protection. Technically, what banks and other fraud-sensitive services care about is not whether your device allows you to do things or not, but whether it allows malware to do things. If malware can get root then it can steal credentials that would let it impersonate the user and initiate cash transfers.

That's why Android devices allow you to obtain root and unlock the bootloader but factory reset the device whilst doing it. Banks don't care about that feature because it's not accessible to malware and even if someone does it (e.g. because they physically swipe your phone for a few minutes) the login cookies are wiped in the process.

The problem with rooting or jailbreaking outside of this process is that it could have been done by malware instead of the user - you can't tell post-hoc - and even if it was done by the user, rooted phones often have semi-broken security systems e.g. they turn sudo on or users run random apps as root that were grabbed off anonymous GitHub accounts. From the bank's perspective all this is highly risky both for you and more importantly for them, as ultimately weak security = fraud = reputational and financial risk to the bank.

Still, realistically, what banks care about is devices that were silently rooted by malware (or physical thieves). Individual Linux hackers are such a tiny number of people they'd probably be OK with just letting those people get rinsed if they run malware. The problem is, how do you know which is which?

A meet-in-the-middle compromise for the banking use case is for some neutral standards body to certify OS builds against a set of concretely specified security goals, whether they're open source or not. There's no specific technical problem, it's a social issue that it's expensive to do such audits and open source hackers don't want to pay for things. LetsEncrypt solved the same problem with SSL by just brute forcing the issue with money, which may be the way Google/Apple choose to go here. If you want root on your device to customize your window manager or something then no, don't give yourself root, instead spin a deterministic OS build with whatever changes you would have made using root, ensure the OS build is secure and then submit it for auditing. Done properly the audit can be mostly automatic, e.g. if the SELinux rules match the set found in a base distro that's already trusted, then you can know that credential protection/debug APIs are configured as before, so then you can wave through changes to non-critical OS processes.