On one side, we'll have a "clean", authority-sanctioned "corpweb", where everyone is ID'ed to the wazoo; on the other, a more casual "greynet" galaxy of porn and decentralized communities will likely emerge, once all tinkerers get pushed out of corpnet. It could be an interesting opportunity to reboot a few long-lost dreams.
I also kind of want it in the public-cloud-meets-private-use home environment (that is, my Cloudflare Access tunnels and MS365 business tenant I use for private stuff).
I don’t want it to touch my personal browsing experience or in any way involved in my personal-use browser environments.
These are effectively opposed desires at this point, and it’s a cat-out-of-the-bag technology.
I can also imagine an IPv7 with ephemeral addresses based on private keys (like on yggdrasil), and a way for the browser to remember keys if wanted by the user. Authenticate sessions with the "IP address".
Attestation does a reasonably well job at that, as you now need a kernel or bootloader exploit.
On desktop? Nope, which is the point. Placing a piece of malware is easy without a kernel exploit. On standard Linux distributions that do not use dm-verity and friends, local root is enough - modify the kernel image or initrd in /boot, and you can do whatever you want with very few ways for a system administrator to detect it upon the next boot. The challenge more is getting local root in the first place, especially as a lot of systems now use selinux or at least have daemons drop privileges.
Windows is a bit harder since Windows refuses to load unsigned drivers since the Win7 x64 days (x86 IIRC didn't mandate the checks), but that's not as much of a hurdle as most think - just look at the boatload of cases where someone managed to steal (or acquire legitimately) a signing certificate to ship malware. Getting local root here is probably the easiest of all three OSes IMO, given the absurd amount of update helpers and other bloatware that got caught allowing privilege escalation regularly.
The hardest IMO/E is macOS, where you have to manually boot to recovery to deactivate SIP and they've been phasing out kexts pretty much already, and you get a crapton of very strong warnings if you mess around with them - you have to manually load them.
With attestation and code-signing done right, it's all but impossible to get your code running in kernel space on Linux and macOS without a kernel exploit, the achilles heel will always be who gets signing certificates that allow loading a module.
The goal of remote attestation is only to be able to prove to a third party that your device is "secured", which does not benefit the user in any way other than awkward/indirect stuff like where in the Google proposal they argue that users have a "need" to prove to a website that they saw an ad (to get free content).
Either you build a massive database of "known good" combinations of hardware, OS, kernel modules versions and corresponding TPM checksums, or you leave that job to a third party - and that is what remote attestation is at its core. Apple has it the easiest there, they control everything in the entire path, while Google has to deal with a myriad of device manufacturers.
Note I massively dislike the path that more and more applications take to restrict user freedom, but I do see why corporations find it appealing.