Web standard consortiums are a game with Chrome as the monopoly man

Web standard consortiums are a game with Chrome as the monopoly man

Speakers: Simon Wijckmans, Founder & CEO, Seaside

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=2qi8Jm2toK8

Overview

In his compelling BSides SF talk, "Web standard consortiums are a game with Chrome as the monopoly man," Simon Wijckmans, founder and CEO of client-side web security company Seaside, delivers a critical examination of the current state of web standards bodies, particularly the World Wide Web Consortium (W3C). Wijckmans argues that despite its foundational role in standardizing the internet, the W3C's processes are hampered by the disproportionate influence of large technology companies, primarily Google, which controls the dominant Chromium browser engine. This imbalance, he contends, stifles innovation, leads to the adoption of compromised or ineffective standards, and ultimately creates a less consistent, predictable, and secure web.

Wijckmans' central thesis is that the very mechanisms designed to foster collaboration and consensus within the W3C have become bottlenecks, leading to a "no by default" culture that benefits established players over nascent innovators. He highlights a critical disconnect between those who write the specifications and the developers who actually implement and use them in production environments. The talk serves not just as a critique, but as a passionate call to action, urging startups and individual developers, especially those in the security field, to actively participate in standards development to inject fresh perspectives, challenge stagnation, and ensure the web continues to evolve in a robust and secure manner.

Background

▶ Watch: Introduction, speaker, and talk's controversial title (0:00)

The genesis of the World Wide Web Consortium (W3C) lies in a vision to safeguard the internet as a freely accessible and standardized environment. Following the internet's invention, Tim Berners-Lee recognized the imperative to standardize its underlying technologies to prevent fragmentation and commercial enclosure. The W3C was established to serve as a neutral ground where organizations with significant stakes in the internet could collaborate on technical specifications, aiming to make the web "better" – a term whose interpretation has become increasingly contentious.

Membership in the W3C is open to companies, non-profits, universities, research institutions, and industry groups willing to contribute. The consortium operates through several mechanisms: Working Groups develop technical specifications, Community Groups offer open forums for exploring new ideas (accessible to non-members), and Technical Architecture Groups (TAG) and Advisory Committees (AC) comprise elected specialists. However, Wijckmans points out significant structural challenges. Time investment in these complex, often bureaucratic processes is substantial, typically favoring larger technology companies that can allocate dedicated headcount. This inherently narrows the pool of contributors, often resulting in a demographic of "later in career" individuals who may not be at the forefront of real-world web development.

A critical shift in the web landscape has exacerbated these issues: the overwhelming dominance of the Chromium browser engine. While legally not a monopoly, Chromium powers the vast majority of web browsers, including Google Chrome, Microsoft Edge, Brave, and Opera. This market share grants Google immense power in shaping web standards, as browser vendors are the ultimate implementers of these specifications. Wijckmans emphasizes that web developers optimize for the most used browser, effectively aligning with Chromium's capabilities. This concentration of power, combined with the difficulty of achieving consensus among diverse perspectives, creates an environment where innovation can easily be stalled by a "no" that simply avoids additional work for entrenched players.

Key Findings

▶ Watch: Challenges of W3C participation for smaller entities (3:10)

Wijckmans' talk meticulously details several key findings that illustrate the challenges within web standards consortiums. Foremost among these is the disproportionate influence of Google. He states that at major W3C events, approximately 40% of attendees are Google employees. These individuals, encouraged to advocate for their perspectives without reservation, collectively wield substantial power. This creates an environment where smaller entities, like Wijckmans' own startup, often find themselves isolated, surrounded by giants like Microsoft and Meta, making it incredibly difficult to push for changes that might not align with big tech's immediate interests.

A significant problem identified is the "no by default" attitude prevalent among many contributors. Wijckmans argues that time is a scarce asset, and for many, saying "no" to a proposed standard or feature simply means less work. This can lead to endless arguments, as those blocking progress are often not the ones who would ultimately implement the work. Compounding this issue is a critical disconnect: many individuals contributing to the specifications "don't often use the technology, the very thing that they are writing the spec for." Wijckmans cites Content Security Policies (CSP) as an example, noting that many spec writers have never deployed CSP in a real production environment with live traffic, perhaps only on a personal blog, which vastly differs from enterprise-level complexity. This lack of practical experience means "acceptable feedback comes in totally unacceptable forms," such as "I don't think I would use it," which lacks substantive technical grounding but still influences others to oppose proposals.

