The freedom problem is this: you will not be able to roll your own keys.
This is probably the biggest nail in the coffin for a ton of computers out there. In theory you could simulate via software the workings of a TPM. If you built a kernel module the browser would have no real way of knowing if it sent requests to a piece of hardware or a piece of software. But the fact that you would have to use Microsoft's or Apple's keys makes this completely impossible.
The hardware problem is this: you will not be able to use older or niche/independent hardware.
As we established that software simulation is impossible, this makes a ton of older devices utter e-waste for the near future. Most Chromebooks themselves don't have a TPM, so even though they are guaranteed updates for 10 years how are they going to browse the web? (maybe in that case Google could actually deploy a software TPM with their keys since it's closed source). I have a few old business laptops at home that have a 1.X version of the TPM. In theory it performs just as well as TPM 2.X, but they will not be supported because, again, I will not be able to use my own keys.
Lastly there is the social problem: is DRM the future of the web?
Maybe this trusted computing stuff really is what the web is bound to become, either using your certified TPM keys or maybe your Electronic National ID card or maybe both in order to attest the genuineness of the device that is making the requests. Maybe the Wild West era of the web was a silly dream fueled by novelty and inexperience and in the future we will look back and clearly see we needed more guarantees regarding web browsing, just like we need a central authority to guarantee and regulate SSL certificates or domain names.
This is the actual missing key bit. The problem that Google is trying to solve here is not actually a hardware / computational problem, it's a Real Identity problem. Hardware / TPMs are a poor proxy for solving that problem.
There's drastically less eWaste and impact on software freedom if you seek attestation from a national ID provider than if you seek attestation from one of a handful of personal electronics OEMs. National ID providers can offer to sign not only Real Identity attestations, but also anonymized attestations to protect citizen privacy. A web operator can decide whether to allow for attestations from only their own national ID provider, foreign national ID providers, private ID providers, or none at all if they just have a read-only site and don't really care.
The truth is that government inaction is forcing Big Tech down the road of violating user privacy and freedoms to solve Big Tech's problems. But getting the government to offer a flat Identity Provider playing field would solve these problems in a way that doesn't require such violation.
For example you could have the website never knowing your actual ID but simply passing an encrypted string to the national server, which would return a 200 response if the document is valid. You could also have additional requests like "is the user 18+".
The website will just know the request is coming from something which has a valid ID available. The state will also not know which pages you browsed, only the domain of the request, just like with HTTPs your ISP does not know exactly the pages you browse but just the websites themselves.
And before someone talks about the state knowing your browser history: they already can by calling up your ISP, and they would get a lot more information than this mechanism would provide.
The ISP, with SNI implemented, would only be able to tell the state that "a device connected through this physical location accessed a server through Cloudflare".
1. 18+website tells the browser age verification is needed, gives a random token
2. Browser signs a verification request with the local ID card (or a key temporality allowed to do so), forwards it to government server
3. Government server sees the request with random token, signs both, answer the browser
4. Browser forwards signed attestation to 18+website.
The government server only sees the random token. The website only has the attestation. There are other things that can be nitpicked against, but not this. For instance, can we require local ID cards? What about foreign visitors? Possibly an attestation from their passport? And of course, browsers sit in the middle and see everything.
However, this could be a useful mechanism to have. For age verification, nationality check, or even identity check on official websites. And if we have this, it's bound to be abused in some ways (Facebook could require an ID check).
Conversely, that system is not secure if the site conspires with the government, because the government could record the signature (or the token) and then compare it to the one the site has to violate the anonymity of a legitimate user. There are forms of encryption that prevent this (the user does a cryptographic operation on their own device that munges the data so the site can still verify the signature but can't tell which one it was), but now you need the government to implement that system -- and update it if any vulnerability is found -- and do a coordinated update of all the sites in the world with the new protocol that patches whatever vulnerability is found -- and do this rapidly and competently because in the meantime the system would have to be taken offline to avoid it being actively exploited.
Do Not Attempt. Failure inevitable.