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. Vendors, therefore, have power over them. 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 libertarian¹ 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,² and that view became embedded deeply into the internet's governance mechanisms.³ 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 (or should) continue to decouple; that it would be ever easier for end-users to bring software of their choosing to devices they had purchased. Their faith in the trajectory was well-founded. It is ludicrous from the perspective of 2025 to suggest that swapping implementations of nearly any internet standard should come at the cost of replacing hardware.

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

And it has worked. Internet standards have facilitated interoperability that has 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.⁵

But standardisation is not purely an economic project. Standards attenuate the power of firms that might seek to arrogate code's privileges. Functional interoperability enables competition, and in so doing, reallocates power to users. Interoperability, and the standards that ensure it, are 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 both legal and electoral systems, and when left to fester, is caustic to democracy itself.⁶

As we shall see, Apple has deftly used a false cloak of security and privacy to move the internet, and web in particular, toward enclosure and irrelevance. Below, I develop the case for why Apple should be considered a corrupted, and indeed incompetent, autocrat in the digital lives of millions, abusing 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. I submit that Apple have been, over the course of many years, poisonous to internet standards and the moral commitments embodied in that grand project.⁷

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

The Power of Interoperability

One reason to champion standardisation is that it signifies the expansion of interoperable technology, pushing firms to innovate, rather than extracting rents for access to commodity features.

Interoperability-in-being allows users to choose alternative implementations, forcing competitors to differentiate on quality and not yet standard features. Standards accelerate the emergence of true interoperability by lowering the costs of implementation and reducing tails risks to implementers, e.g. from patent trolls. Over time, a vibrant and growing 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 dampen the power of dominant firms, but it is the most powerful. Free and Open Source software (FOSS) can provide a counterweight to rentiers, but OSS is not a full solution.⁸

Voluntary Adoption Is Foundational to Internet Standards

Interoperability, and the economic surpluses that flow from it, are underpinned by the bedrock principle of 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 "picking winners". But it is not only that.

Voluntary adoption is necessary for internet standards to function, and this principle implicitly binds participants to a presumption of fair play, both for themselves, and for others in the ecosystems that standards bodies facilitate.

Several implications bear mentioning.

First, the principle of voluntary adoption is a predicate for effective standards' development. Without some mechanism for determining which designs are good vs. bad, we are unable to make consistent progress, and that test never comes from within an SDO; it is always extrinsic and customer-defined. Writing a standard is not a test of quality, and conversely, without a functional market in which to test designs, 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 using procedural shenanigans to prevent competing designs from also being standardised.

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

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

Apple's Unique Monopoly

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, being marketed under that brand for many years, supporting considerably identical features, running all the same third-party software, and being released on substantially the same cadence, while running exclusively on hardware of the same architecture as iOS devices is, somehow, an entirely different product.⁹

But these tests, for as clear and effective as they have been, do not capture the most important aspects of Apple's influence on the market for smartphone software.

Apple's ability to negatively impact the potential of standards-based platforms to disrupt the App Store relies on properties of the market that every software developer understands: a monopoly on wealthy users, and through it, influence.

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

Despite selling fewer than a quarter of smartphone devices every year for the past decade, Apple has maintained iron control over the way smartphone software is developed and delivered, owing to the social and market effects of wealthy users gravitating to iOS devices. Apple uses both legitimately superior product attributes (e.g., leading chip design) along with anti-user and anticompetitive tactics — e.g., green vs. blue chat bubbles, suppression of browsers — to maintain this position.

Apple imposes an interlocking set of restrictions to help ensure that standards-based platforms cannot disrupt its position as the primary arbiter and delivery channel of software for wealthy users. Those users, in turn, enjoy disproportionate influence over the behaviour of software developers, owing both to their greater spending power, and their collective ability to determine the relevance of competing platforms thanks to their positions within the software industry. Developers of all stripes understand that if they cannot demo their wares to the 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 that developers have no effective choice but to build native applications, for which Apple extracts rents. 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"

Over time, the effect becomes self re-enforcing: developers are forced into the App Store due to a lack of capabilities in browsers, granting proprietary ecosystems a library of software with no interoperable parallel. This further induces wealthy and influential users to seek software exclusively through App Stores.

The monopoly on influence explains in part why Apple is wedded to legalistic, dissembling tactics in order to prevent the spread of standards-based platforms. 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.

How Apple Uses Its Monopoly to Centralise and Enclose

Developers are forced into the App Store, first and foremost, by a lack of functionality in standards-based alternatives. By contrast, Apple has used over-broad grants of system capabilities to woo developers with an interest in monetising user data through too-broad grants of detailed information about users and unconscionable allowances for suppressing pro-privacy interventions by the most rapacious native apps.¹⁰ When Apple professes that "privacy is a human right", we must understand this as an attempt to turn the consequences of Apple's own largesse towards data abusers into a marketing asset and an attempt to convince users not to flee the proprietary ecosystem it favours.

These over-broad grants depend, fundamentally, on Apple's own decisions.

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, ensuring 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 terms.

The result has been API enclosure; appropriation of commodity capabilities that themselves are standards-based — e.g., USB, Bluetooth, NFC, file storage, etc. — by a proprietary ecosystem and denial of even the safest and most privacy-preserving versions of those features by open, interoperable, and standards-based application platforms.

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

Apple's Transgressions Against Voluntary Adoption

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

Apple has:

• Restricted competitors from delivering their own implementations of web and internet standards, depriving them access to Apple's monopolised controls of influential users.
• Forced all iOS browsers to use Apple's own, defective and impoverished, implementations, depriving users of choice and destroying the market's ability to select for better ideas and implementations.
• Compelled browser engine monoculture and, in so doing, consistently undermined user security and privacy.
• Attempted to use contractual terms to dissuade competitors from extending browsers to support standards that Apple disfavours.
• Serially misled regulators and the public when presented with evidence of the harms that spring directly from the above.
• Objected spuriously in bad faith within standards bodies to prevent standardisation of features which Apple offered no counter-proposal.¹¹
• Since at least 2015, delivered explicitly pejorative UI and marketing to discourage use of open and interoperable technologies that might benefit users at its own expense.

