Reading List

The most recent articles from a list of feeds I subscribe to.

Comforting Myths

Infrequently Noted

In several recent posts, I've attempted to address how the structure of standards bodies, and their adjacent incubation venues, accelerates or suppresses the potential of the web as a platform. The pace of progress matters because platforms are competitions, and actors that prevent expansions of basic capabilities risk consigning the web to the dustbin.

Inside that framework, there is much to argue over regarding the relative merits of specific features and evolutionary directions. This is healthy and natural. We should openly discuss features and their risks, try to prevent bad consequences, and work to mend what breaks. This competitive process has made browsers incredibly safe and powerful for 30 years.

Until iOS, that is.

Imagine my surprise upon hearing that Apple isn't attempting to freeze the web in amber, preserving advantages for its proprietary platform, and that it instead offers to redesign proposals it disagrees with.

As I have occasionally documented, this has not been my experience. I have relatively broad exposure to the patterns of Apple's collaboration, having designed, advised on, or led teams that built dozens of features across disparate areas of the platform since the Blink fork.1

But perhaps this was the wrong slice from which to judge? I've been hearing of Apple's openness to collaboration on challenging APIs so often that either my priors are invalid, or something else is at work. To find out, I needed data.

A specific parry gets deployed whenever WebKit's sluggish feature pace comes up: “controversial” features “lack consensus” or “are not standards” or “have privacy and security problems” (unspecified). The corollary being that Apple engages in good-faith to address these developer needs in other ways, even in areas where they have overtly objected.

Apple's engine has indisputably trailed Blink and Gecko in all manner of features over the past decade. This would not be a major problem, except that Apple prevents other browsers from delivering better and more competitive web engines on iOS.

Normally, consequences for not adopting certain features arrive in the market. Browsers that fail to meet important needs, or drop the ball on quality lose share. This does not hold on iOS because no browser can ship a less-buggy or more capable engine than Apple's WebKit.

Because competitors are reduced to rebadging WebKit, Apple has created new responsibilities and expectations for itself.2 Everyone knows iOS is the only way to reach wealthy users, and no browser can afford to be shut out of that slice of the mobile market. Therefore, the quality and features of Apple's implementation matter greatly to the health and competitiveness of the web.

This put's Apple's actions squarely in the spotlight.

It's possible to size up Apple's appetite for problem-solving in several ways. We can look to understand how frequently Apple ships features ahead of, or concurrently with, other engines because near-simultaneous delivery is an indicator of co-design. We can also look for visible indications of willingness to engage on thorny designs, searching for counter-proposals and shipped alternatives along the way.

This chart tracks single-engine omissions over the past decade; a count of designs which two engines have implement but which a single holdout prevents from web-wide availability:

Features missing in one engine, '15-25. Lower is better.<br>Safari consistently trails every other engine, and APIs missing from it impact every iOS browser.
Features missing in one engine, '15-25. Lower is better.
Safari consistently trails every other engine, and APIs missing from it impact every iOS browser.

Thanks to the same Web Features data set, many views are possible. This data shows that there are currently 178 features in Chromium that are not available in Safari, and 34 features in Safari that are not yet in Chromium. (or 179 and 37 for mobile, respectively). But as I've noted previously, point-in-time evaluations may not tell us very much.

I was curious about delays in addition to omissions. How often do we see evidence of simultaneous shipping, indicating strong collaboration? Is that more or less likely than leading vendors feeling the need to go it alone, either because of a lack of collaborative outreach, or because other vendors do not engage when asked?

To get a sense, I downloaded all the available data (JSON file), removed features with no implementations, removed features introduced before 2015, filtered to Chrome, Safari, and Firefox, then aggregated by year. The resulting data set is here (JSON file).

The data can't determine causality, but can provide directional hints:

Safari rarely leads, but that does not mean other vendor's designs will stand the test of time. But if Apple engages in solving the same problems, we would expect to see Safari leading on alternatives3 or driving up the rates of simultaneously shipping features once consensus emerges. But these aren't markedly increased. Apple can, of course, afford to fund work into alternatives for “problematic” APIs, but it doesn't seem to.

Narratives about collaboration in tricky areas take more hits from Safari's higher incidence of catch-up launches. These indicate Apple shipping the same design that other vendors led with, but on a delay of two years or more from their first introduction. This is not redesign. If there were true objections to these APIs, we wouldn't expect to see them arrive at all, yet Apple has done more catching up over the past several years than it has shipped APIs with other vendors.

This fails to rebut intuitions developed from recent drops of Safari features (1, 2) composed primarily of APIs that Apple's engineers were not primary designers of.

But perhaps this data is misleading, or maybe I analysed it incorrectly. I have heard allusions to engagement regarding APIs that Apple has publicly rejected. Perhaps those are where Cupertino's standards engineers have invested their time?

Most of the hard cases concern APIs that Apple (and others) have rightly described as having potentially concerning privacy and security implications. Chromium engineers agreed those concerns have merit and worked to address them; we called it “Project Fugu” for a reason. In addition to meticulous design to mitigate risks, part of the care taken included continually requesting engagement from other vendors.

Consider the tricky cases of Web MIDI, Web USB, and Web Bluetooth.

Apple has supported MIDI in macOS for at least 20 years — likely much longer — and added support for MIDI on iOS with 2010's introduction of Core MIDI in iOS 4.2. By the time the first Web MIDI proposals broke cover in 2012, MIDI hardware and software were the backbone of digital music and a billion dollar business; Apple's own physical stores were stocking racks of MIDI devices for sale. Today, an overwhelming fraction of MIDI devices explicitly list their compatibility with iOS and macOS.

It was therefore a clear statement of Apple's intent to cap web capabilities when it objected to Web MIDI's development just before the Blink fork. The objections by Apple were by turns harsh, condescendingly ignorant and imbued with self-fulfilling stop-energy; patterns that would repeat post-fork.

After the fork and several years of open development (which Apple declined to participate in), Web MIDI shipped in Chromium in early 2015. Despite a decade to engage, Safari has not shipped Web MIDI, Apple has not provided a “standards position” for it4, and has not proposed an alternative. To the best of my knowledge, Apple have also not engaged in conversations about alternatives, despite being a member of the W3C's Audio Working Group which has published many Working Drafts of the API. That group has consistently included publication of Web MIDI as a goal since 2012.

Across 11 charters or re-charters since then, I can find no public objection within the group's mailing list from anyone with an @apple.com email address.5 Indeed, I can find no mentions of MIDI from anyone at Apple on the public list. Obviously, that is not the same thing as agreeing to publication as a Recommendation, but it also not indicative of any attempts at providing an alternative.

But perhaps alternatives emerged elsewhere, e.g., in an Incubation venue?

There's no counter-proposal listed in the WebKit explainers repository, but maybe it was developed elsewhere?

We can look for features available behind flags in Safari Technology Preview and read the Tech Preview release notes. To check them, I used curl to fetch each of the 127 JSON files that are, apparently, the format for Safari's release notes, pretty-printed them with jq, then grepped case-insensitively for mention of “audio” and “midi”. Every mention of “audio” was in relation to the Web Audio API, the Web Speech API, WebRTC, the <audio> element, or general media playback issues. There were zero (0) mentions of MIDI.

I also cannot locate any public feedback on Web MIDI from anyone I know to have an @apple.com email address in the issue tracker for the Web Audio Working Gropup or in WICG except for a single issue requesting that WICG designs look “less official.”

The now-closed Web MIDI Community Group, likewise, had zero (0) involvement by Apple employees on its mailing list or on the successor Audio Community Group mailing list. There were also no (0) proposals covering similar ground that I was able to discern on the Audio CG issue list.

Instead, Apple have issued a missive decrying Web MIDI as a privacy risk. As far as anyone can tell, this was done without substantive analysis or engagement with the evidence from nearly a decade of deploying it in Chromium-based browsers.

If Apple ever offered an alternative, or to collaborate on a redesign, or even an evidence-based case for opposing it,6 I cannot find them in the public record.7


Missing alt text

USB is a security sensitive API, and Web USB was designed with those concerns in mind. All browsers that ship Web USB today present “choosers” that force users to affirmatively select each device they provide access to, from which sites, and always show ambient usage indicators that let users revoke access. Further, sensitive device classes that are better covered by more specific APIs (e.g., the Filesystem Access API instead of USB Mass Storage) are restricted.

This is far from the Hacker News caricature of "letting any web page talk to your USB devices," allowing only point connections between individual devices and sites, with explicit controls always visible.

Web USB has been available to an overwhelming majority of the web's users for the better part of a decade. The sky has not fallen.
Web USB has been available to an overwhelming majority of the web's users for the better part of a decade. The sky has not fallen.

After two years of public development and a series of public Origin Trials lasting seven months (1, 2), the first version of the API shipped in Chrome 61, released September 2017.

I am unable to locate any substantive engagement from Apple about alternatives for the motivating use-cases outlined in the spec.

With many years of shipping experience, we can show that these needs have been successfully addressed by WebUSB; e.g. teaching programming in classrooms. More than a decade after it was first approached about them, it's unclear what Apple's alternative is. Hollowing out school budgets to buy Cupertino's high-end devices to run unsafe, privacy-invading native apps?

Apple have included Web USB on the list of APIs they “decline to implement” and quite belatedly issued a “standards position” opposing the design. But no alternative proposal was developed or linked from those threads, despite being asked directly if there might be more palatable alternatives.

I can locate no appetite from Apple's standards engineers to address these use-cases, know of no enquiries into data about our experiences shipping them, and can find no constructive counterproposals. Which raises the obvious question: if Apple does engage to develop counterproposals in tricky areas, how long are counterparties meant to wait? More than eight years?

Like Web USB, Web Bluetooth was designed from the ground-up with safety in mind and, as a result, has been incredibly safe and deployed at massive scale for eight years. It relies on the same chooser model in Chromium-based browsers.

Prior to getting user consent, this PWA can't talk to any devices.

Pairing is only possible when users explicitly choose a device.

Once connected, data can only be sent over the safer GATT subset of the larger Bluetooth protocol.

As with all Project Fugu device APIs, Web Bluetooth was designed to reduce ambient risks — no access to Bluetooth Classic, available only on secure sites, and only in <iframe>s with explicit delegation, etc. — and to give implementers flexibility about the UIs they present to maximise trust and minimise risk. This included intentionally designing flexibility for restricting access based on context; e.g., only from installed PWAs, if a vendor chooses that.

The parallels with Web USB continue on the standards track. I can locate no engagement from any @apple.com or @webkit.org email addresses on the public-web-bluetooth mailing list. In contrast, when design work began in 2014 and every browser vendor was invited to participate, Mozilla engaged. I can find no evidence of similar openness on the part of Apple, nor constructive counter-proposals.

Over more than three years of design and gestation in public, including very public Origin Trials, Apple did not provide constructive feedback, develop counter-proposals, or offer to engage in any other way I can find.

This appears to be a pattern.

From a deep read of the “standards position” threads for designs Apple opposes, I cannot find evidence that Cupertino has ever offered a constructive counter-proposal for any API it disfavours.

These threads do demonstrate downplaying clearly phrased developer needs, rather than proactive engagement, and it seems the pattern is that parties must beg Apple to belatedly form an opinion. When there is push-back, often after years of radio silence, requesters (not Apple) also have to invent potential alternatives, which Apple may leave hanging without engagement for years.

Worse, there are performative expressions of disinterest which Apple's standards engineers know are in bad-faith. An implementer withholding engagement from a group, then claiming a lack of implementer engagement in that same venue as a reason not to support a design, is the sort of self-serving, disingenuous circularity worthy of disdain.

Perhaps both the general trends and these specific high-profile examples are aberrant. Perhaps Apple's modus operandi isn't to:

  • Ignore new incubations, even when explicitly asked to participate.
  • Fail to register concerns early and collaboratively, where open design processes could address them.
  • Force web developers and other implementers to request “positions” at the end of the design process because Apple's disengagement makes it challenging to understand Cupertino's level of support (or antipathy).

