Like any technology, there are both positive and negative aspects of it. The positive take would probably be that this technology is already widely used by iOS and Android apps. People use Apple's AppAttest to e.g. ensure that high scores submitted for a game are from a legitimate copy of the game and not just someone calling the SubmitHighScore API.
But it's absolutely fair to argue that the web operates on a different set of expectations than the Play Store/App Store, and I think the concerns that this will create a second-class citizen status for browsers are totally valid. There's a huge difference in character between "in order to prevent piracy and ensure ad revenue we are only releasing our app on the Play Store" and "we are only releasing our web app for Chrome".
> People use Apple's AppAttest to e.g. ensure that high scores submitted for a game are from a legitimate copy of the game and not just someone calling the SubmitHighScore API.
But that's for Apps. Native Apps, not websites. If we argue this way, then this becomes a solution seeking an issue, since the first thing you learn in web programming is to never trust the client. I don't even see how this changes here, given that it won't mitigate any bugs, except giving me proof that the only bugs present on the client side system are the ones written by me.
The reason Google actually want's to implement this, is because they risk loosing huge amounts of revenue due to adblocking, something they can control on mobile (since they control the software supply chain there) but cannot do in the browser (since I have access to the DOM).
But it's absolutely fair to argue that the web operates on a different set of expectations than the Play Store/App Store, and I think the concerns that this will create a second-class citizen status for browsers are totally valid. There's a huge difference in character between "in order to prevent piracy and ensure ad revenue we are only releasing our app on the Play Store" and "we are only releasing our web app for Chrome".