Through these and other overt acts, Apple has worked to disempower users, depriving them of choice in the market, and thereby devaluing the effectiveness of interoperable, standards-based platforms.¹²

These acts are not simply the competitive acts of a fierce market participant. 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 are predicated on.

Unilateral Off-Ramps

It must be emphasised that Apple has never been forced to suppress its competitors, nor to create an anticompetitive landscape. At every moment, Cupertino's senior management have retained intellectually consistent choices that allow it to pursue growth of Apple's superior (we are told) native app ecosystem without creating conditions that threaten 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 vendor has for nearly the web's entire history, and which Apple has itself facilitated on macOS.¹³ Any plausible restriction owing to available system resources has long been overcome by progress in mobile hardware, particularly within Apple's ecosystem.¹⁴ Early mobile era justifications based on API richness and resource availability were falsified by even the lowliest Androids to more than a decade ago.

The only conscionable restrictions on competing browser engines spring from demonstrable failures to safeguard security. As other vendors have generally had better track records vs. Apple regarding sandboxing strength, security response times, patch gap width, and consistent coverage for users on older OS versions, this should be no practical obstacle.

Lest Apple's defenders worry about the impacts on the company, under true browser choice, Apple retains considerable market advantages, including (but not limited to) pre-installation, lower structural costs¹⁵, and continued voluntary feature adoption, allowing it to earn users through differentiation.¹⁶ 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 all browsers on iOS. This is a fully consistent position, and one that has been available to Apple from the moment of the iPhone'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.¹⁷

Either way, the choice to undermine choice and standards has rested entirely with Apple. At every moment it has had intellectually honest solutions available to resolve these contradictions of its own design. Apple cannot claim the situation is anyone else's fault, or that it has had no choice.

How Apples Crimes Differ From Prior Episodes

It should be obvious from the proceeding sections that I do not consider Apple's mere failure to implement standards I personally approve of to rise to the level of the transgression worthy of sanction.

Under voluntary implementation, every vendor is free to ship whatever they please, including Apple. Whilst it may be sad, or even damaging, when features go missing from important products, that is not a calamity. In functioning markets, this is simply an input to be priced. Among browsers, this has traditionally been experienced as vendors gaining or losing share to the extent they support otherwise-interoperable content.

And so it 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. Some tactics may be distasteful, but reside squarely within the "awful but lawful" category. Venues dedicated to free exchanges of views should allow them, with sanctions for poor behaviour meted out in the social realm, if at all.

Apple's outrages against this community are more fundamental, and more dangerous.¹⁸

Some will see here 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 bestowing membership in good standing to those actively uprooting the basis for standards is to ensure 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 that users might use 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.

Necessary, Proportional Responses

The web and internet communities must understand not only the threat, but the ongoing harms to the cause of the web and of 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, practically, can be done?

The founding documents of internet SDOs do not include mechanisms for censure of these violative acts. The W3C's bylaws, for example, only speak to membership in good standing in relationship to payment of dues. Regardless, it is possible — and I believe urgent — to do more.

First, proposals can be raised to amend those documents to include mechanisms for censure by votes of the membership for actions such as those alleged here. These are likely to fail, and will surely be rejected on a first attempt, but the act of constituents considering these questions has power in and of itself. Raising proposals for discussion at plenary meetings and in visible fora can, at a minimum, elicit a response to the charges levied here. That, on its own, is valuable to the community.

Next, leadership boards with moral authority can write persuasively on the question. 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 the continued relevance of their convening organisations.

Most importantly, individual delegates to working groups of all sorts can recognise that Apple's compelled use of WebKit by competitors on iOS is illegitimate and corrosive. Having done so, they can resolve not to accept "Apple does not comment on future products" as a viable response to questions about implementation timelines.

As long as Cupertino demands and unjustly defends a monopoly, it is incumbent to demand responsibility for the consequences of Apple's failures.

Apple alone can choose to support features within WebKit and allow them in other iOS browsers, even under compellence, and even if it does not to enable them in Safari. It is simply illegitimate for Apple to claim that it cannot or should not allow other vendors to reach feature parity with competing engines.

The sham of WebKit as an Open Source project is incompatible with disavowal of features that other vendors would flag on for their iOS users if allowed. Compelled implementation and the destruction of voluntary adoption should not be a shield against critique. Instead, it must heighten expectations. These are simply the consequences of accepting responsibilities that Apple agues it should be singularly entrusted with, despite Safari and WebKit's trailing record on standards' conformance, security, and privacy.

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 must use Apple's engine, Apple should bear the costs of completeness and feature quality. So long as Cupertino compels use of WebKit by competitors, the demand must be echoed back: parity with browser features on other Operating Systems is the minimum bar.

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.

Fundamentally, the web and internet community must stop accepting the premise that Apple should benefit from the protections and privileges that voluntary adoption affords whilst it denies those benefits to others.¹⁹

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, of course, inconsistent for Apple to hold positions of influence in organisations they are actively suppressing, and fellow participants are under no obligation to pretend otherwise or hand Apple formal or even persuasive power within these groups.

Why Now?

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

Beyond the threshold point that the damage done is cumulative, and therefore it isn't necessary to identify specific instances to discuss the rot Apple's influence has caused, 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.

Do Standards Matter?

Like most who have dedicated the greater proportion of their working lives to the cause of an open and interoperable web, the conclusions offered 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 of society. Only those who would see markets subjugating all, forever, because of one-time power imbalances can be sanguine about what Apple has done.

   We do not have to grant that pro-totalitarian arguments in technology are in good faith given what we know about where unchecked power reliably 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. For a vendor as wealthy as Apple, and one that insists it must maintain a monopoly on implementations of standards-based platforms on the most influential OS — particularly one that skims as much cash from the open web as Apple does — to object to proposals other vendors ship safely for years, without offering their own designs to address similar needs, is prima facie evidence of bad faith.

    This case is bolstered by implementation of the same designs to which spurious and unbacked objections were previously raised as regulatory pressure has grown. ⇐

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.²⁰

    Apple's framing asserts that total control by a famously unaccountable firm is a Panglossian utopia. That any choice Cupertino makes now, has ever made, or has ever reversed, have unquestionably been the best of all possible choices. 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, and always was, kayfabe. In reality, Apple is Facebook's chauffeur; holding Zuck's coat while Facebook¹ wantonly surveils iPhones owners.²

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.³

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:

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:

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:

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:

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.

