> There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS
If you are that naive look where Android is now today.
Despite being open source and having some alternative distributions, many banking and other "serious" institutions apps only work on official builds blessed by Google.
They also block screenshots and remote screen.
All thanks to Android\Google Play Protect DRM.
If DRM is added to the web expect these same institutions to be early adopters so they can restrict access to their websites to only the browsers controlled by big tech and only without extensions.
The only DRM currently available on the web that I'm aware of relates to video.
Banks don't have to restrict their apps against unauthorized Android builds and rooted devices with Play Protect but they do. There is nothing to gracefully degrade when your goal is actually to just restrict access.
Also the banks already just plain restrict access on the web, unconditionally, by making a smartphone app a mandatory auth / confirmation factor. And the app itself, of course, makes full use of Google's attestation APIs like you describe.
So at this point allowing for the web to be nearly as secure as a native app would allow for these sites to potentially start working on the web again.
I've commented to this point in the past, but I don't care about the web winning, I care about the things that make the web the web -- user-controlled agents, being platform-agnostic, extensibility, etc...
If we're willing to give that stuff up in order to bring native apps back to the web, then we can save a lot of time and effort and just redefine the web to include mobile apps and get Google to re-label all the native apps in the Play Store as webapps and change nothing else. Then those apps will technically be on the web! No developer changes even needed, the web won! /s
The problem is not that the banks aren't on the web. The problem is that the banks deny user-agency. That's the problem I want to fix by bringing apps to the web. My goal is not to get the bank app served over an HTTP request, I don't care about that part. I don't care if the bank's interface was written in Java or Javascript. I don't care if the bank is caching data in service workers or on disk.
My goal is to get the bank app to respect user-agency, that's the part I care about.
If we make the web into a native environment, then it doesn't matter anymore whether or not app developers are using it. The web forcing developers to support user freedoms is the primary reason we want webapps. The web is a means to an end, not an end in and of itself.
Unless you're calling extra low resolution graceful? I wouldn't when there's no reason for it. And things that use the Google DRM on phones usually just shut off.
Yes, I am talking about low resolutions that they understand will be easily stolen. Websites aren't mobile apps and the intention was that this API was not to be used for blocking.
The 4K DRM'd stuff is also easily "stolen". It's not as if it's actually working. It only takes one mildly sophisticated actor to get around it, share the resulting files and then your fancy DRM is completely useless.
So what is this DRM actually accomplishing? Well, it makes it so that on platforms that don't support the DRM, piracy is actually a better user experience. All it did was create an additional(if minor) incentive for Linux users to just download the stuff for free instead of paying for Netflix.
If you are that naive look where Android is now today.
Despite being open source and having some alternative distributions, many banking and other "serious" institutions apps only work on official builds blessed by Google. They also block screenshots and remote screen.
All thanks to Android\Google Play Protect DRM.
If DRM is added to the web expect these same institutions to be early adopters so they can restrict access to their websites to only the browsers controlled by big tech and only without extensions.