Apple's Assault on Standards

Original Article ↗ Hacker News Discussion ↗

Apple’s control over browser engines on iOS and its slow or selective adoption of web standards are criticized as undermining the open web, yet many argue this focus ignores Google’s dominant influence through Chromium/Blink and the de facto standards it drives. Commenters clash over whether Apple is a harmful gatekeeper blocking useful capabilities like WebUSB or a necessary counterweight preventing a “made for Chrome” monoculture and risky hardware-access APIs in browsers. Underneath the browser politics are broader concerns about monopolies, security versus openness, the legitimacy of standards that only one vendor implements, and how much power any single company should wield over the direction of the web.

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.