Apple Knows

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.⁴

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:

   

   

   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. ⇐

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.¹

Weighing Up Inline Attribution

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

"These blocks detract from readability."

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.

"There's already an edit log."

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.

"Our team is small.

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.

"Specifying an author elides the contributions of collaborators."

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.

Minimum Viable Attribution

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 form²:

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.

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. ⇐

Mel Conway's seminal paper "How Do Committees Invent?" (PDF) is commonly paraphrased as Conway's Law:

Organizations which design systems are (broadly) constrained to produce designs which are copies of the communication structures of these organizations.

This is deep organisational insight that engineering leaders ignore at their peril, and everyone who delivers code for a living benefits from a (re)read of "The Mythical Man-Month", available at fine retailers everywhere.

Conway's Law is generally invoked to describe organisations working to solve well-defined problems, in which everyone is working towards a solution. But what if there are defectors? And what if they can prevent forward progress without paying any price? This problem is rarely analysed for the simple reason that such an organisation would be deranged.

But what if that happened regularly?

I was reminded of the possibility while chatting with a colleague joining a new (to them) Working Group at the W3C. The most cursed expressions of Conway's Law regularly occur in Standards Development Organisations (SDOs); specifically, when delegates refuse to communicate their true intentions, either through spurious objection or tactical silence.

This special case is the fifth column problem.

Expressed in Conwayist terms, the fifth column problem describes the way organisations mirror the miscommunication patterns of their participants when they fail to deliver designs of any sort. This pathology presents when the goal of the majority is antithetical to a small minority with a veto.

Reticence of certain SDO participants to consider important problems is endemic, in part, due to open membership. Unlike corporate environments where alignment is at least partially top-down, the ability of any firm to join an SDO practically invites subterfuge. This plays out calamitously when representatives of pivotal firms obfuscate their willingness to implement, or endlessly delay consideration of important designs.

Open membership alone would not lead to crisis, except that certain working groups adopt rules or norms that create an explosion of veto players.

These veto-happy environments combine with bad information to transmute opaque communication into arterial blockage. SDO torpidity, in turn, colours the perception of web developers against standards. And who's to say they're wrong? Bemoaning phlegmatic working groups is only so cathartic.

Eventually, code must ship, and if important features are missing from standards-based platforms, it becomes inevitable that developers will decamp to proprietary solutions.

Instances of the fifth column problem are frequently raised to me by engineers working in these groups. "How," they ask, "can large gatherings of engineers meet regularly, accomplish next-to-nothing, yet continue pat themselves on the back?"

The sad answer is "quite easily."

This dynamic has recurred with surprising regularity over the web's history,¹ and preventing it from clogging the works is critical to the good order of the entire system.

How Does This Happen?

The primary mechanism that produces consequential fifth column episodes is internal competition within tech giants.

Because the web is a platform, and because platforms are competitions, it's natural that companies that make both browsers and proprietary platforms favour their owned-and-operated offerings.

The rent extraction opportunities from controlling OS APIs are much more lucrative than an open ecosystem's direct competition. Decisions about closed platforms also do not have to consider other players as potential collaborators. Strategically speaking, managing a proprietary platform is playing on easy mode. When that isn't possible, the web can provide a powerful bridge to the temporarily embarrassed monopolist, but that is never their preference.

This competition is often hard to see because the decisive battles between proprietary systems and open platforms are fought behind the tallest, most heavily guarded walls of tech giants: budget planning.

Because budgets are secret, news of the web losing status is also a secret. It's a firing offence to leak budget details, or even share internally to those without a need to know, so line engineers may never be explicitly told that their mission has fundamentally changed. They can experience transitions away from the web as "Plan A" to "Plan Z" without their day-to-day changing much. The team just stops growing, and different types of features get priority.

OS vendors that walk away from the web after it has served their businesses can simply freeze browser teams, trimming ambitions around the edges without even telling the team that their status has been lowered. Capping and diverting funding away from new capabilities is easily explained; iteration on existing, non-threatening features is important, after all, and there are always benchmarks to optimise for.

Most fifth columnists are, therefore, unwitting and unknowing accomplices to corporate machinations well above their own pay grades. They cannot acknowledge that a vibrant web is not valuable to their firm because they will have never been told as much, and should they enquire, will hear only that the important work they are doing continues to be valued.

Mayfly Half-Lives

Until recently, the impact of fifth column tactics was obscured in a haze of legacy engines. Web developers take universality seriously, so improvements in capabilities have historically been experienced as the rate at which legacy UAs fall below a nominal relevance threshold.² Thanks to pervasive auto-updates, the historical problem of dead-code-walking has largely been resolved. Major versions of important browsers may have entire cradle-to-grave lifecycles on the order of two or three months, rather than IE 6's half-decade half-life.

This has clarified the impact of (dis)investments by certain vendors and makes fifth columnists easier to spot. Web developers now benefit from, or are held back by, recent decisions by the companies (under)funding browser development. If sites remain unable to use features launched in leading-edge engines, it's only because of deficiencies in recent versions of competing engines. This is a much easier gap to close — in theory, anyway.

The Web Platform's Power Structure

Web standards are voluntary, and the legal structures that create SDO safe-harbours (PDF) create the space in, and rules under, which SDOs must operate. SDOs may find their designs written into legislation after the fact, or as implementation guides, but there is a strong aversion to being told what to design by governments within the web community, particularly among implementers. Some new participants in standards arrive with the expectation that the de jure nature of a formal standard creates a requirement for implementation, but nothing could be further from fact. This sometimes leads to great frustration. Enshrining a design in a ratified standard does not obligate anyone to do anything, and many volumes of pure specifiction have been issued to little effect.

The voluntary nature of web standards is based on the autonomy of browsers, servers, and web developers to implement whatever they please under own brand.

