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
Google has been beat-down before trying to do these kinds of things. 2 ones I can think of:

1) FLoC: https://www.theverge.com/2022/1/25/22900567/google-floc-aban...

2) Dart: Google wanted this to replace javascript, but Mozilla and MS both said no way, as they had no part in it. So that project ended up dying.

Google tries lots of things. Mozilla, MS, and Apple are still strong enough (especially outside the US) to push back on things that they think are a bad idea.

>>kyrra+6R1
Dart is still around. The Flutter framework is growing in popularity.

Apple already built and shipped this same feature last year, so they're not opposed. MS? Probably gonna love this. Mozilla hasn't said anything on it (yet at least). I'm not expecting any of those players to save us.