Unpacking Google’s Web Environment Integrity specification

There is no reason that can't be done with existing web technology, WEI does not advance that use case in any meaningful way.

It provides a uniform service for ensuring a client has desired properties.

That’s kinda tricky to do well. Traffic for monitoring, you can do with a jwt, but like, enabling chunked transfer in python request lib is a problem you discover. An array of attestors could guarantee feature sets.

I'm not understanding how giving the client a token that you put in a request header that proves you've paid, or is just an account lookup token to then ask a payment processor whether or not their account is in good standing, is limited in a way that WEI makes better. I don't see any use cases that wouldn't work that way that would now work with WEI.

>It provides a uniform service for ensuring a client has desired properties.

I see that as a downside, not a benefit -- who decides whether or not a client (i.e., my software running on my hardware) has those "desired properties" and what might those properties be?

> for ensuring a client has desired properties.

There's nothing about payments that requires testing client properties though. What you want is the ability to test if there's a corresponding payment, that has nothing really to do with the client's device. It just seems like irrelevant information, what are these "desired properties"?

You want a corresponding token with the request that matches a payment. And WEI seems like a strictly inferior way to get that instead of just... asking a payment provider for the token. What does my hardware/OS/browser have to do with a payment token?

This will be great when both my partner and i use the same browser but different ... Different what exactly? Ah.. accounts!

"This allows them to detect the actual device"... As if that isn't a solved space already?