Until Apple's flagrantly anticompetitive iOS policies, this right was viewed as inviolable because, when compromised, erosions of feature sovereignty undermines the entire premise of SDOs.

When products lose the ability to differentiate on features, quality, performance, safety, and standards conformance, the market logic underpinning voluntary standards becomes a dead letter. There's no reason to propose an improvement to the collective body of the web when another party can prevent you from winning share by supporting that feature.

The harms of implementation compellence are proportional to market influence. iOS's monopoly on the pockets of the wealthy (read: influential) has decisively undermined the logic of the open internet and the browser market. Not coincidentally, this has also desolated the prospect of a thriving mobile web.

The Mobile Web: MIA

It's no exaggeration to say that it is anti-web to constrain which standards vendors can implement within their browsers, and implementation coercion is antithetical to the good functioning of SDOs and the broader web ecosystem.³

In a perverse way, Apple's policy predations, strategic under-investment, and abusive incompetence clarify the basic terms of the web's power structure: SDOs are downstream of browser competition, and browser competition depends on open operating systems.

But Why?

Why do vendors spend time and money to work in standards, only to give away their IP in the form of patent licences covering ratified documents?

When vendors enjoy product autonomy, they develop standards to increase interoperability at the behest of customers who dislike lock-in. Standards also lower vendor's legal risk through joint licensing, and increase marketability of their products. Behind this nondescript summary often lies a furious battle for market share between bitter competitors, and standards development is famous for playing a subtle role. Shapiro and Varian's classic paper "The Art of Standards Wars" (PDF) is a quarter-century old now, but its description of these sorts of battles is no less relevant today that it was in '99.

Like this classic, most discussions of standards battles highlight parties with differing visions but similar goals — should margin-sizing or border-sizing be the default? — rather than situations where one vendor has a proprietary agenda and wishes to grow or maintain a capability gap versus standards-based alternatives. Denying features to open ecosystems makes high-tax proprietary platforms more attractive, and gridlock in standards is an effective strategy for accomplishing it. These cases are under-discussed, in part, because they're hard to perceive over short time periods or by observing a single working group.

Parties that maintain a footprint in standards, but are unhappy to see standards-based platforms compete with their proprietary offerings, only need a few pages from the Simple Sabotage manual (PDF).

Often, they will send delegates to important groups and take visible leadership positions. Combined with juuuuuust enough constructive technical engagement, obstreperous parties scarcely have to say anything about their intent. Others will raise their own hopes, and cite (tepid) participation as evidence of good faith. The fifth columnist doesn't need to raise a finger, which is handy, as doing nothing is the goal.⁴

Problem Misstatements

Working group composition also favours delays at the hands of fifth columnists. Encouraged by defectors, they regularly divert focus from important problems, instead spending huge amounts of time on trivialities because few customers (web developers) have the time, money, and energy to represent their own needs in committee. Without those voices, it's hard to keep things on track.

Worse, web developers generally lack an understanding of browser implementation details and don't intone the linguistic airs and shorthands of committeespeak, which vary from venue to venue. This hampers their ability to be taken seriously if they do attend. At the limit, dismissing pressing problems on technicalities can become something of a committee pastime.⁵

There's also a great deal of opportunity for fifth columnists to misrepresent the clearly stated needs of web developers, launching projects to solve adjacent (but unimportant) sub-issues, while failing to address the issues of the day. This is particularly problematic in big, old rooms.

A competent fifth columnist only needs to signal in-group membership to amplify the impact of their own disinterest in topics they would prefer to avoid. Ambiguous "concerns" and scary sounding caveats are raised, and oven-ready designs which do arrive are reframed as naive proposals by outsiders. Process-level critique, in lieu of discussing substance, is the final line of defence.

Deflecting important work is shockingly easy to pull off because organisations that wish to defeat progress can send delegates that can appeal to rooms full of C++/Rust engineers as peers. The tripwires in web API design are not obvious to the uninitiated, so it's easy to move entire areas of design off the agenda through critique of small, incongruent details.

The most depressing thing about this pattern is that these tactics work because other vendors allow it.

Closed For Business

One problem facing new areas in standards is that chartered Working Groups are just that: chartered. They have to define what they will deliver years in advance, and anything not on the agenda is, by definition, not in scope. The window in many SDO processes for putting something new into the hopper is both short and biased towards small revisions of the existing features. Spinning up new Working Groups is a huge effort that requires political clout.

Technically, this is a feature of SDOs; they jointly licence the IP of members to reduce risks to implementers and customers of adopting standards-based products. Patent trolls have to consider the mutual defences of the whole group's membership and cannot easily pick off smaller prey. Most developers never give a second thought to patent portfolios and do not live in fear of being personally sued for infringement.

This is a sign web standards are a smashing success, but also makes it unlikely that working developers understand that standards processes are designed with bounded IP commitments in mind. Internet SDOs have been so successful at caging the beast that generations of developers have never considered the threat or how it intersects with their interests.

This creates a tension: over the long term, SDOs and the ecosystems can only succeed if they take on new problems that are adjacent to the current set, but the Working Groups they create are primed by their composition and history to avoid taking on substantial expansions of their scope. After all, a good v2 of a spec is one that fixes all the problems of v1 and introduces relatively few new ones.

To work around this restriction, functional SDOs create incubation venues. These take different guises, but the core features are the same. Unlike chartered Working Groups, incubation groups are simple to create; no charter votes or large, up-front IP commitments. They also feature low bars to participation, can be easily shut down, and do not produce documents for formal standardization, although they can produce "Notes" or other specification documents that Working Groups can take up.

Instead, they tend to have substantial contributor-only grants of IP, ad-hoc meeting and internal debate mechanisms, and attract only those interested in working on solutions in a new problem space. In functioning SDOs, such "fail-fast" groups naturally become feeders for chartered Working Groups, iterating on problems and solutions at a rate which is not possible under the plodding bureaucracy of a chartered Working Groups's minuted and agenda-driven meeting cadence.

And that's why these sorts of groups are a first priority for sabotage by fifth columnists. The usual tactics deployed to subvert incubation include:

