I find this tweet about how Google approaches web standards illuminating. To quote: > 1. design a flawed API (it's fine! APIs are hard) > 2. ship it in the most-used browser, despite objections > 3. get cross-browser working group to fix the API > 4. oops, too late, that would break the web twitter.com/Rich_Harris/status/12204127…

This is precisely why I use non-Chromium browsers as my daily driver. It's their constant push for non-standard APIs and aggression towards other browsers that doesn't implement their favored APIs that's cementing their dominance. Not having support for Google features shouldn't be a reason not to support other browser engines. Some examples: news.ycombinator.com/item?id=17606027 twitter.com/Rich_Harris/status/12204127… Some additional rants: > I like that I can search Google by voice in Chrome, Chrome is a blessing for enthusiastic Google users, but not all people feel the same way. > MIDI support More access to HW is the last thing I want from the web at this moment. I'd rather that browser vendors focus on making the privacy footprint smaller, not bigger. > And I hate the ads and recommended sites You're going to see more of those on Chrome when uBo ceases to stop working along with all other manifest V2 extensions.

> Up to and including the point where both Mozilla and Safari are saying they won't implement certain functionality because of glaring holes in the design, and Chrome not only shipping the features, but making them GA. I feel this is being dismissed by many people, but there's a lot of truth in this statement. Here's an example of this at play: twitter.com/Rich_Harris/status/12204127… Chrome devrels and cheerleaders pile on Safari and Firefox all the time for not adhering to Chrome's agenda and frame it as "holding the web back." But the true thing that holds the web back is a browser monoculture.

> Why, then, did it take safari so long to implement ServiceWorkers? > Also, why was Safari's IndexedDB feature released Priorities. Safari's team isn't as big as Chrome's. > but the pattern is fairly obvious. The only obvious pattern is the link I provided. And things like this: - Chrome releasing APIs even when other vendors are against: twitter.com/Rich_Harris/status/12204127… - Chrome sabotaging competitors with shady practices: archive.is/tgIH9 and there are many many many more examples of this behaviour.

It's not "purely hypothetical." It's reckless and irresponsible of you to spread misinformation like that based on wishful thinking. WebUSB made it possible to work around Yubikey phishing protection [1]. WebMIDI allows websites to overwrite device firmware, which is a dangerous capability that could result in a sandbox escape [2]. Granting a website WebNFC permissions makes it possible to read TOTP tokens stored on Yubikeys at any point later on [3], which is worrying because ordinary users can't possibly deduce that from permission prompts. Battery Status API was heavily abused for fingerprinting by the time it was removed from Firefox [4]. I'm amazed that you dismissed that as a "hypothetical" concern, because if anything, it's the legitimate uses of the API that was hypothetical [5]. Uber used it to "inflate Uber prices for desperate users with low batteries." [5] [6]. But one don't even need theses examples to see how bad theses APIs are. Hardware are mostly designed to work with local applications. To expose them to websites is a fundamentally flawed idea. Google justifies them by adding permission prompts each time a problem emerges, but users can't possibly be expected to be fully aware of the consequences of allowing raw hardware access to websites with mere dialogs that they blindly click through. And oh I wish there were only 3 bad APIs like you hinted. There are more than that. WebMIDI, WebNFC, WebSerial, WebHID, Generic Sensor API, File System Access, Low-level Sockets API, Network Information API, and the list goes on. These aren't isolated examples. It's part of a broader pattern where Google ships an anti-feature, asks for "feedback" which means nothing because "devs already depend on it," and "standardizes" it despite opposition from the remaining browser vendors [7] [8]. I’ll judge browser security based on a broad set of examples rather than a cherry-picked one every time. [1]: wired.com/story/chrome-yubikey-phishing… [2]: github.com/mozilla/standards-positions… [3]: github.com/mozilla/standards-positions… [4]: cs.princeton.edu/~arvindn/publications…... [5]: groups.google.com/g/mozilla.dev.platfor…... [6]: forbes.com/sites/amitchowdhry/2016/05/2…... [7]: github.com/mozilla/standards-positions… [8]: twitter.com/rich_harris/status/12204127…