Mayhaps it's not simply the predicable result of paltry re-investments in the web by a firm that takes eye watering sums from it.

Committers to Blink, V8, WebKit, and JSC by affiliation. Green is Apple, blue is Google, tan is Igalia, and brown is Microsoft.
Committers to Blink, V8, WebKit, and JSC by affiliation. Green is Apple, blue is Google, tan is Igalia, and brown is Microsoft.

The true scale of the funding gap becomes clearer as more projects are included. Here we add WebRTC and Web Platform Tests, both of which are shared between browsers and take contributions from many engines.
The true scale of the funding gap becomes clearer as more projects are included. Here we add WebRTC and Web Platform Tests, both of which are shared between browsers and take contributions from many engines.

If so, I would welcome evidence to that effect. But the burden of proof no longer rests with me.8

It's hard to say why some folks are under the impression that Apple are generous co-designers, or believe Apple's evocative statements about hard-case features are grounded in analysis or evidence. We can only guess at motive.

The most generous case I can construct is that Apple's own privacy and security failures in native apps have scared it away, and that spreading FUD is cover for those sins. The more likely reality is that upper management fears PWAs and wants to keep them from threatening the App Store with safe alternatives that don't require paying Apple's vig.

Whatever the cause, the data does not support the idea that Apple visibly engages in constructive critique or counter-proposal in these areas.

Moreover, it shows that many of Apple's objections and delays were unprincipled. It should be every browser's right to control the features it enables, and Cupertino is entirely within those rights to avoid shipping features in Safari. But the huge number of recent “catch-up” features tells a story that aligns more with covering for embarrassing oversights, rather than holding a line on quality, privacy, or security.

On the upside, this suggests that if and when web developers press hard for capabilities that have been safe on other platforms, Cupertino will relent or be regulated into doing so. It scarcely has a choice while simultaneously skimming billions from the web and making arguments like these to regulators (PDF, p35):

Apple is arguing to regulators that the App Store faces plenty of competition, including from web apps. The very same web apps it continually hamstrings, deprives of features, and does not demonstrably engage to improve.
Apple is arguing to regulators that the App Store faces plenty of competition, including from web apps. The very same web apps it continually hamstrings, deprives of features, and does not demonstrably engage to improve.

The moment iPhone users around the world can install high-quality browsers, the conversational temperature about missing features and reliability will drop considerably. Until then, it remains important that Apple bear responsibility for the problems Apple is causing not only for Apple, but for us all.