• Aspersions of bad faith by those working in incubation venues, either on the grounds that the groups are "amateur", "not standards-track",⁶ or "do not have the right people."
• Avoidance of engagement in incubation groups, robbing them of timely feedback while creating a self-fulfilling "lack of expertise" critique.
• Citing a high fraction failed designs within these groups as an indicator that they are not useful, obscuring the reality that the entire point of incubation is to fail fast and iterate furiously.⁷
• Accuse those who implement incubated proposals of "not following the process", "ignoring standards", or "shipping whatever they want"; twisting the goals of those doing design in the open, in good faith, under the SDO's IP umbrella.
• Demanding formalities akin to chartered Working Groups to slow the pace of design progress in incubation venues that are too successful to ignore.

The fifth columnist also works behind the scenes to reduce the standing and reputation of incubation groups among the SDO's grandees, claiming that they represent a threat to the stability of the overall organisation. Because that constituency is largely divorced from the sausage-making, this sort of treachery works more often than it should, causing those who want to solve problems to burn time defending the existence of venues where real progress is being made.

Survivorship Bias and The Problem of Big, Old Rooms

The picture presented this far is of Working Groups meeting in The Upside Down. After all, it's only web developers who can provide a real test of a design, or even the legitimacy of a problem.

This problem becomes endemic in many groups, and entire SDOs can become captured by the internal dramas and preferences of implementers, effectively locking customers out. Without more dynamic, fail-fast forums that enable coalitions of the willing to design and ship around obstructionists, working groups can lay exclusive claim to important technologies and retreat into irrelevance without paying a reputational cost.

The alternative — hard forking specifications — is a nuclear option. The fallout can easily blow back into the camp of those launching a fork, and the effort involved is stupendous. Given the limited near-term upside and unclear results, few are brave or foolish enough to consider forking to route around a single intransigent party.

This feeds the eclipse of an SDO's relevance because legitimacy deficits become toxic to the host only slowly. Risk of obsolescence can creep unnoticed until it's too late. As long as the ancient forms and traditions are followed, a decade or more can pass before the fecklessness of an important group rises to the notice of anyone with the power to provoke change. All the while, external observers will wonder why they must resort to increasingly tall piles of workarounds and transpilers. Some may even come to view deadening stasis, incompatibility, and waste as the natural state of affairs, declining to invest any further hope for change in the work of SDOs. At this point, the fifth columnist has won.

One of the self-renewing arrows in the fifth column's arsenal is the tendency of large and old working groups to indulge in survivorship bias.

Logically, there's no reason why folks whose designs won a lottery in the last round of market jousting⁸ should be gatekeepers regarding the next tranche of features. Having proposed winning designs in the past is not, in itself, a reliable credential. And yet, many of these folks become embedded within working groups, sometimes for decades, holding sway by dint of years of service and interpersonal capital. Experience can be helpful, but only when it is directed to constructive engagement, and too many group chairs allow bad behavior, verging on incivility, at the hands of la vieille garde. This, of course, actively discourages new and important work, and instead clears the ground for yet more navel-gazing.

This sort of in-group/out-group formation is natural in some sense, and even folks who have loathed each other from across a succession of identically drab conference rooms for years can find a sort of camaraderie in it. But the social lives of habitual TPAC and TC39 attendees are no reason to accept unproductive monopolies on progress; particularly when the folks in those rooms become unwitting dupes of fifth columnists, defending the honour of the group against those assailing it for not doing enough.

The dysfunctions of this dynamic mirrors those of lightly moderated email lists: small rooms of people all trying to solve the same problem can be incredibly productive, no matter how open. Large rooms with high alignment of aims can make progress if leadership is evident (e.g., strong moderation). What is reliably toxic are large, open rooms with a mix of "old timers" who are never moderated and "newbies" who have no social standing. Without either a clear destination or any effective means of making decisions, these sorts of venues become vitriolic over even the slightest things. As applied to working groups, without incredibly strong chairing, interpersonal dynamics of long-standing groups can make a mockery of the responsibilities resting on the shoulders of charter. But it's unusual for anyone on the outside to get any the wiser. Who has time to decipher meeting minutes or decode in-group shorthands?

And so it is precisely because fifth columnists can hire old timers⁹ that they are able to pivot groups away from addressing pressing concerns to the majority of the ecosystem, particularly in the absence of functional incubation venues challenging sclerotic groups to move faster.

Marketing Gridlock As Thoughtfulness