The cumulative effect of this process, Wijckmans explains, is that innovative proposals are often compromised beyond recognition, transforming from a "Chihuahua" into a "camel." The original vision is diluted by endless iterations and compromises, resulting in standards that are "partially available, some browser support, some server supported, but not a lot of adoption because nobody's really excited about it anymore." He provides several historical examples of standards that suffered this fate:

• Do Not Track: A privacy mechanism that ultimately failed due to lack of consensus and browser support.
• Content Security Policies (CSP): While critical for web security, Wijckmans suggests its implementation complexity and the challenges in real-world deployment make it widely disliked by developers.
• Web Components: A set of W3C specifications for creating reusable custom elements, which initially struggled with adoption and consistent browser support.
• P3P (Platform for Privacy Preferences Project): An early HTTP header-based standard from the late 1990s that allowed users to express privacy preferences to websites. Wijckmans highlights its prescience, noting it would be incredibly relevant today in the era of cookie banners. However, it failed due to partial commercialization (requiring an extra license on Windows servers) and being a "proactive solution to a problem that at the time wasn't an agenda item," leading to its gradual demise.

These examples underscore a pattern where the standards-setting process, instead of fostering robust and widely adopted solutions, often yields fragmented, under-supported, or functionally diminished outcomes.

Technical Deep Dive

▶ Watch: Chromium's dominance and 'winner takes all' web ecosystem (4:10)

The technical deep dive into web standards, as presented by Wijckmans, isn't about a specific protocol or code snippet, but rather a detailed exposition of the arduous, multi-stage process required to shepherd a new specification from concept to adoption, and the myriad obstacles it faces. He illustrates this with a hypothetical example: a "magnificent spec" for a new image fetching method that could save 40% of bandwidth, is completely secure, and 100% backwards compatible – a "total no-brainer."

To get such a spec implemented, Wijckmans outlines a complex "supply chain" of stakeholders who must agree:

1. Browser Vendors: Primarily Google, due to Chromium's dominance. They can simply say "no" because existing image fetching methods already work, and there's little incentive for them to invest in change if it doesn't align with their strategic priorities.
2. CDN Providers: Content Delivery Networks must also agree to support the new method. Many may defer to Google, reasoning that if the dominant browser isn't interested, there won't be enough traffic to justify their investment.
3. Web Developers: Even with a small change required from developers, gaining widespread adoption is challenging. There's no central point to engage them, and they are "hell opinionated," often rejecting new approaches for "whatever freaking reason" in online forums.
4. Security Experts: The spec must be pressure-tested and gain approval from security specialists.
5. Accessibility Experts: Crucially, the accessibility implications must be considered and approved.

Wijckmans estimates this entire process takes around 18 months just to gather the necessary data, including developer and benchmark analysis, security analysis, and compatibility testing.

The most illustrative part of the technical deep dive is the "comment circus" that inevitably ensues. This phase involves a range of feedback, from constructive to outright obstructive:

• Constructive Feedback: "Have you considered edge case X or Y?" or "This conflicts with specification Y." These are valuable for refining the spec.
• Political/Business Objections: "Our business model depends on the current approach" or "We need more time to evaluate" (often an "endless response"). These comments reveal underlying commercial interests that can block progress.
• Pedantic Debates: This category highlights the frustrating minutiae that can derail momentum. Examples include:
• Naming Conventions: Developers "love that," and debates can last "months alone." Wijckmans hilariously points out the irony, asking "Who here has seen referer header?" (referring to the misspelling that became standard), highlighting how arbitrary such debates can be.
• Bikeshedding over Syntax Choices: Endless arguments over minor syntactic preferences.
• "It's an anti-pattern": This phrase, Wijckmans notes, is "thrown around all the freaking time." He vehemently challenges this, arguing that many essential web security features, by their very nature, are "anti-patterns" in terms of user experience or simplicity, but are critical for security. He cites SSL (Secure Sockets Layer), CSP (Content Security Policy), and CORS (Cross-Origin Resource Sharing) – all of which involve extra headers or configuration, making them "anti-patterns" in a strict sense, yet "hold such significant security essentials." His point is that whether something is an "anti-pattern" should not override its security or functional benefits, especially when it's an optional adoption.

Ultimately, Wijckmans laments that these arguments often occur with people who are "not the target user," further detaching the standards from real-world utility. This bureaucratic inertia and philosophical resistance, coupled with "old tooling" (often open-source, self-hosted, and globally accessible, but cumbersome) and global time zone challenges, leads to low participation in critical meetings and voting processes. He notes a "significantly larger amount of votes coming from Chinese contributors" than any other nationality combined, further underscoring the uneven distribution of influence. The system, he concludes, is fundamentally "broken," leading to a less consistent, predictable, safe, and accessible web.

