zlacker

>>dagurp+(OP)

    > Can we just refuse to implement it?
    > Unfortunately, it’s not that simple this time. Any browser choosing not to implement this would not be trusted and any website choosing to use this API could therefore reject users from those browsers. Google also has ways to drive adoptions by websites themselves.

This is true of any contentious browser feature. Choosing not to implement it means your users will sometimes be presented with a worse UX if a website's developers decide to require that feature.

But as a software creator, it's up to you to determine what is best for your customers. If your only hope of not going along with this is having the EU come in and slapping Google's wrist, I'm concerned that you aren't willing to take a hard stance on your own.

>>wbobei+Hz1
What sets WEI apart is that it, in a way, exerts power over your choice on how to implement other web features, for example whether you're allowed to block elements, or even just show a developer console.

Other than Encrypted Media Extensions (and these are much more constrained than WEI!), I don't know of any other web standard that does that.

>>lxgr+jC1
While it's a much lesser offense, many APIs are only available in "Secure Contexts", so it's not entirely a new concept https://webidl.spec.whatwg.org/#SecureContext

>>wbobei+lF1
Getting a secure context costs $0 and takes no effort in many common webservers at this point.

I do remember the controversy at the time of everybody shifting to HTTPS only, though, and how it might exclude small/hobbyist sites. Fortunately, we've found ways to mitigate that friction in the end. I'm much less optimistic here.

>>lxgr+PF1
> Fortunately, we've found ways to mitigate that friction in the end.

Some of it, yes, but there are a nontrivial number of small/hobbyist sites that never overcame that friction.