One useful lens for discussing the fifth column problem is the now-common Political Science analysis of systems through "veto points" or "veto players" (Tsebelis, '95; PDF):

Policy stability is different from both government stability and regime stability. In fact ... they are inversely related: policy stability causes government or regime instability. This analysis is based on the concept of the veto player in different institutional settings.

If we substitute "capability stability" for "policy stability" and "platform relevance" for "government/regime stability," the situation becomes clear:

Capability stability is different from platform relevance. In fact ... they are inversely related: capability stability causes platform irrelevance.

Any platform that cannot grow to incorporate new capabilities, or change to address pressing problems, eventually suffers irrelevance, then collapse. And the availability of veto points to players entirely hostile to the success of the platform is, therefore, an existential risk¹⁰ — both to the platform and to the SDOs that standardise it, not to mention the careers of developers invested in the platform.

This isn't hard to understand, so how does the enterprising fifth columnist cover their tracks? By claiming that they are not opposed to proposals, but that they "need work," without either offering to do that work, develop counter-proposals, or make any commitment to ship any version of proposals in their own products. This works too often because a pattern of practice must develop before participants can see that blockage is not a one-off rant by a passionate engineer.

Participants are given wide berths, both because of the presumption of voluntarity implementations,¹¹ and the social attitudes of standards-inclined developers. Most SDO participants are community-minded and collaboration-oriented. It's troubling to imagine that someone would show up to such a gathering without an intent to work to solve problems, as that would amount to bad faith. But it has recurred frequently enough that we must accept it does happen. Having accepted its possibility, we must learn to spot the signs, remain on guard, and call it out as evidence accumulates.

The meta-goal is to ensure no action for developers, with delay to the point of irrelevance as a fallback position, so it is essential to the veto wielder that this delay be viewed as desirable in some other dimension. If this sounds similar to "but neighbourhood character!" arguments by NIMBYs offer, that's no accident. Without a valid argument to forestall efforts to solve pressing problems, the fifth column must appeal to latent, second-order values that are generally accepted by the assembled to pre-empt the first-order concern. This works a shocking fraction of the time.

It works all the better in committees with a strong internal identity. It's much easier to claim that external developers demanding solutions "just don't get it" when the group already views their role as self-styled bulwarks against bad ideas.

When Is A "Consensus" Not Consensus?

The final, most pernicious, building block of Working Group decay is the introduction of easy vetoes via consensus decision-making. When vetoes are available to anyone in a large group at many points, the set of proposals that can be offered without a presumption of failure shrinks to a tiny set, in line with the findings of Tsebelis.

This is not a new problem in standards development, but the language gets muddy. I perceive two distinct versions:

• Strong Consensus refers to working modes in which the assent of every participant is affirmatively required to move proposals forward.
• Weak Consensus are modes in which preferences are polled, but "the sense of the room" can carry a proposal forward over even strenuous objections by small minorities.

Every long-term functional SDO operates by some version of Weak Consensus. The IETF bandies this about so often that the phrase "rough consensus and running code" is synonymous with the organisation.

But not every group within these SDOs are chaired by folks willing to overrule objectors. In these situations, groups can revert to de facto strong consensus, which greatly multiplies the number of veto holders. Variations on this theme can be even less disciplined, with only an old guard having effective veto power, whilst newer participants may be more easily overturned.

Strong consensus is the camel's nose for long-term gridlock. Like unmoderated mailing lists, things can spiral without anyone quite knowing where the error was made. Small groups can start under strong consensus out of a sense of mutual respect, only to find it is nearly impossible to revoke a veto power once handed out. A sense of fair play may cause this right to be extended to each new participant, and as groups grow, affiliations change, and interests naturally diverge, it may belatedly dawn on those interested in progress that the very rooms where they once had so much luck driving things forward have become utterly dysfunctional. And under identical rules!

Having found the group no longer functions, delegates who have invested large portions of their careers to these spaces have a choice: they can acknowledge that it is not working and demand change, becoming incredibly unpopular amongst their closest peers in the process. Or they can keep their heads down and hope for the best, defending the honour of the group against attacks by "outsiders". Don't they know whose these people are?

Once it sets in, strong consensus modes are devilish to unpick, often requiring a changing of the guard, both among group chairs and influential veto-wielders. Groups can lose internal cohesion and technical expertise in the process, heaping disincentive to rock even the most unproductive boats.

Defences Against Fifth Columns

The ways that web ecosystem SDOs and their participants can guard against embrittlement and fracture from the leeching effects of fifth columns are straightforward, if difficult to pull off socially:

• Seek out and remove strong consensus processes.

  The timeless wisdom of weak consensus is generally prescribed by process documents governing SDOs, so the usual challenge is enforcement. The difficulty in shaking strong consensus practices is frequently compounded by the status of influential individuals from important working groups who prefer it. Regardless, the consequences of allowing strong consensus to fester in rooms big enough to justify chairing is dire, and it must be eliminated root and branch.

• Aggressively encourage "counterproposal or GTFO" culture.

  Fifth columnists thrive in creating ambiguity for the prospects of meaningful proposals while paying no cost for "just asking questions." This should be actively discouraged, particularly among implementers, within the social compact of web SDOs. The price for imposing delay must be higher than having vague "concerns".

• Require Working Groups to list incubators they accept proposals from. Require they prove it.

  Many groups that fifth columnists exploit demonstrate a relative imperviousness to new ideas through a combination of social norms and studious ignorance. To break this pattern, SDOs should require all re-charters include clear evidence of proposals coming from outside the group itself. Without such collateral, charters should be at risk.

• Defend incubators from process attacks.

  Far from being sideshows, incubation venues are the lifeblood of vibrant SDOs. They must be encouraged, nurtured, and highlighted to the membership as essential to the success of the ecosystem and the organisation.

  In the same vein, process shenanigans to destabilise successful incubators must be fended off; including but not limited to making them harder to join or create, efforts to deny their work products a seat in working group chartering, or tactics that make their internal operations more veto-centric.

It takes a long time, but like the gravitational effects of a wandering planet out in the OORT cloud, the informational content of the fifth columnist's agenda eventually becomes legible by side effect. Because an anti-web agenda is easy to pass off under other cover, it requires a great number of observations to understand that this part of the committee does not want the platform to evolve. From that point forward, it becomes easier to understand the information being communicated as noise, rather than signal.

Once demonstrated, we must route around the damage, raising the cost of efforts to undermine the single most successful standards-based ecosystem of our lifetimes; one that I believe is worth defending from insider threats as well as external attack.

FOOTNOTES

1. The most substantial periods of institutional decrepitude in web standards are highly correlated with veto players (vendors with more than ~10% total share) walking away from efforts to push the web forward.

   The most famous period of SDO decay is probably the W3C's troubled period after Microsoft disbanded the Internet Explorer team after IE 6.0's triumphant release in 2001. Even if folks from Microsoft continued to go to meetings, there was nobody left to implement new or different designs and no product to launch them in.

   Standards debate went from pitched battles over essential features of systems being actively developed to creative writing contests about futures it might be nice to have. Without the disciplining function of vendors shipping, working groups just become expensive and drab pantomimes.

   With Microsoft circa 2002 casting the IE team to the wind and pivoting hard to XAML and proprietary, Windows-centric technologies, along with the collapse of Netscape, the W3C was left rudderless, allowing it to drift into failed XHTML escapades that inspired revulsion among the remaining staffed engine projects.

   This all came to a head over proposed future directions at 2004's Web Applications and Compound Document Workshop. WHATWG was founded in the explosion's crater, and the rest is (contested) history.

   The seeds of the next failure epoch were planted at the launch of the iOS App Store in 2008, where it first became clear that other "browsers" would be allowed on Cupertino's best-selling devices, but not if they included their own engines. Unlike the big-bang of Microsoft walking away from browsers for 3+ years, Apple's undermining of the W3C, IETF, and ECMA become visible only gradually as the total global market share of mobile devices accelerated. Apple also "lost" its early lead in the smartphone market share as Android ate up the low end's explosive growth. The result was a two-track mobile universe, where Apple retained nearly all influence and profits, whilst most new smartphone users encountered the predations of Samsung, HTC, LG, Xiaomi, and a hundred other cut-price brands.

   Apple's internal debates about which platform for iOS was going to "win" may have been unsettled at the launch of the App Store¹³, but shortly thereafter the fate of Safari and the web on iOS was sealed when Push Notifications appeared for native apps but not web apps.

   Cupertino leveraged its monopoly on influence to destroy the web's chances, while Mozilla, Google, and others who should have spoken up remained silent. Whether that cowardice was borne of fear, hope, or ignorance hardly matters now. The price of silence is now plain, and the web so weakened that it may succumb entirely to the next threat; after all, it has no champions among the megacorps that have built their businesses on its back.

   First among equals, Apple remains at the vanguard of efforts to suppress the web, spending vast sums to mislead web developers, regulators, legislators, and civil society. That last group uncomfortably includes SDOs, and it's horrifying to see the gaslighting plan work while, in parallel, Cupertino sues for delay and offers easily disproven nonsense in rooms where knowing misrepresentation should carry sanction.

   All this to preclude a competent version of the web on iPhones, either from Apple or (horrors!) from anyone else. Query why. ⇐

2. The market share at which any browser obtains "blocking share" is not well theorized, but is demonstrably below 5% for previously dominant players, and perhaps higher for browsers or brands that never achieved market plurality status.

   Browsers and engines which never gain share above about 10% are not considered "relevant" by most developers and can be born, live, and die entirely out of view of the mainstream. For other players, particularly across form-factors, the salience of any specific engine is more contextual. Contractual terms, tooling support, and even the personal experience of influential developers all play a role. This situation is not helped by major sites and CDNs — with the partial exception of Cloudflare — declining to share statistics on the mix of browsers their services see.

   Regardless, web-wide market share below 2% for any specific version of any engine is generally accepted as irrelevance; the point at which developers no longer put in even minimal effort to continue to support a browser except with "fallback" experiences. ⇐

3. It's not an exaggeration to suggest that the W3C, IETF, and ECMA have been fundamentally undermined by Apple's coercion regarding browser engines on iOS, turning the entire organisation into a sort of Potempkin village with semi-independent burgs taking shape on the outskirts through Community Groups like the WICG, which Apple regularly tries to tear down through procedural attacks it hopes the wider community will not trace back to the source.

   When competitors cannot ship their best ideas, the venues where voluntary standards are codified lose both their role as patent-pooling accelerators for adoption, as well as their techno-social role as mediators and neutral ground.

   The corporeal form continues long after the ghost leaves the body, but once the vivvifying force of feature autonomy is removed, an SDO's roof only serves to collect skeletons, eventually compromising the origanisation itself. On these grounds, self-aware versions of the W3C, IETF, and ECMA would have long ago ejected Apple from membership, but self-awareness is not their strong suit. And as long as the meetings continue and new drafts are published, it hardly deserves mention that the SDO's role in facilitating truly disruptive change will never again be roused. After all, the membership documents companies sign do not require them to refrain from shivving their competition; only that everyone keep their voices down and the tone civil.

   What's truly sad is how few convening services or reading the liturgy from the pews seem disturbed that their prayers can never again be heard. ⇐

4. This is about the point where folks will come crawling out of the walls to tell stories about IBM or Rambus or Oracle or any of the codec sharks that have played the heel in standards at one point or another. Don't bother; I've got a pretty full file of those stories, and I can't repeat them here anyway. But if you do manage to blog one of them in an entertaining way without getting sued, please drop a line. ⇐

5. You know, in case you're wondering what CSS WG was doing from '04-'21. I wonder what changed? ⇐

6. It's particularly disingenuous for fifth columnists to claim proposals they don't like are "not standards track" as they know full-well that the reason they aren't being advanced within chartered working groups is their own opposition.

   The circularity is gobsmacking, but often works. This reduces pressure fifth columnists from credulous web developers. Excusemaking is only possible because other vendors fail to call bullshit. Apple, e.g., would not be getting away with snuffing out the mobile web's chances were it not for a cosy set of fellow travellers at Mozilla and Google. ⇐

7. Internet APIs and protocols do not spring fully-formed from the head of Zeus.

   Getting to good, or even good-enough, requires furious iteration, and that means testing and prodding at proposals. The only way to get miles under a proposal is to try things, and that's what incubation venues specialise in. It is not a sign of failure that many proposals change shape in response to feedback, or that certain evolutionary branches are abandoned altogether. Much the opposite, in fact.

   It is only by trying, testing, iterating, and yes, abandoning many designs that we arrive at productive progress in web specs. Anyone who tells you differently is carrying water for fifth columnists and should be put on notice. They may not personally intend to undermine the web's future, but that's what treating iteration in design as failure does by proxy. ⇐

8. Most Web API design processes cannot claim any kinship to the scientific method, although we have tried mightily to open a larger space for testing of alternative hypotheses within the Chromium project over the past decade.

   Even so, much of the design work of APIs on the web platform is shaped by the specific and peculiar preferences of powerful individuals, many of whom are not and have never been working web developers. ⇐

9. Hiring "known quantities" to do the wrangling within a Working Group you want to scupper is generally cheaper than doing constructive design work, so putting in-group old-timers on the payroll is a reliable way for fifth columnists to appear aligned with the goals of the majority while working against them in practice. ⇐

10. One rhetorical mode for those working to constrain the web platform's capabilities is to attempt to conflate any additions with instability, and specifically, the threat that sites that work today will stop working tomorrow. This is misdirection, as stability for the ecosystem is not a function of standards debates, but rather the self-interested actions of each vendor in the market.

    When true browser competition is allowed, the largest disciplining force on vendor behaviour is incompatibility. Browsers that fail to load important web pages lose share to those that have better web compatibility. This is as close as you can get to an iron law of browser engineering, and every vendor knows that their own engine teams have spent gargantuan amounts of time and money to increase compatibility over the years.

    Put more succinctly, backwards compatibility on the web is not seriously at risk from capability expansions. Proposals that would imperil back compat¹² are viewed as non-starters in all web standards venues, and major schisms have formed over proposed, incompatible divergence, with the compatibility-minded winning nearly every skirmish.

    No SDO representatitive from these teams is ignorant of these facts, and so attempts to argue against solving important problems by invoking the spectre of "too much change, too fast" or "breaking the web" are sleights of hand.

    They know that most web developers value stability and don't understand these background facts, creating space for a shell game in which the threat of too much change serves to obsure their own attempts at sabatoge through inaction. Because web standards are voluntary and market share matters tremendously to every vendor, nothing that actually breaks the web will be allowed to ship. So armed, you can now call out this bait-and-switch wherever it appears. Doing so is important, as the power to muddy these waters stems from the relative ignorance of web developers. Educating them to the real power dynamics at work is our best bullwark against the fifth column. ⇐

11. There's no surer sign of the blindness many SDO participants exhibit toward the breakage of the voluntary implementation regime than that they extend deference on that basis to Apple.

    Cupertino's SDO delegates do not bear a heightened presumption that they will implement as soon as other ship. To the contrary, Apple have so thoroughly lowered expectations that nobody expects timely feedback on proposals, let alone implmementation commitments. Even when Apple is the last holdout. Cupertino sullies the brands they force to use WebKit's worst-of-the-worst implementation. It has been going on so long that it is now simply accepted as the status quo.

    This is entirely backwards, and Apple's representatitives should, instead, be expected to provide implementation timlines for features shipped by other vendors. God knows they can afford it.

    Until such time as Apple allows engine competition worldwide, it's only fair to expect (and demand) parity. Every Apple employee should feel the heat of shame every as they mutter "Apple does not comment on future product releases" while indefensibly harming the web. ⇐

12. The browser and web infrastructure community have implemented large transitions away from some regretted technologies, but the care and discipline needed to do this without breaking the web is the stuff of legend. Big ones that others should write long histories of are the sunsetting of AppCache and the move away from unencrypted network connections.

    Both played out on the order of half a decade or more, took dozens of stakeholders to pull off, and were games of inches adding up to miles. New tools like The Reporting API, Deprecation Reports, and Reverse Origin Trials had to be invented to augment the "usual" tool bag of anonymised analytics trawls, developer outreach, new limits on unwanted behaviour, and nudging UI.

    In both cases (among many more small deprecations we have done over the years), the care taken ensured that only a small fraction of the ecosystem was impacted at any moment, lowering the temperature and allowing for an orderly transition to better technology. ⇐

13. Your correspondent has heard different stories from folks who had reason to know about the period from '08-'10 when Apple pulled its foot off the gas with Safari.

    Given the extreme compartmentalisation of Apple's teams, the strategic import of any decision, and the usual opacity of tech firms around funding levels ("headcount") to even relatively senior managers, this is both frustrating and expected.

    The earliest dating puts the death of the web as "Plan A" before Steve Jobs's announcement of the iPhone at Macworld in June 2007. The evidence offered for this view was that a bake off for system apps and the home screen launcher had already been lost by WebKit. Others suggest it wasn't until the success of the App Store in '09 and '10 that Apple began to pull away from the web as a top-tier platform. Either way, it was all over by early 2011 at the very latest.

    WebKit would never again be asked to compete as a primary mobile app platform, and skeletal funding for Safari ensured it would never be allowed to break out of the OS's strategic straightjacket the way IE 4-6 had. ⇐

Frances has urged me for years to collect resources for folks getting into performance and platform-oriented web development. The effort has always seemed daunting, but the lack of such a list came up again at work, prompting me to take on the side-quest amidst a different performance yak-shave. If that sounds like procrastination, well, you might very well think that. I couldn't possibly comment.

The result is a new links and resources page page which you can find over in the navigation rail. It's part list-of-things-I-keep-sending-people, part background reading, and part blogroll.

The blogroll section also prompted me to create an OPML export , which you can download or send directly to your feed reader of choice.

The page now contains more than 250 pointers to people and work that I view as important to a culture that is intentional about building a web worth wanting. Hopefully maintenance won't be onerous from here on in. The process of tracking down links to blogs and feeds is a slog, no matter how good the tooling. Very often, this involved heading to people's sites and reading the view-source://

FOMO

Having done this dozens of times on the sites of brilliant and talented web developers in a short period of time, a few things stood out.

First — and I cannot emphasise this enough — holy cow.

The things creative folks can do today with CSS, HTML, and SVG in good browsers is astonishing. If you want to be inspired about what's possible without dragging bloated legacy frameworks along, the work of Ana Tudor, Jhey, Julia Miocene, Bramus, Adam, and so many others can't help but raise your spirits. The CodePen community, in particular, is incredible, and I could (and have) spend hours just clicking through and dissecting clever uses of the platform from the site's "best of" links.

Second, 11ty and Astro have won the hearts of frontend's best minds.

It's not universal, but the overwhelming bulk of personal pages by the most talented frontenders are now built with SSGs that put them in total control. React, Next, and even Nuxt are absent from pages of the folks who really know what they're doing. This ought to be a strong signal to hiring managers looking to cut through the noise.

Next, when did RSS/Atom previews get so dang beautiful?

The art and effort put into XSLT styling like Elly Loel's is gobsmacking. I am verklempt that not only does my feed not look that good, my site doesn't look that polished.

Last, whimsy isn't dead.

Webrings, guestbooks, ASCII art in comments, and every other fun and silly flourish are out there, going strong, just below the surface of the JavaScript-Industrial Complex's thinkfluencer hype recycling.

And it's wonderful.

My overwhelming feeling after composing this collection is gratitude. So many wonderful people are doing great things, based on values that put users first. Sitting with their work gives me hope, and I hope their inspiration can spark something similar for you.