Demo / Proof of Concept

▶ Watch: Spec writers' disconnect from real-world technology usage (5:50)

This talk is a conceptual analysis of the web standards ecosystem and does not include a live demonstration or a proof of concept of a specific technology or exploit. Instead, Simon Wijckmans relies on historical examples and hypothetical scenarios to illustrate the challenges and implications of the current standards-making process.

Defensive Implications

▶ Watch: Negative influence of 'unacceptable' feedback in W3C (6:15)

The defensive implications of Wijckmans' analysis are profound, particularly for security professionals and anyone invested in a robust, secure, and accessible internet. The core message is that the stagnation and compromise within web standards bodies directly lead to a "less consistent web that is less predictable, less safe, less accessible." If standards do not evolve rapidly enough to address emerging threats and technologies, defenders are left in a perpetual state of "hacking around the spec" – implementing temporary, often suboptimal, solutions to critical problems that should ideally be addressed at the foundational level.

Wijckmans highlights that many existing standards are "outdated and old and are not being changed," yet remain "a thing and will continue to be a thing." This forces security teams to build complex workarounds, diverting resources from proactive defense and leading to a fragmented security landscape. The reliance on a single dominant browser engine, Chromium, and by extension, Google, for the evolution of web standards, poses a significant single point of failure. If innovation is stifled at this level, or if Google's priorities do not align with broader web security needs, the entire web ecosystem becomes vulnerable.

The call to action for defenders is clear: active participation in standards development is not merely a nice-to-have, but a crucial defensive strategy. Security professionals are often the ones on the front lines, understanding the real-world implications of vulnerabilities, the practical challenges of implementing security policies like CSP, and the necessity of robust privacy controls. By contributing to the W3C and other relevant bodies, even with just "30 minutes per month," defenders can:

• Inject real-world expertise: Counteract the disconnect between spec writers and practitioners by providing feedback rooted in production experience.
• Challenge "no by default": Bring an "opportunity" mindset, characteristic of startups, to push past inertia and accelerate the adoption of necessary security features.
• Drive innovation: Ensure that new standards are designed with security and accessibility from the outset, rather than being retrofitted or compromised later.
• Diversify influence: Reduce the disproportionate power of a few large companies and ensure a broader range of perspectives, including those focused purely on security, are heard and integrated.

Ultimately, for the web to remain a secure and open platform, its underlying standards must be agile, responsive, and reflective of the diverse needs of its users and builders. This requires security professionals to move beyond merely consuming and reacting to standards, to actively shaping them.

Key Takeaways

• Chromium's Dominance and Google's Influence: Google, through its control of the dominant Chromium browser engine, exerts a disproportionate influence within web standards consortiums like the W3C, often leading to a "no by default" culture that stifles innovation.
• Disconnect from Real-World Usage: Many individuals contributing to web standards lack direct experience deploying and maintaining these technologies in real-world production environments, resulting in compromised or impractical specifications.
• Stagnation and Compromise: The complex, bureaucratic, and often politically charged process within standards bodies frequently dilutes innovative proposals, leading to "Chihuahua to camel" outcomes where original goals are lost, and adoption suffers (e.g., Do Not Track, P3P).
• The Urgency for Startup Participation: Startups and individual developers, especially those focused on security, are uniquely positioned to inject fresh perspectives, user-centric thinking, and a bias towards action into standards discussions, counteracting the prevailing inertia.
• Defenders Must Contribute: Security professionals have a critical responsibility to engage with standards bodies to ensure the web remains consistent, predictable, safe, and accessible, actively shaping foundational technologies rather than merely reacting to outdated or compromised specifications.
• Risk of Stagnation: Without broader participation and faster execution, the web risks becoming like legacy operating systems, with foundational knowledge lost and its evolution becoming entirely reliant on a single, dominant entity.

About the Speaker(s)

Simon Wijckmans is the founder and CEO of Seaside, a company focused exclusively on client-side web security. His work at Seaside involves monitoring malicious dependencies within browsers, understanding their behavior (whether from open-source components, marketing tools, or ads), and detecting fraud. He also specializes in fingerprinting and analyzing user interactions with web applications to distinguish human users from AI agents and identify malicious activities. Though he jokingly mentions being "accidentally born in Belgium," Simon has lived outside of Belgium since he was 18, bringing a broad perspective to his work and advocacy for a better web.