Apple's Assault on Standards

Original Article ↗ Hacker News Discussion ↗

Overall reaction to the article

  • Many found the piece rhetorically overwrought, meandering, and hard to read; some stopped at the TL;DR because it felt like inflated prose that obscured the core argument.
  • Others said the tone is “histrionic” but broadly aligned with their view that Apple resists standards and openness.
  • Several note the author’s long history working on Chrome/Blink and now Edge, seeing both welcome insider perspective and potential bias.

Market power: monopoly, duopoly, triopoly

  • Discussion centers on a practical duopoly in mobile OS (Apple/Google) and near-triopoly in browser engines (Blink/WebKit/Gecko).
  • Some argue there is “no real competition” in standards: WHATWG and major browser vendors effectively set them.
  • Debate over whether Microsoft meaningfully counts, since Edge runs Blink; Firefox is seen as the only non‑WebKit, non‑Blink engine with noticeable share, but heavily dependent on Google funding.

Apple’s WebKit lock-in and behavior in standards

  • Strong criticism of Apple’s iOS rule that all browsers use WebKit: 2B devices can’t run alternative engines, so if Safari doesn’t implement a feature, it’s effectively not a standard.
  • Others, including people with standards-body experience, describe Apple’s in‑room behavior on committees as notoriously obstructive and driven by upper management.
  • Counter‑voices say Apple also has a long record of pioneering and adopting standards and that proprietary tech is sometimes used to deliver desired UX.

Google/Blink dominance and “standards”

  • Several argue the article underplays Google’s own monopoly and its role in driving “standards” that are really Blink-originated features.
  • WebUSB/WebBluetooth/WebNFC are highlighted as Blink‑only APIs repeatedly rejected by both Mozilla and Apple on security/privacy grounds; commenters note they are not standards precisely because nobody else would implement them.
  • Example given: WebMIDI was abused by porn sites for fingerprinting, reinforcing skepticism of exposing low‑level capabilities via the web.

Security, hardware access, and user interests

  • One camp: deep hardware APIs (Bluetooth, USB, NFC, HID, etc.) via the browser are vital for an open, app‑like web and avoiding proprietary native apps.
  • Opposing camp: many users don’t want browsers to become full OSes; strong sandboxes and platform‑native apps are seen as safer.

Apple as bulwark vs. Apple as threat

  • Some frame Apple’s WebKit lock‑in as the last effective bulwark against a Blink/Chrome monoculture and “Made for Chrome” web.
  • Others say this gives Apple a local monopoly that harms developers and users, and that Google’s Android model (where Chrome can be disabled and alternative browsers installed) is more open in practice.
  • There’s broad agreement that regulators and commentators often attack Apple alone, without fully grappling with Google’s parallel power.

Broader ecosystem and standards-process issues

  • Commenters invoke “Too Big To Fork”: as the web’s complexity grows, incumbents with money and market share gain de facto control, regardless of formal openness.
  • Some note W3C’s slow, XML‑era stagnation and that many key web primitives (XHR, div/span, etc.) started as de facto vendor or developer inventions before standardization.
  • Several call for making the web more modular and easier to re‑implement, but acknowledge this is technically very hard.