FOOTNOTES

  1. My various roles since the Blink fork have included:

    In my role as TAG member, Fizz/Fugu TL, and API OWNER I've designed, reviewed, or provided input on dozens of web APIs. All of this work has been collaborative, but these positions have given me a nearly unique perch from to observe the ebb and flow of new designs from, particularly on the "spicy" end of the spectrum. ⇐

  2. Apple has many options for returning voluntarity to the market for iOS browsers.

    Most obviously, Apple can simply allow secure browsers to use their own engines. There is no debate that this is possible, that competitors generally do a better job regarding security than Apple, and that competitors would avail themselves of these freedoms if allowed.

    But Apple has not allowed them.

    Open Web Advocacy has exhaustively documented the land mines that Apple has strewn in front of competitors that have the temerity to attempt to bring their own engines to EU users. Apple's choice to geofence engine choice to the EU, indefensible implementation roadblocks, poison-pill distribution terms, and the continued prevarications and falsehoods offered in their defence, are choices that Apple is affirmatively and continually making.

    Less effectively, Apple could provide runtime flags for other browsers to enable features in the engine which Apple itself does not use in Safari. Paired with a commitment to implement features in this way on a short timeline after they are launched in other engines on other OSes, competing vendors could risk their own brands without Apple relenting on its single-implementer demands. This option has been available to Apple since the introduction of competing browsers in the App Store. As I have argued elsewhere, near-simultaneous introduction of features is the minimum developers should expect of a firm that skims something like $19BN/yr in profits from the web (a ~95% profit rate, versus current outlays on Safari and WebKit).

    Lastly, Apple could simply forbid browsers and web content on iOS. This policy would neatly resolve the entire problem. Removing Safari, along with every other iOS browser, is intellectually and competitively defensible as it removes the “special boy” nature of Safari and WebKit. This would also rid Apple of the ethical stain of continuing to string developers and competitors along within standards venues when it is demonstrably an enemy of those processes. ⇐

  3. Apple regularly goes it alone when it is convinced about a design. We have seen this in areas as diverse as touch events, notch CSS, web payments, "liquid glass" effects, and much else. It is not credible to assume that Apple will only ship APIs that have an official seal of an SDO given Cupertino's rich track record of launch-and-pray web APIs over the years. ⇐

  4. In fairness to Apple regarding a "standards position" for Web MIDI, the feature predates Apple's process. But this brings up the origin of the system.

    Why does this repository exist? Shouldn't it be rather obvious what other implementers think of that feature, assuming they are engaged in co-design?

    Yes, but that assumes engagement.

    Just after the Blink fork, a series of incidents took place in which Chromium engineers extrapolated from vaguely positive-sounding feedback in standards meetings when asked about other vendor's positions as part of the Blink Launch Process. This feedback was not a commitment from Apple (or anyone else) to implement, and various WebKit leaders objected to the charachterisations. As a way to avoid over-reading tea leaves in the absence of more fullsome co-design, the "standards position" process was erected in WebKit (and Gecko) so that Chromium developers could solicit "official" positions in the many instances where they were leading on design, in lieu of clearer (tho long invited) engagement.

    If this does not sound like it augurs well for assertions that Apple engages to help shape designs in a timely way...well, you might very well think that. I couldn't possibly comment. ⇐

  5. There may have been Formal Objections (as defined by the W3C process) in private communications, but Member Confidentiality at the W3C precludes me from saying either way. If Apple did object in this way, it will have to provide evidence of that objection for the public record, as I cannot. ⇐

  6. Apple's various objections to powerful features have never tried to square the obvious circle: why are camera and microphone access (via getUserMedia()) OK, but MIDI et. al are not? What evidence supports the notion that adding chooser-based UIs will lead to pervasive privacy issues that cannot be addressed through mechanisms like those Apple is happy to adopt for Geolocation? Why, despite their horrendous track records, are native apps the better alternative? ⇐

  7. Mozilla objected to Web MIDI on various grounds over the years, and after getting utterly roasted by its own users over failing to support the API, shipped support in Firefox 108 (Dec '22).

    The larger question of Mozilla's relationship to device APIs was a winding road. It eventually culminated (for me) in a long discussion at a TAG meeting in Stockholm with EKR of TLS and Mozilla fame.

    By 2016, Mozilla was licking its wounds from the failure of Firefox OS and retrenching around a less expansive vision of the future of the web. Long gone were the aspirations for "WebAPIs". Just a few short years earlier, Mozilla would have engaged (if not agreed) about work in this space, but an overwhelming tenor of conservativism and desktop-centricity radiated from Mozilla by the time of this overlapping IETF/W3C meeting.

    It didn't make the notes, but my personal recollection of how we left things late in the afternoon in Stockholm was EKR claiming that bandwidth for security reviews was the biggest blocker that and that it was fine if we (Chromium) went ahead with these sorts of designs to prove they wouldn't blow up the world. Only then would Mozilla perhaps consider versions of them.

    True to his word, Mozilla eventually shipped Web MIDI on EKR's watch. If past is prologue, we'll only need to wait another three to five years before Web Bluetooth et al. join them. ⇐

  8. My memory is famously faulty, and I have been engaged in a long-running battle with Apple's legal folks relating to the suppression of browser choice on iOS. All of that colours my vision, and so here I have tried to disabuse myself of less generous notions by consulting public evidence to support Apple's case.

    From what I was able to gather over many hours was overwhelmingly inculpatory. It is not possible from reading these threads and data points — rather relying on my own recollections — to sustain a belief that Apple have either provided timely constructive feedback on tricky APIs, or worked to solve the problems they address. But I am, in the end, heavily biased.

    If my conclusions or evidence are wrong, I would very much appreciate corrections; my inbox and DMs are open.

    If reliable evidence is provided, I will update this blog post to include it, and I encourage others to post on this topic in opposition to my conclusions. It should not be hard for Apple to make the case, assuming there is evidence to support it, that I've missed important facts. It would have both regulatory and persuasive valence regarding questions I have raised relating to Apple's footprint in the internet standards community. ⇐

Web Standards and the Fall of the House of Iamus

Infrequently Noted

Photo by Photo by Artan Sadiku
Photo by Photo by Artan Sadiku

Commentary about browsers and the features they support is sometimes pejorative towards pre-standardisation features. Given Apple's constriction of Mozilla's revenue stream and its own strategic under-funding of WebKit, this usually takes the form "Chromium just ships whatever it wants."

This is true, of course, but not in the way commenters intend; and not only because Blink's rigorous launch process frequently prevents unvalidated designs from shipping.

Except for iOS, where Apple attempts to hide its role in undermining the competitive foundation of web standards, every vendor always ships "whatever it wants." That is the point of voluntary standards, and competition is the wind in those sails.

Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. There are no seers; no Delphic oracles that fleetingly glimpse a true logos. Working Groups do not invent the future, nor do they hand down revealed truths like prophets of the House of Iamus.

In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread.

In the end, this is the role of standards and the Working Groups that develop them: to license patents that read on existing designs, reducing risks to implementers who adopt them.

Anyone who tries to convince you otherwise, or invites you to try your hand at invention within a chartered Working Group, does not understand what those groups are designed to do. Sadly, this includes some folks who spend a lot of time in them.

Complaints about certain engines leading reveals a bias to fighting the last-war; fear of a return to the late 90s, when “irrational exuberance” applied not just to internet stocks, but also browser engines.

Unfounded optimism about our ability to deal with externalities of shipping prior to consensus created a great deal of pain. Misreadings of how browsers evolve in practice over-taught lessons that still invoke fear. But we have enough miles on the tires to see that standards aren't what create responsible feature development; thoughtful launch processes are.1

As we will see, consensus is never a precondition for shipping, nor could it be. If it were, nothing would move forward, for it is the threat (and sometimes reality) of popular features shipping without a priori agreement that brings parties to the table. It's also the only reliable defence against the fifth column problem.

Before we get into the role of the charters that define Standards Development Organisation (SDO) Working Groups, we must define some terms:2

Proposal
Any design, in any sort of document (Specification, Explainer, or scrawl on the back of a napkin) offered inside an SDO for standardisation. Proposals are revised through collaborative processes which function best inside SDOs thanks to carve-outs in competition laws allowing competitors to collaborate in writing standards.
Proposals are implemented, and even shipped, well ahead of formal status as Web Standards in order to gain developer feedback, iterate on designs, and build confidence that they meet needs effectively.3
Specification
A document that describes the properties of an implementation, often in technical shorthand (e.g., Web IDL) and with reference to other specifications.
Specifications are by and for implementers, rather than working web developers, and are the documents to which the IPR commitments of Web Standards attach.
Explainer
An overview of a proposal. Explainers are not specifications, but encapsulate the key points of designs in terms of the problems they solve.4 The goal is to explain the why along with the what, in terms web developers can weigh.
In well-incubated designs, Explainers evolve in parallel to specifications. This forces API designers to think like web developers. Explainers serve as foci for considering alternatives and as well as “missing manuals” for early designs.
Web Standard
A specification that has been put forward by a chartered Working Group to the full membership, and granted official status after ratification. For example, by receiving the status as a Recommendation of the W3C by a vote of the Advisory Committee, or in the case of ECMA TC39, publication of an International Standard at ISO.
Web standards create clarity around IPR concerns which pre-standards specifications cannot. These commitments license the patents of parties participating in a Working Group under Royalty Free terms.
In practice, this also commits major firms to the defence of potential implementers, reducing risks across the ecosystem.
Standards Track
A specification document is "on the standards track" if its developers have signalled interest in formal, chartered Working Groups taking up their design for publication as a Web Standard, subject to clarification along the way. It is not necessary for any specific Working Group to agree for this description to hold.
Designs in this state often carry IPR grants, but provide less patent clarity ("contribution only") than official Web Standards.
Incubation
Any process outside a chartered Working Group in which web developers, browser vendors, and other interested parties meet to understand problems and design solutions. Drafts of incubated designs are often volatile. Eventually, if a problem is judged important by participants, one or more designs congeal into brief, high-level "Explainers".
Before features launch without flags in stable-channel browsers, developer and implementer feedback can lead to large changes in incubated designs. Designers and participants must actively solicit input and respond to substantive feedback constructively.

Proposals whose specifications receive formal status within SDOs are described as “adopted”, “recommended”, or “ratified”. This process binds the intellectual property of chartered Working Group participants to the licensing regime of the SDO by approval of the membership.

From this we can see that is nonsensical to discuss “proposals” and "standards" in the same breath. They are a binary pair. A specification has either one status or the other; it cannot be both.

No design that becomes a standard can start as anything but a proposal,5 and the liminal space of non-standard proposal is not somehow less-than or an aberration. Rather, it is an embryonic stage every design must pass through, and which every de jure Web Standard has taken at some point.

Armed with better language, we can develop an understanding of how features actually come to the web. Through this, we'll see why our optimism for standards has to come from our own powers of collaborative problem-solving, rather than waiting for designs to be handed down from Olympus.

Jake Archibald pointed out that linguistic precision is uncommon, and developers use the phrase “standard” or “web standard” loosely; a shorthand for features they can use without worry. That ground covers both official Web Standards and de facto standards. The example of WebP was raised, and was even more instructive than I recalled.6

A brief refresher: WebP was introduced by Google in 2010, shipping in Chromium in 2011. At that point, and for many years thereafter, WebP was not a standard. A high-level specification broke cover in 2012, but was not brought to an SDO. Patent rights and other IP questions were addressed only by Google's waiver and the Open Source licensing of libwebp.

Nearly all Chromium-based browsers adopted WebP by 2012. Microsoft Edge added support in 2018, Firefox joined the party in 2019, and Safari added support in 2020.

It was not until April 2021, a full decade after the format's introduction and after all major engines supported it, that WebP arrived at the IETF for standardisation. It finally earned RFC status in November 2024, four years after Apple unlocked wide compatibility, having been the last hold-out.

WebP gained tremendous adoption despite not being a standard for nearly 15 years. This has led some to suggest it was a Web Standard, as it had many of the properties expected of successful standards. Namely:

  • Broad adoption. All major engines gained support before standardisation began in earnest.
  • Stability. Despite adding opacity and animation later, every WebP image produced across the life of the format still renders correctly.
  • Interoperability. The same WebP images work across implementations.
  • IPR clarity. As the primary contributor to the format and reference implementation, Google's substantial legal and patent assets provided adopters with assurances related to the provenance of both the code and the codec fundamentals.

Many assume that Web Standards are the only path to achieving these attributes, but WebP shows us that this is mistaken. Web Standards deliver these properties most effectively and reliably, but WebP shows us that “being a standard” is not a requirement for interoperable implementation at scale, even in browsers.

Interoperability and adoption are, by inspection, independent of official status. Many formal Web Standards have spotty adoption or fail to achieve interoperability. The web also has a long history of de facto behaviours gaining official status long after interoperability and stability manifest in the market. This sits comfortably with the reality that every single web feature is non-standard for some fraction of its lifetime. At the limit, that fraction can be rather large.

Conflation of de facto standards, official Web Standards, wide deployment, and interoperability are likely to persist. However, those of us who work on browsers can and should be more precise, preferring “interoperability”, “widely deployed”, and “standards track” to “Web Standard” when those are more appropriate.

If we admit, as we must, that all features begin as non-standard proposals which proceed through official processes to become Web Standards, quality is never as simple as “standard good, non-standard bad.” A design can pass unaltered through every lifecycle stage without change to its technical shape or merits, and questions of wide implementation and interoperability are clearly extrinsic to the status of a design within an SDO.

We must locate definitions of relative goodness in more directly descriptive properties. I have given a few above, namely adoption, stability, interoperability, and IPR clarity. For a full account, we need to cover design-time attributes, including testability, specification rigour, wide review, and responsiveness to developer feedback . Taken together, they define what it means to solve important problems well on the standards track.

Developers and implementers weigh up these properties when judging APIs. Some designs, like WebP,7 can score highly on everything but adoption. WebP was not technically worse in 2015 than in 2019, or 2020, or 2024; only less widely adopted. Working web developers were free to exploit its benefits the whole time. Many did, and because it had been responsibly developed, interoperability followed, even before a proposal had been submitted to an internet standards body.

Likewise, we cannot judge other APIs shipped in a single engine to be low-quality on the basis of SDO status. Nor can we credit statements opposing them on that basis, particularly from parties that have not offered counterproposals. A single implementation may preclude features from becoming standards, but that says nothing about design fitness, or even prospects for eventual adoption.

This understanding draws our focus away from formal SDO status and toward more important properties of features. It also helps us weigh up the processes that gestate them:

  • Are they friendly and open to developers, or are they smoke-filled rooms where old-timers hold sway?
  • Do they encourage new work at the pace of emerging developer needs, or are they artificially constricted by a proliferation of veto players?
  • Do those processes generate good tests and strong specifications, or do a few powerful editors regularly cut corners?
  • Are features submitted for wide review to competent and responsive experts, or is Working Group "go fever" allowed to dominate?
  • Do processes put evidence of solving end-user and developer problems8 ahead of groupthink and reckons?
  • Do those processes allow high-quality features to ship ahead of full consensus, based on evidence?
  • Do they adequately protect implementers from IPR risks?

These questions do not line up clearly with corporate jerseys. They do not favour one company's designs over another's. Google, Microsoft, Apple, and Mozilla all have fielded designs that easily pass these tests, and others that flunked. That's the thing about quality; metrics don't care about status or affiliation. Quality doesn't have a “team”, it has units of measure.

Quality tests help us evaluate features in the market-based ecosystem of voluntary standards. The presumed working mode of Web SDOs is that many ideas will be tried (responsibly, hopefully) and the best ideas should gain traction. Eventually, better designs sway the market, leading to calls for standardisation.9 Competitors who objected, even strenuously, can then adopt liberally-licensed designs, provide alternatives, or lose share. This logic does not designate grandees or smoke-filled rooms as arbiters of quality. Instead, we rely on voluntary adoption, the testable qualities of shipped designs, and developers voting with their feet.

Responsible, quality-oriented feature development processes reject priesthoods, seers, and oracles, putting evidence-based engineering in their place. This focuses us on solving problems we can see, showing our work, inviting critique, and engaging constructively.

There were never curtains from behind which a feature's essential “standardness” could be revealed, and we should not invent them because the messier, egalitarian reality of feature evolution seems disquieting. Like “Best Picture”, formal SDO status isn't a reliable indicator of quality. Each must judge for themselves.

In the end, the wider internet engineering community always decides if problems are relevant and if designs are “correct.”

There are no blinding flashes of insight, only the push and pull of competing proposals to solve user and developer needs. When standards fail to meet needs, developers patch over the gaps at great cost, or route around standards-based platforms altogether. It is no coincidence that the phases of the Blink Launch Process and tools like Origin Trials present practical steps away from Working Group mysticism. Moving, however haltingly, towards egalitarian, pluralistic collaboration has delivered tremendous progress, despite recalcitrant participants.10

Along with other experienced colleagues at Google and Microsoft, I have had the privilege to teach the practice and theory of standards-track feature development to talented engineers working inside Chromium.

The role of chartered Working Groups looms large in those conversations, but it is far from central. This is because the primary job of a Working Group is to accelerate adoption of existing designs that have enough support to move forward and insulate them from IPR-based attacks. This is both their official job (per SDO process documents) and their primary value.

“I” dotting and “t” crossing is expected, and it can slightly alter designs, but chartered Working Groups never work well as venues for effectively canvassing developers for problems to solve. Nor are they good environments for testing ideas. If the goal is to solve new problems or design new solutions, chartered Working Groups are never the best forum for the simple reason that it is not what they are built to do.

Consider the most recent charters from a few lively W3C Working Groups:

Per the formal process governing charters, each group's convening document contains several sections that outline:

  • A problem statement, laid out at the group's (re)charter.
  • An explicit scope; i.e., technologies the group can consider in addressing that problem.
  • An a priori list of documents and deliverables the WG will produce.

Everything in these charters works to provide clarity and precision about what the group will deliver because that is how members (firms, in the W3C's case) weigh up the costs and benefits of joining relative to their patent portfolios.

Yes, it's all about patents. Standards Development Organisations are, practically speaking, IPR clearing houses. From this perspective, all the hoops one must jump through to join a chartered group make sense:

  • Q: Why do companies have to officially join each Working Group separately?

    A: Patents.

  • Q: Why does each participant need to be approved by a company's main W3C delegate?

    A: Patents.

  • Q: Why are there so many checkpoints in the process that appear to do little more than waste time?

    A: Patents.

  • Q: Why does the whole membership need to vote to progress a document to a formal standard?

    A: Patents.

Features named in Working Group charters are the only designs a group can standardise, and groups run into trouble with lawyers when they exceed charter scopes, because participating firms may not have done a search in their portfolio (or their competitor's) regarding designs outside the pre-determined scope. When this happens, all progress can halt for an indeterminate amount of time. SDO processes and documents, therefore, work to cabin the risk, moving early design out of Working Groups and into other venues.

All of this drives to a simple set of obvious conclusions: venues other than chartered Working Groups are necessary in order to do the sort of high-iteration-pace design work that leads to higher-quality designs.

It's a punchline that standards committees are bad at design, but this is by design. They do not have the cycles, mission, or tools needed to explore developer problems, let alone iterate towards compelling solutions. Their job, per the official process documents that convene them, is to ensure that certain quality attributes are tended to (e.g., tests and complete specifications) on the way towards licensing of the intellectual property embodied in specifications.

To this end, internet SDOs have many alternatives that are better suited to design work, and which create glide paths for the fittest proposals into chartered Working Groups to gain eventual status as Web Standards. Here are a few:11

It's always possible for designs to fail to solve important problems, or fail to solve them well, and better designs flow naturally from a higher pace of iteration and feedback. Incubation venues tend to work better for design because they lower some strictures Working Groups erect to create patent clarity. Instead of needing to pre-define their deliverables, these groups can fail fast and iterate. When they work, they can be submitted to Working Groups to get patent and IP issues finalised.

Incubation venues display very different working modes and membership than formal Working Groups. Instead of pre-decided, formal deliverables, groups can form around nebulous problem statements and define the issues long before landing on a single design. There is no stable set of delegates from member firms, largely dominated by implementers. Rather, interest groups may form organically, even from web developers interested in shared problems. Instead of predefined timelines and pre-ordained deliverables, these groups work at the speed of their need and understanding. And instead of design pivots representing potential failure, incubation venues can test multiple alternatives. Discarding entire designs is even healthy while the furious iteration of incubation plays out.

Lower barriers to entry for web developers, along with structures that encourage dynamic problem-solving coalitions, tend to create higher pace and more focused work. This, in turn, allows consideration of more alternatives and helps facilitate the iterations that hone design. Not every Incubation venue succeeds, and not every design they consider wins. But their outsized success vs. design-in-committee approaches has been apparent for more than a decade.

Only those mistakenly wedded to, or cynically selling, mystical notions of Working Groups as diviners of revealed truth try to rubbish the web's incubation venue's outstanding track record of delivery. Given the overwhelming success of incubation, including the demonstrated benefits of fail-fast iteration, we must then ask why there are still proponents of Working Group misuse and process opacity.

Splitting the needs of design from the strictures of standardisation isn't against the spirit of standardisation, nor is shipping ahead of a vote by the full membership of an SDO problematic. These approaches are written into the process documents of the internet's most effective bodies. Implementation experience is required for a proposal to become a ratified standard, and Working Groups are enjoined by process from undertaking the explorations incubation venues specialise in. Which is why those same SDOs build and encourage incubation groups.

This is an uncomfortable acknowledgement for some.

Folks I have talked to seem to imagine rooms filled with people who know everything and always make correct decisions. There are no such rooms. We're all just engineers trying to solve problems, from the heights of the TAG and the Internet Architecture Board to the scrappiest W3C Community Group or IETF Bar BOF. And sometimes we get it very wrong. But that should not immobilise us in fear; it should cause us to do what we always do when engineering: adopt processes and guardrails to improve quality and increase the rate of delivery.

Problems only get solved by people of good cheer working hard to spot them,12 trying out solutions, and working collaboratively to document the ones that work best. There are no oracles in standards work, only engineers. And that's more than enough.

FOOTNOTES

  1. While the Blink Launch Process raised the bar in some ways for every project, many parts of Blink's risk-based logic for feature leadership still lack analogues for tools like Origin Trials in other projects. Over the past decade, this has generally not been a major problem because other projects rarely lead (sadly). ⇐

  2. And, it would seem, long-time browser engineers and standards participants. ⇐

  3. The IETF famously phrases this principal as "rough consensus and running code", which indicates that that formal status as an official standard should be reserved for designs with experience in the market.

    A frustrating fraction of the web's erstwhile friends twist the arrow of causality, demanding formal standards status before they (or anyone else) dare to ship a proposal. This is, of course, entirely backwards, but sounds convincing to web developers who desire interoperability which comes from uniform implementation status which, historically, correlates with de jure status.

    This rhetorical bait-and-switch is deployed very frequently by fifth columnists. ⇐

  4. Most contemporary web standards explainers use a template derived from a document I authored for use by Google's Web Standards engineers, and which was adopted by the W3C's Technical Architecture Group during my service there.

    The current template has drifted from the original somewhat, but the initial intent is in tact: to favour the perspective of working developers over implementers when weighing up potential designs.

    This explicit goal is realised through many steps of the Blink Launch Process. It's that process which forces Blink engineers to request TAG design review for new features. This combines with the reality that most new web features begin life within Chromium and Blink's “coalition of the willing”. As a result, designers of important new features experience Blink's process guardrails as the most constricting influence on quality as they work towards shipping. And one of those guardrails is to explain features in terms that web developers can understand via Explainers.

    As a sociotechnical system, the Blink Launch Process, and its integrations with the TAG and various incubation bodies, are calculated to act in a Popperian mode, rejecting claims to design authority and oracular Working Group pronouncements. In their place, we explicitly delegate power to groups that have done a good job of representing wider constituencies. The goal is to place the key question "does this design solve an important problem well?" at the centre of feature development, and to trust users (web developers) as judge of the results.

    We reject both essentialist and inductive intuitions about where features “should” come from, and instead require designers walk a mile in the shoes of their users. This is easiest to do in incubation venues like the WICG, where the barriers to bringing web developers into the conversation are lowest.

    This also is why the Blink API OWNERS expect “Considered Alternatives” sections of explainers to be exhaustive, and that examples appear the languages developers use (HTML, CSS, and JS), not the languages implementers think in (WebIDL and C++). Domain experts may understand the system, by sympathy for the machine is not a substitute for web developers trying designs and rendering their own judgement. The Blink Launch Process guards against go fever while enabling feature designers to launch responsibly, even when forced to go first by the disinterest of other vendors in solving problems. ⇐

  5. Even if a proposal is, for some blighted reason, floated first within a chartered Working Group, it is still only that: a proposal without any standing as a standard. It is only upon publication of a formal standard document months or years later that a proposal, encoded in a specification, can be called a Web Standard and carry any of the attendant IP protections.

    That necessarily happens after the proposal has been offered, and generally happens months or years after all design work has completed and multiple interoperable implementations are fielded. ⇐

  6. Until prompted to consider it, I had not been aware that WebP had made the transition to a formal standard in any venue. ⇐

  7. It would, obviously, have been better for WebP to be floated at IETF many years prior, but adoption in every major engine occurred before that process began. ⇐

  8. In that order, always. ⇐

  9. In reality, new web features are a thinly traded market, and long experience (e.g., CSS's “prefixpocalypse") has taught the web community that uncontrolled experiments are disruptive and costly. This lesson has, in my view, been heavily over-sold.

    Responsible approaches (e.g., Origin Trials) now have a long track record of success. Those who argue that we must sort out differences in perspective exclusively by thinking hard about designs within the teleconferences of chartered Working Groups have not demonstrated that their approach is superior in any way that I can see. Simply trying ideas and gathering developer feedback has, despite tremendous resistance from Apple, generated a many important and high-quality features over the past decade using this model.

    Had we waited for Working Groups to recover from stupors induced by fifth columnist's disinterest, the quality of the resulting designs would not have improved substantially. Nor, in my estimation, would they be more likely to eventually achieve status as ratified and widely adopted Web Standards.

    There will always be a role for chartered Working Groups to improve on extant designs, but we have falsified the thesis that it is necessary for design to happen within them. The positive qualities of successful features are not down to venue, but the constituencies involved, and the evidence used to evolve them. That developer involvement and vendor flexibility towards feedback overlapped with Working Group-centered design efforts at certain moments in the past gives rise to much confusion. New entrants, thankfully, can skip old muddles and move straight to beginning their work in more entrepreneurial, high-iteration-rate venues built for incubation. ⇐

  10. Many big, old chartered Working Groups attract participants who are earnestly confused about the value of their own contributions or the correct scope of the group's activities. Luckily, it is not necessary to convince them that they should not have outsized power in these domains. Instead, we only need to route around by moving early design work to incubation venues that enable more productive and egalitarian practices.

    There is little that hard-done-by WG delegates can do when this happens, other than to muddy the waters about what the best order of operations is. They cannot prevent design work from decamping to more fertile ground because it is in full alignment with the roles assigned to Working Groups and their feeder venues by the formal processes that govern SDOs.

    Design work should never have been on their docket, and it is always illegitimate Working Groups to attempt to monopolise it. Their charters make this extremely clear. ⇐

  11. The WHATWG is unique among internet SDOs in disavowing any sort of incubation or early design process, which largely serves to make the W3C's various appendages (particularly the WICG) more useful and vibrant. ⇐

  12. Taking developers seriously and not being dismissive about the needs they express is the first step in this work. It is therefore extremely problematic when implementers gaslight developers or claim the needs they are taking time to express are somehow illegitimate.

    There are many cases where an SDO or Working Group can't, or shouldn't, work to solve certain problems. But we can engage those questions without being dismissive, and should show our work along the way. Vendors who make a habit of brushing off developers, therefore, bring disrepute to the whole goal of standards work. ⇐

Apple's Assault on Standards

Infrequently Noted

Internet enthusiasts of the previous century sometimes expressed the power of code by declaring the sovereignty of cyberspace, or that "code is law."

As odd as these claims sound today, they hit a deep truth: end-users, and even governments, lack power to re-litigate choices embodied in software. Software vendors, therefore, have power. Backed by deeply embedded control chokepoints, and without a proportional response from other interests, this control is akin to state power.

Both fear and fervour about these properties developed against a backdrop of libertarian1 attitudes toward regulation and competition. Attenuating vendor power through interoperability was, among other values, a shared foundation of collaboration for internet pioneers.

The most fervent commitment of this strain was faith in markets to sort out information distribution problems through pricing signals,2 and that view became embedded deeply into the internet's governance mechanisms.3 If competition does not function, neither do standards.

The internet's most consequential designs took competitive markets as granted. Many participants believed hardware and software markets would (and should) continue to decouple; that it would be easier for end-users to bring their own software to devices they owned. It is odd from the perspective of 2025 to suggest that swapping browsers, e.g., should come at the cost of replacing hardware. This is why Apple have worked so hard to obscure that this is exactly the situation it has engineered, to the detriment of users, the web, and internet standards.

Internet standards bodies assumed the properties of open operating systems and low-cost software replacement to such an extent that their founding documents scarcely bother to mention them.4 Only later did statements of shared values see fit to make the subtext clear.

And it has worked. Internet standards have facilitated interoperability that have blunted lock-in, outsized pricing power, and monopolistic abuses. This role is the entire point of standards at a societal level, and the primary reason that competition law carves out space for competitors to collaborate in developing them.5

But this is not purely an economic project. Standards attenuate the power of firms that might seek to arrogate code's privileges. Functional interoperability enables competition, reallocating power to users. Standardisation is therefore, at least partially a political project; one that aligns with the values of open societies:

We must ask whether ... we should not prepare for the worst leaders, and hope for the best. But this leads to a new approach to the problem of politics, for it forces us to replace the question: "Who should rule?" by the new question: "How can we so organize political institutions that bad or incompetent rulers can be prevented from doing too much damage?"

— Karl Popper,
"The Open Society and Its Enemies"

Without a counterweight, network effects allow successful tech firms to concentrate wealth and political influence. This power allows them to degrade potential competitive challenges, enabling rent extraction for services that would otherwise be commodities. This mechanism operates through (often legalised) corruption of judicial, regulatory, and electoral systems. When left to fester, it corrodes democracy itself.6

Apple has deftly used a false cloak of security and privacy to move the internet, and web in particular, toward enclosure and irrelevance. This post makes the case for why Apple should be considered a corrupted, and indeed incompetent, autocrat in our digital lives. It abuses a unique form of monopoly to extract rents, including on the last remnants of open ecosystems it tolerates.

Worse, Apple's centralisation through the App Store entrenches the positions of peer big tech firms, harming the prospects of competitors in turn. Apple have been, over the course of many years, poisonous to internet standards and the moral commitments of that grand project.7

Despite near continuous horse-race coverage in the tech press, the consequences of this regression in civic/technical affairs is not well socialised.

Standardisation expands the reach of interoperable technology, pushing firms to innovate, rather than extracting rents on commodities.

Interoperability-in-being gives users choice, forcing competitors to differentiate on quality and not-yet-standard features. Standards expedite interoperability by lowering the costs for implementers and reducing tails risks, e.g. from patent trolls. Over time, a complete enough set of standards can attenuate the power of vendors to extract rents and prevent progress in important domains.

Interoperability is not the only mechanism that can reduce the power of dominant firms, but it is the most powerful. Free and Open Source software (FOSS) can provide a counterweight too, but OSS is not a full solution.8

Interoperability, and the economic surpluses that flow from it, are underpinned by voluntary adoption. This is enshrined in the "open stand" principles agreed to by no less than ISOC, IETF, IAB, IEEE, and the W3C.:

...

5. Voluntary Adoption

Standards are voluntarily adopted and success is determined by the market.

— The IAB, IEEE, IETF, ISOC, and W3C,
"The OpenStand Principles"

This final principle is the shortest, and many readers will understand it as a dodge; a way for Standards Development Organisations (SDOs) to avoid being seen to pick winners. But it is more than that.

Voluntary adoption is necessary for internet standards to function, and it creates a presumption of fair play.

Several implications bear mentioning.

First, the principle of voluntary adoption is necessary for effective standards development. Without a mechanism for determining which designs are better, we are unable to make consistent progress. That test never comes from within an SDO; it is always customer-defined. Writing a standard is not a test of quality, and without a functional market to test designs in, SDOs are irrelevant.

Second, this principle outlines a live-and-let-live doctrine, both within standards bodies and in the market. Participants may want their design to win, but are enjoined from procedural shenanigans to prevent competing designs from also being standardised.

Lastly, voluntary adoption marks customers (developers) and suppliers (browser vendors, etc.) as peers and creates norms of mutual respect within the walls of SDOs.

For all of these reasons, voluntary adoption must be defended, and actions taken to undermine it met with resistance and eventual sanction.

Regulators have had no difficulty in building market tests that demonstrate the power Apple holds in the lives of users.

Some of these tests have produced comical contortions as Apple has attempted to weasel out of its responsibilities. Consider the Trinitarian claim that Safari is simultaneously one product, and also three. Or that iPadOS, despite sharing nearly all code with iOS, marketed under that brand for years, supporting identical features, running the same third-party software, releasing on the same cadence, and running exclusively on the same hardware architecture is (somehow) an entirely different product.9

But for as clear and effective as regulator's tests have been in piercing these smoke screens, they do not capture the most important aspects of Apple's influence on the market for smartphone software: the monopoly on wealth.

Apple suppresses standards-based platforms and their disruptive potential through a mechanism every software developer understands: wealthy users carry iPhones, and they have all the influence.

Competition law does not explicitly recognise this distortion of the market, but the connection between the influence of the wealthy and the choices available to other end-users is indisputable.

Despite selling fewer than a quarter of smartphones globally for the past decade, Apple has built and anti-competitively maintained a supermonopoly among the wealthiest 10-20% of the world's population who, in turn, control effectively all wealth on the planet. This has handed it control over software distribution due to the social effects of wealth. Apple pairs legitimately superior product attributes (e.g., leading chip design) with anti-user and anticompetitive tactics — e.g., green vs. blue chat bubbles, suppression of browsers — to maintain this position.

Apple has put in place a set of interlocking restrictions to ensure the web cannot disrupt native apps within this user base. Those users, in turn, warp the behaviour of software developers thanks their spending power and positions within the software industry. Developers understand that if they cannot demo their wares to bosses and VCs (all of whom are wealthy) on their own devices, their software might as well not exist.

The long-stable propensity of users who make more than $100K USD/year to carry iPhones combines with Apple's suppression of browsers and PWA capabilities to ensure developers have no choice but to build native applications. These effects were visible in population-level statistics a decade ago and have been stable ever since:

Knowing whether someone owns an iPad in 2016 allows us to guess correctly whether the person is in the top or bottom income quartile 69 percent of the time. Across all years in our data, no individual brand is as predictive of being high-income as owning an Apple iPhone in 2016.

— Marianne Bertrand and Emir Kamenica,
"Coming Apart? Cultural Distances in the United States Over Time"

Developers are forced into the App Store by missing web capabilities, ensuring an advantage for Apple's proprietary ecosystem. This induces wealthy and influential users to default to the App Store for software, further damping the competitiveness of open platforms.

The monopoly on influence explains why Apple is wedded to legalistic, dissembling tactics in order to prevent the spread of web apps. Should the work of internet and web standards bodies ever become relevant, Cupertino understands the market for software will transform in ways it cannot control or tax.

Developers are forced into the App Store by a lack of functionality in browsers and web apps. By contrast, Apple has liberally meted out fingerprintable system capabilities to privacy-invading native apps. It has also allowed them to suppress pro-privacy interventions when it serves them.10

Apple professes that "privacy is a human right", but this as an attempt to turn the consequences of Apple's own largesse towards data abusers into a marketing asset. Wide-scale privacy erosion has depended, fundamentally, on Apple's own decisions, and it has not recanted.

It was Apple's choice to introduce less safe, less privacy-preserving native apps into iOS. It was also Apple's choice to deny competing browsers engines the freedom of voluntary feature adoption. This has ensured that important underlying capabilities could only ever be accessed through Apple's proprietary APIs, and only ever by those who are willing to agree to Cupertino's extractive terms.

The result has been API enclosure; appropriation of commodity capabilities that themselves are standards-based — e.g., rich graphics, USB, Bluetooth, NFC, file storage, etc. — by a proprietary ecosystem. Meanwhile, it has delayed and undermined the emergence of safe and privacy-preserving versions of those features on the web.

This, in turn, has created a winner-take-all dynamic inside the app store, harming privacy, security, and competition in the process.

This strategy relies on interlocking policies that harm competitors, and the sabotage of voluntary standards adoption lies at its heart. A Bill of Particulars for crimes against the internet community springs from a small set of undisputed facts.

Apple has:

  • Restricted competitors from shipping their own implementations of web and internet standards, depriving them access to influential users.

  • Forced all iOS browsers to use Apple's own defective, impoverished implementation.

  • Undermined user security and privacy through iOS browser engine monoculture.

  • Used contractual terms to dissuade competitors from supporting standards Apple disfavours.

  • Objected spuriously within standards bodies to prevent standardisation of features which Apple offered no counter-proposal.11

  • Engaged in marketing and product UI that discourages use of web-based alternatives.

  • Misled regulators and the public when presented with evidence of the harm from these actions.

Through these and other overt acts, Apple has worked to disempower users, depriving them of choice by preventing open platforms from challenging native apps.12

This isn't just a fierce market participant competing aggressively. Apple has done violence to the founding ethos of internet and web standards development. Instead of honourably withdrawing from those groups, Apple has maintained a charade of engagement, and gaslights other participants while actively sabotaging the principle of voluntary adoption that internet standards rely on.

Apple has never been forced to suppress its competitors, nor to create an anticompetitive landscape. Cupertino's senior management have intellectually consistent options that would allow it to pursue growth of the superior (we are told) native app ecosystem without threatening browser choice or the good functioning of internet standards.

Let's consider two: all safe browsers, and no browsers.

Apple could, of course, simply enable the same sort of level playing field for high-quality browsers that every competing general-purpose OS vendor has for the web's entire history. Apple itself facilitates this sort of ecosystem on macOS.13 Any plausible restrictions stemming from available system resources have long been overcome by progress in mobile hardware, particularly within Apple's ecosystem.14

The only reasonable restrictions on competing browser engines relate to security. As other vendors have generally had a better track records than Apple regarding sandboxing, incident response, patch gaps, and support for older OS versions, this should be no practical obstacle.

Lest Apple's defenders worry about the impact on Safari, recall that under true browser choice, Apple retains considerable market advantages, including (but not limited to) pre-installation, lower structural costs15, and continued differentiation through integration.16 Such bulwarks have allowed Safari to retain considerable share on macOS in spite of stiff competition and Safari's poor track record on security and standards conformance.

Alternatively, Apple could withdraw Safari while forbidding web content on iOS. This is a fully consistent position, and has been available to Apple from the moment of the App Store's release. The iPod did not include a browser, and many subsequent Apple OSes lack functional browsers. iOS and visionOS are uniquely deficient in this regard.17

Either way, the decision to undermine choice and standards rests entirely with Apple. It has always had intellectually honest solutions to the problems it has created. Apple cannot claim the situation is anyone else's fault, or that it has had no alternative.

It should be obvious that I do not consider Apple's failure to implement standards I personally approve of to rise to a level worthy of sanction.

Under voluntary implementation, every vendor is free to ship what they please, including Apple. It may be sad, or even damaging, when features go missing from important products, but that is not a calamity; it's simply an input to be priced by the market. This has traditionally been experienced as browsers gaining or losing share.

Is not enough to cite a lack of features, bungled implementations, peevish behaviour in working groups — or even rank dishonesty — as reason for censure. These are, to a greater or lesser degree, players playing the game within the rules. Certain tactics may be distasteful, but are squarely inside the "awful but lawful" zone. Standards venues should allow them, with sanctions for poor behaviour meted out in the social realm, if at all.

Apple's outrages against the community are more fundamental, and more dangerous.18

Some will see a parallel to the Paradox of Tolerance, and I do not believe this is mistaken. Standards bodies can, and should, admit many positions by their participants, but granting membership in good standing to parties who are actively uprooting the basis for standards is madness. It ensures that standards, and the ecosystems that depend on them, wither and die.

By subverting the voluntary nature of open standards, Apple has defanged them as tools for users against the totalising power of native apps in their digital lives. This high-modernist approach is antithetical to the foundational commitments of internet standards bodies and, over time, erode them.

Indeed, no other vendor has achieved what Apple has in the realm of anticompetitive suppression of the web. We must not imagine that Apple would stop at the Application layer given a chance. The same mechanism threatens voluntary feature adoption in every other layer of the stack, too.

The web and internet communities must understand the threat and the ongoing, cumulative harm done to the web and to internet standards. It seems to me that this point has hardly been engaged, let alone won, within the walls of SDOs. But if it were, then what? What can be done?

The founding documents of internet SDOs do not include censure mechanisms for sabotage. The W3C's bylaws, for example, only relate membership in good standing with paying dues. Regardless, it is possible — and I believe urgent — to do more.

First, proposals can be raised to amend bylaws to include mechanisms for censure by votes of the membership for the kinds of outrages alleged here. These are likely to fail, and will surely be rejected at first, but the act of raising these questions has power. Bringing up these issues in plenary meetings can, at a minimum, elicit a response. That, on its own, is valuable to the community.

Next, leadership boards with moral authority can consider the question and issue guidance. The W3C's Advisory Board and Technical Architecture Group and the IETF's Internet Architecture Board have the ear of the membership, even on non-technical topics, should they choose to weigh in on the side of their own continued relevance.

Most importantly, individual delegates to Working Groups can recognise that Apple's forced monoculture is illegitimate and corrosive. They can resolve not to accept "Apple does not comment on future products" in response to questions about implementation timelines.

As long as Cupertino demands a monopoly, we must demand it take responsibility for the consequences.

Today, Apple alone chooses which features ship in WebKit, and which can be used by competing browsers. Even if it does not to enable them in Safari, it can provide more to others. It is simply illegitimate for Apple to claim that it cannot, or should not, allow other vendors to reach feature parity between their iOS browsers and other products that use their own engines.

WebKit purports to be Open Source, but in practice Apple has used it to undermine the "bring your own code" foundation of OSS. It is illogical for Apple to cite a disinterest in a feature in Safari as a reason for Apple not to be expected to implement those features in iOS's WebKit binary, making them available for other embedders to flag on.

The sham of WebKit as an Open Source project is incompatible with preventing other vendors from introducing features they would turn on for their iOS users if allowed. The destruction of voluntary adoption is not a shield against critique. Instead, it must heighten expectations. Apple agues it should be singularly entrusted with control over all web features on iOS, despite Safari and WebKit's trailing record on standards' conformance, security, and even privacy. This is nonsense, but so long as it is the law of the land in code, Apple should bear the costs.

Apple alone must be on the hook to implement any and every web platform feature shipped by any and every other engine. It does not need to enable them in Safari, but must make them available for use by others as they see fit.

So long as competing vendors are forced into the App Store and required to use Apple's engine, Cupertino owes much more when it comes to completeness and quality. So long as Cupertino compels use of WebKit, the demand should be echoed back: parity with browser features on other Operating Systems is the minimum bar.

Fundamentally, the web and internet community must stop accepting the premise that Apple should benefit from the protections and privileges of voluntary feature adoption while denying it to others.19

Lastly, and perhaps most controversially, delegates and organisations can use their positions to vote against Apple's personnel in elections to leadership positions within internet and web SDOs. It is inconsistent for Apple to hold positions of influence in organisations it works to sabotage, and fellow participants are under no obligation to pretend otherwise. Hand Apple formal or persuasive power within these groups is a mistake, and one that can be corrected without changes to bylaws.

In raising these questions, colleagues have invariably asked "why now? What changed?"

Beyond the threshold point that the damage is cumulative, and therefore it isn't necessary to identify specific instances to discuss the spread rot, it's fair to ask why anyone should be agitated tomorrow when they might not have been yesterday.

Most of the factors involved have indeed changed very gradually, and humans are famously poor judges of slowly emergent threats. Apple's monopoly on influence, Cupertino's post-2009 WebKit priorities, the suppression of browser competitors, and the never-ending parade of showstopping bugs are all gradually emergent factors. Despite all of this long-running, unrefuted evidence, many continue to think of Apple an ally of the web for helpful acts now more than 15 years old.

But recent events must shake us awake. Apple's petulant attempt to duck regulations, destroy the web as a competitor for good, and frame regulators for the dirty deed was shocking. In recurring misrepresentations to regulators before and since, it has dissembled about its role in suppressing the web, and through its demand for secrecy in quasi-standards processes, has worked tirelessly to cover its tracks.

Taken individually, and in ignorance of iOS's coerced WebKit use by competing browsers, forced monoculture, habitual security failures, and strategic starvation of the Safari team, these shameful acts would simply indicate another monopolist behaving badly. It is only when considered alongside the wider set of facts that the anti-standards strategy and impact become clear.

Like most who have dedicated the greater proportion of their working lives to the cause of an open and interoperable web, the conclusions offered here shock me as well.

In the end, however, the question "do standards matter any more?" is intrusive, despite my aversion to reconsidering a question whose answer I thought obvious. But in light of the past decade's sidelining of the web, we must grapple with the consequences. To allow Apple to continue to abuse the foundation of standards without acknowledgement would be a failure of honesty towards my own intellectual commitments.

My personal affinity for the many talented and thoughtful people that Apple has sent to standards bodies over the years — including those I think of as friends — has, on reflection, been an emotional blind spot. But here we are. The realisation that they have been an unwitting fifth column against the web is nauseating for me, and I expect many will loudly reject the conclusion. I do not blame them.

For all the harm Apple has done to the web and to competition, I had hoped that it would relent before any of this became necessary. Like most web developers, I harboured hope that, true to Steve Job's promise in '07, Apple would let the web be a "sweet solution" for delivering safe, powerful applications. Piggybacked on that hope was a belief that a relevant mobile web would bolster the relevance of standards. But Cupertino has gone a different way, choosing profit over collaboration and the needs of users.

The web matters too much for the standards-based future it represents to fade without so much as a nod.

FOOTNOTES

  1. Or, if you like, "liberaltarian". ⇐

  2. A faith I do not share. Markets fail frequently, never mind that most goods are hardly substitutable, thinly traded, and lack reliable public prices. All of this means that the information capacity of markets a priori the rationalising effect of standards and market fairness regulation is heavily suspect.

    But even for those that take a market fundamentalist perspective, restrictions on trade such as Apple has imposed are offensive to the basic logic of the market's role in bettering society. Only those who would see markets subjugate all, forever, because of one-time power imbalances can be sanguine about what Apple has done.

    We do not have to grant pro-totalitarian about technology are in good faith given what we know about where unchecked power leads. ⇐

  3. It is not original to note that there is an inherent contradiction in the idea of liber(al)tarian participants in standards bodies collaborating through non-market mechanisms. We do not have to ignore it, however, or even treat those holding both an affinity to open standards and libertarian ideals as hypocrites, in order to accept that the development of standards is often a creative act of critique for which there is no other functional venue (or, if you like, "market").

    Proposals for open internet standards often begin as personal drafts of individual authors, working in a community of like-minded developers experiencing similar challenges and working to design solutions. These proposals are situated in a context that is often opaque to those outside narrow circles, and the communities that form around them trade in reputation as much as any other currency.

    In addition to personal status, there is a distinguishable ideology at work:

    The open systems ideology that was developed in computing between the 1970s and the 1990s embodied several assumptions articulated in previous open system visions in diplomacy, economics, philosophy, and engineering. These assumptions included:

    • an economic commitment to global markets;
    • a moral support of international and multicultural ties;
    • a political opposition to centralized power — either in governments or in monopolies — that threatened individual autonomy;
    • a belief that technical professionals could achieve these economic, moral, and political aspirations through cooperation and standardization.

    — Andrew L. Russell,
    "Open Standards and the Digital Age"

    These principles stand as critique to older, less open ways of working. Technology that is more interoperable makes a larger space for critique through code and the market, and that is essential to the openness of any society that depends on software as much as modern, western nations do today. ⇐

  4. The history of Bell Labs, the antitrust battles of IBM, the birth of Unix, and the expectations of "common carrier" treatment for data transmission help to situate the thinking of participants in setting up the foundational standards bodies that we now take for granted. Major battles were fought to keep computing out of the hands of a few corporations with outsized power, and the consequences continue to reverberate.

    It is my personal view that it has been the good work of antitrust and anti-monopoly reformers — both within and outside government — that made it possible for other parties to believe in the abstraction of functional markets. Functioning markets are not, in fact, self-organising, and are enabled explicitly by law that helps to minimise noise in the channel (e.g., from fraud).

    That self-identified libertarians (along with the rest of society) have benefited dramatically from the gains enabled by these anti-monopoly regimes is not in doubt; the only mystery is how fervently some cling to the belief that regulation must be problematic as a way to skip past its content and ignore engaging on substance. ⇐

  5. Without an "all clear" signal for explicit standardisation, antitrust law in most advanced nations would explicitly forbid the sorts of coordination among industry peers that standards bodies facilitate. Authorities permit, and even encourage, standardisation in contrast to other forms of collaboration because the positive externality benefits of reduced friction to trade from interoperability is so compelling. For more on the history and structure of this now-international regime, see Russell (2014) ⇐

  6. One needs to look no further than tech CEOs lining up to hail the rise of explicitly fascist leaders and ply them with gifts, to understand the ways in which this corruption corrodes our hopes for open, tolerant societies. ⇐

  7. This is not an accusation to be levelled lightly, and not without overwhelming evidence. But that evidence has accrued, and so I feel compelled to speak.

    Apple are known both to be capricious and retributive, and its antipathy towards Khronos provides an excellent example of the decade-length grudge-holding for which Cuptertino is infamous. I therefore write this post advisedly and with trepedation. ⇐

  8. More than twenty years into the experience of Open Source as a force in software, we can clearly discern that the licence of source code is not, in-and-of itself, a solution to the imbalances inherent in software's relationship to users, or even to other parties with the capacity to develop software.

    I believe that history demonstrates clearly that (F)OSS licensing and effective governance are only related by the intellectual and commercial commitments of those building software, and are therefore easily co-opted by wealthy and powerful firms.

    We have witnessed the limits of forking as a bulwark against bad behaviour, through both the persistent upward reach of firmware into "open" systems, and through capture in higher layers due to the carrying costs of complex systems. Licensing has also been little help in courts against large and determined enemies of OSS and the freedoms it attempts preserve. The limits of licensing, and the lack of IP defence pooling inherent in common licences, create risks that successful firms and projects hit regularly.

    At the limit, (F)OSS licensing is not a significantly disruptive force against wealthy and powerful technology firms, but rather a tool that is useful to peer-level adversaries. For OSS licences and defences to have purchase in practice, a significantly endowed group of technologist's interests must be at stake. The interests of informed and financially capable technologists and the firms that use their software bear only passing resemblance to the needs and interests of society more broadly.

    From this perspective, we can understand (F)OSS as complementary to standards development, but unable to fully replace standards-based interoperability as an attenuating force on the power of software in the lives of users. Standards retain a unique ability to build space for challengers within and between proprietary products, which (F)OSS do not. The power of SDOs to pool the patent interests of proprietary players has parallels in (F)OSS, but with more clarity and lower risk, further accelerating practical interoperability.

    Therefore, we must understand that it is a rhetorical and intellectual trap to consider (F)OSS a replacement for standards. Each hasten interoperability and attenuate power in different and complementary — but not substitutable — ways, and both mechanisms are healthier when the other succeeds. ⇐

  9. The EC, having borne witness to Apple's appalling behaviour within its borders, and more generally to boot, was having none of it.

    The full finding (PDF) is a masterclass in even-handed consideration, and as such it is not surprising that Apple's legal and marketing fictions failed. ⇐

  10. Helpfully for Apple, the conversation around privacy and technology has barely progressed past Apple's anti-Google and anti-Facebook kayfabes.

    Privacy advocates are regularly taken in by Apple's marketing, and the tech press remains in a largely stenographic mode. None of this is to say that Google or Facebook are good actors (they are not), only that Apple is also not on the level.

    We can begin an analysis by noting that Apple does not encourage users to move their computing to the web where browsers can attenuate the worst invasions of privacy. Browsers do not provide nearly as much information to trackers as even the most locked-down native app in Apple's ecosystem, and Apple know this.

    Next, Apple has not funded lobbying and regulatory outreach efforts to establish privacy laws worth a damn. Instead, it channels huge amounts into defeating right-to-repair legislation and defeating browser engine choice around the world, including going as far as funding astroturf groups to provide Cupertino's views in stereo.

    Moreover, Apple takes no responsibility for its historical role in the growth of tracking via the native API surfaces Apple created relative to the web. Nor does it demand audits of data use by App Store participants, or to even set policy about acceptable uses of data collected via App Store-vended applications.

    Apple does not even forbid pervasive "ad blocker blocking" by the worst actors in its ecosystem, even when interventions are trivial from a policy and technical perspective.

    That all of this aligns with Apple's preference for control over, and taxation of, developers cannot escape comment. It further forces us to entertain the idea that Apple's position as a defender of privacy is a cynical show, or that it is incompetent in assessing privacy risks, or that it is out of touch with the behaviour of snooping developers. Any of these would be enough to judge it an incompetent regulator, asleep at the switch.

    Depressingly, these are not even exclusive choices. ⇐

  11. It is prima facie evidence of bad faith for a vendor that skims as much cash from the open web as Apple does, and which insists it must maintain a monopoly on browser engines, to object to providing implementations of proposals that other vendors have shipped safely for years, without offering their own designs to address similar needs,

    This case is bolstered by Apple late-implementing designs which it spuriously objected to as regulatory pressure has grown.

    By failing to engage in solving problems, then citing its own objections as reason not to implement the resulting demonstrably safe features, Apple have cut the legs out from underneath any protection from critique. ⇐

  12. Platforms are in competition.

    It cannot escape notice that Apple's undermining of voluntary adoption most damages interoperable platforms that might challenge the App Store-based native app ecosystem which supports Apple's vertical integration agenda. ⇐

  13. Here we must mention other instances of operating systems imperilling browser choice. Microsoft, for instance, was credibly accused of making text less readable on Netscape Navigator.

    Google, for its part, introduced ChromeOS without any provision for competing browsers. Subsequently, it allowed Android versions of competing browser products using their own engines to register as the default system browser. This is an unsatisfying solution, as Play-based apps are a poor experience on low-end devices and competing browsers are prevented from integrating as deeply as Chrome does. This may not rise to the level of Apple or Microsoft's acts as ChromeOS remains a niche product, ranks lowest in influence, and features a capable browser — regardless, the precedent, combined with prior episodes of Microsoft and Apple turning away from their successful and capable browsers, remains troubling. ⇐

  14. No company in the world is more aware of the awesome power and capability of Apple's A-series chips than Apple itself.

    Apple executives know, for instance, that even the least expensive iPhone produced in the past five years is hundreds of times faster than the first iPhones which gave rise to resource-based restrictions on engine choice. They are either aware, or can trivially deduce, that there is no legitimate system health or resource-related reason to disallow competing browser engines. ⇐

  15. As I have discussed before, Apple economises on the development of WebKit and Safari not only by failing to fund development of web features in a timely way, drafting on the path-breaking work of others, but also through an (over)reliance on OS components in lieu of more easily defended abstractions. This goes much deeper than only needing to support a single family of operating systems; unlike competitors, Apple directly leans on OS systems where competitors rebuild large swaths of the runtime to enable the web where underlying OS APIs are more limited.

    The result, for Apple, is reduced headcount and a lower bill-of-materials when producing devices (read: higher profits), owing to higher code page sharing across applications.

    The consequence for users is an implementation monoculture and slower patch delivery, harming security. Apple's users remain vulnerable to attacks for longer and without recourse to competing alternatives with stronger track records. The downside of all high modernism is brittleness, borne of uniformity, and iOS is no exception. The lack of the ecological diversity that Apple demands undermines security and resilience. This is not a price society should pay for the convenience of a blue chat bubble. ⇐

  16. In testimony before various competition authorities around the world, and in peevish screeds in response to those arguments failing, Apple habitually attempts a rhetorical redirection that unmasks its anti-Popperian thirst for control.

    It appears to believe, on the strength of brand, that it can win on the ground of "who should rule?," rather than "how can institutions keep bad rulers from doing too much damage?" In so doing, Apple offers an authoritarian model of technology. Cupertino proposes that all sources of control attenuation are themselves totalising, and any compromise forced on the ruler therefore equivalent to a coup.

    This is nonsense, both practically and historically, and technologists that support democratic norms should reject this framing.

    History shows clearly that open systems in open societies enable civil society to take many effective positions that attenuate untrammelled power, both of the state and of other actors. We can further see that neither open nor closed systems are full bulwarks against government coercion. The prospects for improved societies must not be invested in autocratic technology firms for the simple reason that they are powerless to deliver it.

    Apple itself has been forced to compromise in areas such as right-to-repair without any of the apocalyptic prophecies of Cupertino's lobbyists coming to pass.

    Here Apple, and its extremely vocal band of apologists, will bring up overreaches by others, including disastrous and ill-advised anti-encryption pushes by national governments. The goal of this argument is to sully the idea of democratic control of technology. "How", it asks leadingly, "can anyone trust these people to do what's right for users?"

    How indeed! For the central point is that we do not have to. Recourse is available (in functioning democracies) through elected representatives and the responsiveness to citizen's concerns. We can even accept that democracies will get many of these issues wrong for a time without seceding any ground to Apple's authoritarian offer. It is intellectually consistent to reject both noxious positions taken by elected officials and offers of high modernist control by firms opposed to the current positions of a government.

    Apple's arguments are microns deep on the merits. They attempt to erase both the successes of civil society (rather than Apple) in curbing abuses along with Apple's own shameful track record of capitulation to overtly authoritarian regimes.20

    Apple's framing asserts that total control by a famously unaccountable firm is a Panglossian utopia. That any decision Cupertino makes now, has ever made, or has ever reversed, have unquestionably been the best of all possible options. That by paying a thousand dollars for a phone, we are but lucky to bask in the glow of such resplendent wisdom.

    It's all too much to take, at least for anyone with a working memory. As I hope I have demonstrated here, this posture fails on ethical as well as practical grounds.

    Apple, with all of its power and money, could be an ally to civil society in curbing abuses without claiming total and unaccountable control for itself in the process. It is incumbent on any thinking technologist to reject such land grabs, even when they come wrapped in causes we otherwise support. To do otherwise is to co-sign the doctrine of "who should rule?," a framing that is caustic to both our short-term technical and long-term societal interests. ⇐

  17. Paradoxically, it may be Apple's own malign behaviour regarding browser choice that might prevent a "no browsers" policy from being possible today.

    Even if we were to ignore Cupertino's incentive to maintain browsers on iOS owing to the shockingly large flows of money from Google for search placement (which Apple records as nearly pure profit), regulators may require it to pursue an "all browsers" alternative to fairly redress the harms from the previous 15 years of abuses. Should this come to pass, Cupertino would (again) have no party to blame but itself. ⇐

  18. The damage Apple has done to the cause of internet and web standardisation is analogous to the (US) concept of impeachable "high crimes and misdemeanours", rather than better enumerated, more pedestrian infractions. This category covers acts that are destructive to the foundational principles of the enterprise, regardless of narrow legality.

    Internet SDOs are not set up well to police or react to this class of offence, which may help explain why Apple's violence against the community has gone unremarked for so many years. ⇐

  19. Apple engineers should be questioned (politely, but insistently) about timelines for implementation of any feature that any other engine chooses to ship, and failure to provide that timeline should be viewed as ongoing evidence of malfeasance against the internet and web community for as long as Apple withholds the ability for others to bring their own engines and whatever features they choose.

    If this causes Apple to retreat from sponsoring work in these venues, that is regrettable, but must also be understood as a choice that is entirely within Apple's power to reverse. ⇐

  20. The fuller airdrop story creates a cross-pressured narrative in which it is possible to claim that Apple was acting to protect, rather than suppress, A4 protesters. But such a pose must also contend with Apple's own history of failure, first to build a truly private version of a system marketed in those terms, thereby encouraging users in sensitive situations to expose themselves to great risk. Second, Apple's unwillingness to patch post-disclosure.

    Owing to AirDrop's use of closed protocols that Apple does not make available to developers of competing applications, it also falls exclusively on Apple's shoulders that better solutions were not available to replace Apple's own botched implementation.

    The story is more complex than "Apple sold protesters up the river," but no publicly available version of events is a defence the argument that Apple is a bellicose marketing outfit with a situational and opportunistic relationship to user privacy and security.

    When the effect is to expose or debilitate users that rely on the very properties Apple so truculently asserts its competitors fail to deliver, it becomes impossible to defend Cupertino's insistence that it alone should be trusted. ⇐

Apple vs. Facebook is Kayfabe

Infrequently Noted

Photo by Claudia Raya
Photo by Claudia Raya

Apple vs. Facebook is, and always was, kayfabe. In reality, Apple is Facebook's chauffeur; holding Zuck's coat while Facebook1 wantonly surveils iPhones owners.2

Facebook's gross profit over time.
Facebook's gross profit over time.

Facebook and Apple mugged convincingly for the cameras as "App Tracking Transparency" rolled out, talking up the impact to Facebook's business. But San Mateo's profits tell a very different story. Net income dipped between late 2021 and early 2023 thanks to accelerating capital expenditures, not reductions in revenue. Despite strenuous efforts to sell the move, it's hard to discern any impact from ATT whatsoever.

How can we be sure Apple's wise? Because Cupertino continues to allow Facebook's wide-scale abuse of In-App Browsers:

Open Web Advocacy - In-App Browser Primer

Apple has long facilitated and enriched mass surveillance through native apps, both directly from in-app activity, but much more insidiously through the In-App Browsers that lurk behind every link in Facebook, Instagram, Messenger, Threads, TikTok, Pinterest, etc.

I have written about them before, and they still stink to high heavens. Facebook couldn't ask for a better or more willing accomplice than Apple as it glides into the second decade of its browserjacking spree.

In-App Browsers are, for Facebook's purposes, ad-blocker blockers. Cheat codes for the enterprising panopticon proprietor. Much wringing of hands transpires every time one of these knockoff browsers is suspected of injecting script into web pages. The fear is that this will enable a level of tracking by apps that is not otherwise possible.

As scary (and real) as the threat is, it is also a misdirection.

To effect total surveillance, Facebook et al. don't need to inject scripts into the runtime, they only need your browser not to block their "ad tags" that are already embedded in every high-traffic page on the internet. Combined with the ability to watch every URL you navigate to in a WebView, this is more than enough to correlate in-app activity with web browsing without leaving overt fingerprints.

As long as users remain in the web purgatory of native apps, data collected from tracking endpoints remains immeasurably richer. It is, in effect, a loophole that only requires users be denied access to their browser of choice whenever it is convenient for native apps.

Real browsers matter because they are user agents; they represent the interests of users, rather than ad networks (Facebook, Google, ByteDance) and the OS vendors that are desperate to keep apps from decamping to portable, interoperable alternatives like PWAs. Users configure their browsers' privacy and security settings, knowing they will synchronize between devices. They can expand those protections with extensions that further ward against unwanted snooping.

By contrast, IABs from Facebook and ByteDance (etc.) do not feature many privacy-preserving settings or extensions, are fiendishly hard to disable, and do not sync between devices in the same app. They don't even synchronise preferences between multiple apps from the same company on the same device.3

Promising-looking options for users trying to disable Facebook's IAB. Now to find the right one...maybe we can just search? Promising-looking options for users trying to disable Facebook's IAB. Now to find the right one...maybe we can just search? Promising-looking options for users trying to disable Facebook's IAB. Now to find the right one...maybe we can just search?
Promising-looking options for users trying to disable Facebook's IAB. Now to find the right one...maybe we can just search?

Ok, let's search for 'web'...ah! 'Apps and websites', looks promising...well...no...maybe if we scroll. Hmmm. Nope. Ok, let's search for 'web'...ah! 'Apps and websites', looks promising...well...no...maybe if we scroll. Hmmm. Nope. Ok, let's search for 'web'...ah! 'Apps and websites', looks promising...well...no...maybe if we scroll. Hmmm. Nope.
Ok, let's search for 'web'...ah! 'Apps and websites', looks promising...well...no...maybe if we scroll. Hmmm. Nope.

Well, what if we search for 'browser' instead? Tapping on 'Browser' takes us to a tab that...doesn't let us turn it off? Hm. Let's go back to the start...might have seen something about 'Content Preferences'...hrm, nope, not that. Well, what if we search for 'browser' instead? Tapping on 'Browser' takes us to a tab that...doesn't let us turn it off? Hm. Let's go back to the start...might have seen something about 'Content Preferences'...hrm, nope, not that. Well, what if we search for 'browser' instead? Tapping on 'Browser' takes us to a tab that...doesn't let us turn it off? Hm. Let's go back to the start...might have seen something about 'Content Preferences'...hrm, nope, not that.
Well, what if we search for 'browser' instead? Tapping on 'Browser' takes us to a tab that...doesn't let us turn it off? Hm. Let's go back to the start...might have seen something about 'Content Preferences'...hrm, nope, not that.

Ok, it has to be in 'Settings and Privacy'...but where? We've tried 'Browser', and that's not it. It's not 'Content Preferences'...maybe 'Media'? Worth a shot... Ok, it has to be in 'Settings and Privacy'...but where? We've tried 'Browser', and that's not it. It's not 'Content Preferences'...maybe 'Media'? Worth a shot... Ok, it has to be in 'Settings and Privacy'...but where? We've tried 'Browser', and that's not it. It's not 'Content Preferences'...maybe 'Media'? Worth a shot...
Ok, it has to be in 'Settings and Privacy'...but where? We've tried 'Browser', and that's not it. It's not 'Content Preferences'...maybe 'Media'? Worth a shot...

I'm sorry...what? Are you actually kidding? The option is hidden two levels deep, not in the 'Browser' section, but in 'Media', and you have to scroll to get to it? I'm sorry...what? Are you actually kidding? The option is hidden two levels deep, not in the 'Browser' section, but in 'Media', and you have to scroll to get to it? I'm sorry...what? Are you actually kidding? The option is hidden two levels deep, not in the 'Browser' section, but in 'Media', and you have to scroll to get to it?
I'm sorry...what? Are you actually kidding? The option is hidden two levels deep, not in the 'Browser' section, but in 'Media', and you have to scroll to get to it?

Be honest: would you think to look in 'Menu' > 'Settings & privacy' > 'Settings' > [ scroll to 'Preferences' ] > 'Media' > [ scroll to bottom ] > 'Open links in external browser'?
Be honest: would you think to look in 'Menu' > 'Settings & privacy' > 'Settings' > [ scroll to 'Preferences' ] > 'Media' > [ scroll to bottom ] > 'Open links in external browser'?

This goat rodeo is wilfully obtuse in a way that only an organisation dedicated through-and-through to A/B testing can accomplish. You might very well think that Facebook is working hard to trick users into a knockoff browser in the hopes they don't notice.

Even without assuming intentional obfuscation, it is shocking how laughably incomplete the privacy and security settings of Facebook's IAB remain, more than a dozen years after it was introduced:

Facebook's IAB fails to provide standard security, privacy, and accessibility settings. This single page is the entire set of available configuration options, and they are not sync'd.
Facebook's IAB fails to provide standard security, privacy, and accessibility settings. This single page is the entire set of available configuration options, and they are not sync'd.

An identical thicket of pain awaits anyone trying to disable the Facebook IAB on iOS. Facebook's UI is screen-for-screen the same across mobile OSes, and iOS users enjoy no advantage in finding the settings to disable FB's IAB.

Chrome and Edge's sync'd settings are vast by comparison, as are the offerings from every other responsible browser vendor:

Firefox for Android has such detailed settings that users have to scroll twice to see just the top-level entry points. The 'Privacy and Security' section alone offers as many options as all of FB's IAB. Firefox for Android has such detailed settings that users have to scroll twice to see just the top-level entry points. The 'Privacy and Security' section alone offers as many options as all of FB's IAB. Firefox for Android has such detailed settings that users have to scroll twice to see just the top-level entry points. The 'Privacy and Security' section alone offers as many options as all of FB's IAB.
Firefox for Android has such detailed settings that users have to scroll twice to see just the top-level entry points. The 'Privacy and Security' section alone offers as many options as all of FB's IAB.

Opera is similarly flexible and settings follow logged-in users through sync. Opera is similarly flexible and settings follow logged-in users through sync.
Opera is similarly flexible and settings follow logged-in users through sync.

The difficulty in disabling Facebook's IAB, failure to synchronize opt-out choices, and a crippled privacy features are calculated to enable maximum tracking when tapping links. Even when Apple's vaunted "App Tracking Transparency" is enabled:

App Tracking Transparency was enabled, yet Facebook's IAB continues to be invoked when tapping on links. The IAB was also disabled on the same account via another device within the hour, showing that Facebook disregards privacy settings when it suits them.

Here are the results of the EFF's "Cover Your Tracks" testing tool on (left-to-right) the iOS Facebook IAB, Firefox Focus, and the DuckDuckGo browser, all with default settings under iPadOS 17.7.10:

FB's IAB scores worst of all FB's IAB scores worst of all FB's IAB scores worst of all
Facebook's IAB reports 'some protection' with 'some gaps', leaking a unique fingerprint, while both Firefox Focus and DuckDuckGo do better, featuring 'strong protection', despite using exactly the same browser engine under the hood, as Apple (unfairly) requires.

Users that install browsers, configure them to preserve their privacy, then use Facebook app's after selecting "Ask App Not to Track" are reliably sold up the river by Apple, who seem content to facilitate this end-run around the rules.

Privacy settings? Gone. Extensions? Poof! And because Facebook has code on every top site, the tracking suddenly roars back to life, out of band of the channels that Apple wants you to believe are important (or at least that it has taken heat for in the past).

FB's tracking is so pervasive in modern web pages that it doesn't need to exfiltrate data from the IAB to track you. It just needs to keep you away from your real browser, where it might not be able to join up clicks and taps.

It isn't exactly clear if the IAB is the basis for recent reports of secretive "deterministic matching" efforts, but it's safe to assume that Facebook's bullheaded determination to steal clicks and deny users their choice in browsers isn't simply an oversight.

None of this is news to Apple. They have read the posts and have made timid interventions to avoid being blamed for the most obviously nasty versions of IAB tracking. But acting against the deep rot? No joy.

Not only has Apple not responded to advocacy on behalf of users from groups like OWA, it has failed to impose either common-sense, pro-privacy restrictions on IABs, or to support action by regulators. As we've seen above, it doesn't even require apps to avoid privacy-degrading IABs when ATT is enabled or provide a global opt-out.

And Apple is absolutely aware of these concerns because they have been raised publicly and in regulatory circles for years. Yet it does not act.

Why?

Facebook's dark patterns are directly facilitated by Apple and Google. It is their SDKs and policies that make this not only possible, but pervasive. So why do they deliver users unto perdition?

Denying users true browser choice helps keep the big app vendors in the store. Those whales understand that native APIs offer increased data collection, which they monetize.

Keeping big fish in the store, in turn, helps Apple and Google corral others into their API enclosure ghettos. If users know that to get their "main" apps, they must go to the store, then the store becomes the place to look for all software. Moreover, for competitors to have any hope of equivalent profits, they must enter the same Store-enabled race to the privacy bottom.

And that race to the bottom helps the duopolists, no matter how much they want you to believe otherwise.

Apple and Google are trying to maintain a distribution model chokehold over mobile software. Their duopoly allows them to tax developers outrageously for access to commodity APIs. Dependence on proprietary versions of bog-stock APIs, in turn, makes it hard for software vendors to consider building for other platforms with their limited engineering budgets.

This, not coincidentally, reduces the size of the (potentially) portable software catalogue, harming the prospects of new entrants that might challenge the duopoly. For users, a lack of apps in open ecosystems make it hard to escape for less predatory alternatives.

The entire point of the multi-layered exercise, in the end, is to subvert interoperability. And to do that, it's necessary to keep the anchor apps happy. Which is why Apple and Google let Facebook spy on you via through the web.

Apple isn't defending your privacy, it's retreating just far enough into the hedge that you won't notice the App Store dangling Facebook, Messenger, Instagram, and TikTok to take the blame for the APIs that Apple itself has recklessly provided. Compared to the web, iOS native apps have facilitated a universe of privacy invasion that was previously unthinkable. Apple did that, and continues to do that, and now it wants credit for forcing developers to "comply" (wink wink) with anti-tracking rules it can't be bothered to enforce.

The answer is blindingly obvious: forbid IABs, particularly under ATT, and/or force native apps to use the system-provided browser-overlay systems — SFSafariViewController and Android Custom Tabs — where user's choice of browser and customisations will be respected.

This isn't hard. In fact, it's one of the simplest interventions possible. And yet neither Apple nor Google are willing to pick a real fight with Facebook and do right by users.

And until they do, you can be certain the privacy preening is all for show.4

FOOTNOTES

  1. I will continue to refer to Facebook as "Facebook" and Twitter as "Twitter" despite their sweaty, grasping rebrands.

    It is an act of complicity to assist folks this guilty in turning the page on their transgressions. Using their new names helps oligarchs who retain standing through collective amnesia by disconnecting what is from what was, and they know it. Which is why they tried to rebrand in the first place.

    The US legal fiction of "corporate personhood" does not entitle that corporation to respect. As a corporation's feelings cannot be hurt, either because it has none, or because it is a sociopath (as the market demands). If a billionaire is so embarrassed of their monster that they long for its rebirth it, I say fine; go ahead. I'll happily call it something else, just so long as it dies first. Liquidate the assets, pay your bloody taxes, fire everyone, put the winnings into a holding LLC, then start afresh. Then I'll call the new thing whatever they please.

    Never deadname a trans person, but the pet amphisbaenas of billionares? Always and forever. ⇐

  2. At least until Apple can wrestle away Facebook's ad business for itself. ⇐

  3. A reliable measure of a tech firm's disrespect is making users frequently re-select privacy-enhancing choices. A good proxy for this is which settings are sync'd. Chrome's disregard for choices which Google dislikes is evident when logging into each new device:

    Every time a user visits settings on a new device, they're obliquely informed that the settings they laboriously configured on previous devices have been disregarded.
    Every time a user visits settings on a new device, they're obliquely informed that the settings they laboriously configured on previous devices have been disregarded.

    Chrome settings after verifying that sync has completed for the profile.
    Chrome settings after verifying that sync has completed for the profile.

    All of this has been carefully considered, and it is exceedingly likely that Figma mocks exist for versions that respect user choices. Those designs were not put into production. It's impossible to know from the outside exctly who made the call, but it's a reliable guess that the ads team won a Product Manager cage match.

    Facebook, for its part, is even worse, failing to join up browser choice settings on any surface or across apps. Hardly a surprise, but in a world where almost every other setting is synchronised, the difference is confirmation of anti-user intent. ⇐

  4. It should go without saying that the only truly effective solutions in this space will be legislative and regulatory. That neither Apple nor Google have put their aggressive lobbying teams to work to get effective privacy laws passed should also be a warning flag.

    Until and unless they're willing to put the same sorts of money behind drafting model legislation and donating to the coffers of electeds via proxies that they do to degrade right-to-repair and browser engine choice, it's all kayfabe. ⇐

Put Names and Dates On Documents

Infrequently Noted

Anyone who has worked closely with me, or followed on social media [, ], will have seen a post or comment to the effect of:

Names and dates on docs. Every time. Don't forget.

This is most often tacked onto design documents lacking inline attribution, and is phrased provocatively to make it sticky.

Why do I care enough about this to be prescriptive — bordering on pushy — when colleagues accuse me of being Socratic to a fault about everything else? Because not only is unattributed writing a reliable time-waster, the careers of authors hang in the balance.

Having to work to find the best person to discuss a topic with is annoying, but in large organisations, the probability of authors having work appropriated without credit goes up when they fail to claim ownership of their writing. It should go without saying that this is toxic, and that functional engineering cultures look harshly on it. But to ward off bad behaviour, it helps to model what's healthy.

The best reminder to cite work is for authors to name themselves. Doing this increases their stature, unsubtly encourages others to link and cite, and leaves a trail of evidence for authors to reference when building a case for promotion.

The importance of evidence to support claims of design work in technical fields cannot be overstated. Having served on hiring and promotion committees for many years, I can unequivocally say that this collateral is often pivotal. The difference between "[x] promote" and "[x] do not promote" often comes down to the names on documents. Reviewers will pay attention to both the authors list and the propensity of design doc authors to cite others.1

In response to unsubtle nudges, several recurring arguments are offered against explicit authorship notices.

This is fair, but does not outweigh the needs of future readers who may be working to trace a chain of events or ideas. Nor does it outweigh the needs of authors for credit regarding their work at a future date.

This crutch fails in any number of ways:

  • PDFs and printed copies do not include authorship data that is not in body text.
  • Some systems (e.g. Google Docs) do not make the history available to non-editors.
  • Documents may be copied or re-published in ways that disconnect the content from the original revision tracking system; e.g., in a systems transition as part of an acquisition.

Moreover, design is a complex and collaborative process. Ideas and concepts captured in documents are not always the contribution of the person writing down the conclusions of a whiteboarding session. A clear, consistent way to give credit helps everyone feel included and encourages future collaboration.

This is usually offered as a claim of superfluousness. If everyone knows everything and everyone working in a system, why does attribution matter?

Perhaps a team is small now, but will it always be? I am not in a position to tell, and my interlocutors also lack crystal balls. Given the downside risks, attribution is a pittance of an insurance premium.

This is easily countered with invitations in comments and drafts for contributors to add themselves to the authorship section. Generous and collaborative folks — the sorts of people we want to promote — reliably add their collaborators to documents proactively and set the expectation that others will do the same. Over time, practice becomes habit, which crystallises into culture.

A final concern I hear is that these blocks require a great deal of upkeep. Long-form revision logs might be onerous, but the minimum viable attribution style only needs three elements: names, emails, and dates. These should be provided on the very first page, ideally just below the title.

The primary date always refers first drafting, even if that is before publication. If deemed necessary, authors can optionally add a "Last Updated" field below the primary date, but this is optional. Documents authored in a single sitting by a lone author should avoid extra visual noise.

Revision logs are generally unnecessary, and my personal view is that they distract from content; if they're a requirement (e.g., in a heavily regulated industry), record them in an Appendix, but do not remove minimum viable attributions.

Here's a screenshot of an explainer I helped draft many years ago showing the basic form2:

Minimum Viable Attribution in a Markdown document.
Minimum Viable Attribution in a Markdown document.

If a document is still an early draft, it can be helpful to put some indication in the title — I use a prefix like "[ Draft ] ..." — and invite collaborators to add themselves to the authors list by including an entry there of the form "Your Name <your_email@example.com>". Once a document is circulated widely, remove these inline markers.

Thanks to Andy Luhrs for his feedback on drafts of this post.

FOOTNOTES

  1. If you write technical design docs, it is always a good sign if you cite prior work and parallel efforts, including competing designs. Omitting those references is something that both technical and promotion reviewers are alert to and are primed to think poorly of. No design is entirely new, and it is a sign of maturity to give others their due. ⇐

  2. Don't worry, all of these email addresses are now inactive.

    On the question of emails and spam in authoring public documents, views are split. I favour always using them, but understand if authors prefer other sorts of contact information; e.g., their personal website. Best not to be too fussy about this sort of thing, except to ensure that internal documents always contain email addresses. ⇐