The Browser Gatekeeping Problem

Why the "Open Web" Is Neither Open Nor Free

February 2026 | Reading time: ~18 minutes

I. The Illusion of Browser Security as Pure Engineering

The standard narrative goes like this: browsers restrict direct network access, enforce sandboxing, and limit what web applications can do - all in the name of security. The Zero-Trust model. Defense in depth. Protect the user.

And on the surface, this is technically sound. Without server-side consent mechanisms, a raw UDP socket in the browser would turn every website into a potential SSRF weapon - scanning internal networks, probing routers, attacking local databases. The argument is real, and the engineering concern is legitimate.

But here's where the narrative falls apart: the same companies enforcing these restrictions - Google, Microsoft, Apple - are simultaneously running telemetry pipelines, background processes, screen capture features, photo scanning systems, and tracking layers that would make any self-respecting firewall administrator weep. The browser locks the window while the operating system leaves the front door wide open.

This isn't hypocrisy by accident. It's hypocrisy by design.

II. WebSocket and WebTransport: Not What They Seem

When challenged on browser networking limitations, defenders of the status quo point to WebSockets and WebTransport. "We already have sandboxed TCP and UDP," they say. "What more do you need?"

But this misrepresents what these APIs actually are.

With WebSocket or WebTransport, your code never touches a socket. The browser makes the connection on your behalf. The browser decides whether the destination is allowed. The browser performs the handshake. The browser validates certificates. The browser mediates every byte of data between your application and the network.

You don't have a network connection. You have a request to the browser, which may or may not grant you a proxied, filtered, controlled channel to a server that has explicitly opted in to receiving your traffic.

This means:

• You cannot implement your own transport protocol.
• You cannot design your own handshake mechanism.
• You cannot perform transport-level cryptography on your own terms.
• You cannot optimize the connection for your specific use case.
• You cannot build a packet re-acquisition protocol tailored for real-time video and audio.

You sit on top of HTTP-based APIs forever, unable to innovate below the abstraction layer the browser has decided you're allowed to see.

For real-time media applications, this is crippling. Video and audio streaming require precise control over packet loss recovery, jitter compensation, and quality adaptation. WebRTC handles some of this, but it's the browser's implementation, not yours. WebTransport gives you unreliable datagrams, but all recovery logic must be built on top of HTTP semantics - an absurd constraint for latency-sensitive applications.

Case Study: SRT vs. Low Latency HLS - The Hack That Proves the Ceiling

The contrast between native and browser-based streaming protocols illustrates this problem perfectly.

SRT (Secure Reliable Transport) is an open-source protocol built on UDP with selective ARQ (Automatic Repeat reQuest). The receiver detects missing packets and requests retransmission of only those specific packets, with timing constraints matched to the content's latency budget. The sender controls FEC (Forward Error Correction) at the transport level. Congestion feedback loops are tuned per-connection. The result: sub-second live streaming with robust packet recovery, used in broadcast production worldwide.

Now look at what Apple had to build to achieve something vaguely comparable inside the browser's HTTP prison. Low Latency HLS (LL-HLS) is a masterwork of engineering - and a monument to the absurdity of the constraints it operates under. To get TCP/HTTP to behave like a real-time transport, Apple had to invent:

• Partial Segments - because standard HLS segments (6 seconds) are far too long for low latency, so they had to subdivide them into sub-second chunks delivered over HTTP.
• Blocking Playlist Reload - a long-polling hack where the client holds an HTTP connection open until the next segment is available. This is necessary because HTTP has no native push mechanism - the client must ask, then wait.
• Preload Hints - metadata telling the CDN to prefetch segments before they're complete, because by the time a segment is finished and the playlist is updated and the client polls for it, the latency budget is already blown.
• Delta Playlist Updates - because the playlist changes so frequently at low latency that downloading the entire playlist each time adds unacceptable overhead.

The irony deepens: HTTP/2 Server Push was supposed to solve the "client must poll" problem. A server could proactively send playlist updates and segments to the client without waiting for a request. It was the one HTTP-level feature that could have made browser-based low-latency streaming architecturally sound. Google killed it. Chrome removed Server Push support in 2022, citing low adoption - adoption that was low precisely because Chrome's own implementation was unreliable and poorly optimized. The feature that could have closed the gap between browser and native streaming was eliminated by the browser vendor that controls the platform.

The result? LL-HLS achieves 2-5 seconds of latency on a good day - and only when the entire CDN infrastructure is purpose-built to support it. SRT achieves sub-second latency over commodity internet connections with a fraction of the complexity. One protocol works with the network. The other fights against the browser to pretend the network doesn't exist.

AV player and streaming solution vendors hit this wall constantly. Every generation of browser-based players runs into the same architectural ceiling, producing increasingly elaborate workarounds that never quite close the gap. Nobody has shipped anything genuinely innovative in browser-based real-time media - not because the engineers aren't capable, but because the platform structurally will not allow it.

III. CORS: A Business Filter, Not a Security Mechanism

CORS (Cross-Origin Resource Sharing) is routinely cited as a critical security feature. In reality, it's a server-side consent mechanism that controls which browser-based origins may access a resource.

It does not protect against cyberattacks. An attacker making requests from a server bypasses CORS entirely - it's a browser-only restriction. Any tool outside the browser (curl, a Python script, a native application) ignores CORS completely.

CORS protects against cross-origin resource abuse at the business logic level - preventing one website from making authenticated requests to another on behalf of the user. This is a valid concern, but it's an application-layer policy, not a network security mechanism. Conflating it with Zero-Trust architecture or cyber threat mitigation is technically dishonest.

Historical Precedent: Novell NetWare's Client-Trust Model

CORS is not a new idea. It's a recycled mistake.

In the early 1990s, Novell NetWare dominated corporate networking. Its file security model relied on trustee rights - access control lists stored on the server - but critically, the enforcement depended on the client behaving honestly. The NetWare client software respected the permissions. The server trusted that the client was who it claimed to be. Authentication was thin. The security boundary was, in practice, the client application itself.

This worked exactly as long as everyone used the official Novell client. The moment someone connected with an alternative client, sniffed packets, or reverse-engineered the protocol, the entire permission model collapsed. The server had the rules. But it had no way to enforce them against a client that chose not to play along.

Novell learned this lesson the hard way. By the late 1990s, they moved to NDS (Novell Directory Services) with Kerberos-based authentication and server-side enforcement that didn't trust the client at all. The industry consensus was clear: security that depends on client cooperation is not security.

CORS is the same architecture, decades later. The server declares a policy (Access-Control-Allow-Origin). The browser enforces it on the client side. Any tool outside the browser - curl, a Python script, Postman, a native application, a malicious server-side proxy - ignores the policy entirely. The "protection" exists only for clients that voluntarily comply.

Novell's client-trust model is remembered as a cautionary tale in network security. CORS is the same model, celebrated as a web standard. The only difference is that the web industry hasn't had its NetWare moment yet - or more precisely, it has one every day, and just doesn't notice because the workarounds (curl, proxy servers, browser extensions) are so routine that nobody questions why they're necessary.

IV. The DRM Cartel

The browser gatekeeping problem is nowhere more visible than in DRM.

The EME (Encrypted Media Extensions) standard was supposed to be an open, pluggable interface for content decryption. In theory, any vendor could build a CDM (Content Decryption Module) and load it into any browser.

In practice, each browser accepts exactly one CDM:

There is no process, no application form, no technical pathway for an independent developer or company to build their own CDM and load it into a browser. The W3C standardized the interface. Three companies monopolized the implementation.

This isn't an open standard. It's a closed club with an open API.

Firefox's story is particularly telling. Mozilla fought against DRM in the browser for years. They argued - correctly - that it violated the principles of the open web. But when EME became a W3C standard backed by Google, Microsoft, Apple, and Hollywood, Mozilla faced a binary choice: integrate Widevine or become a browser that can't play Netflix. The EFF left the W3C in protest. Mozilla capitulated. The "open web" lost.

And here's the deeper irony: all browser-based DRM is fundamentally broken anyway. Widevine L3 (the software implementation used in browsers) runs as a user-space process. The decryption keys exist in RAM. A memory dump extracts them. This applies to Firefox, Chrome, and any other browser using software-level DRM.

The only DRM that actually works is hardware-based: Widevine L1, PlayReady SL3000, or - most securely - SimulCrypt with smart cards, where the private key never leaves the card's secure processor. The smartcard performs decryption internally. No key material is ever exposed to the host system. RAM dumps yield nothing.

Hollywood and the media cartels understood this, which is why they demanded hardware-level DRM in the first place. Browser-based DRM is theater - it doesn't stop determined pirates, but it does ensure that three companies control who may and may not build a video player for the web.

V. The Impossible Position

Add it all together and the picture becomes clear.

If you want to build a truly secure, optimized web application, you cannot:

• Access the network directly - everything is proxied through browser APIs you don't control.
• Implement your own transport protocol - you're locked into HTTP-derived semantics.
• Access cryptographic hardware - WebCrypto exists but you can't talk to a smartcard.
• Load your own DRM module - three companies decide who plays content.
• Implement your own security model - the browser decides what's "safe."
• Build a custom packet recovery protocol for real-time media - you sit on HTTP forever.

WASM was supposed to be the answer - near-native performance in the browser. But in reality, WASM is just a faster execution engine inside the same sandbox. It still can't access the network. It still can't touch the DOM directly. It still operates entirely within the browser's permission system.

The result is that any application requiring genuine security, hardware access, custom protocols, or real-time performance optimization must be a native application. The web, as a platform for serious engineering, is a dead end - not because of technical limitations that can't be solved, but because the gatekeepers have no incentive to solve them.

VI. The WASM Firewall Model: A Path Forward

There is a better model. Instead of the current whitelist approach - "you may only use these specific APIs we provide" - a policy-based model could work:

WASM gets direct network access, but a firewall-like security layer in the runtime enforces access control. Think ACLs, netfilter-style rules, rate limiting, fingerprinting detection. The application can open raw sockets, but the runtime's security policy determines what destinations are allowed, what protocols are permitted, and what rate limits apply.

This is fundamentally different from the current model:

The firewall model is more powerful, more flexible, and more honest. It acknowledges that security is about policy enforcement, not capability restriction. It's the difference between "you can't have a kitchen knife" and "you can have a kitchen knife, but here are the rules."

But this model requires browser vendors to relinquish control. And that's the real problem - not technical, but political and economic.

VII. Web vs. Native: The Unfinished War

The web's original promise was compelling: no installation, open standards, write once run everywhere. But reality has diverged so far from this vision that the promise is effectively broken.

Every serious service pushes users toward native apps. Banking, streaming, video conferencing, productivity tools - they all say "download our app for a better experience." Why? Because the browser can't do what they need.

Meanwhile, technologies like Electron and Tauri represent the worst of both worlds: a browser engine packaged as a native app, carrying all the limitations of the web with all the overhead of a native installation. It's an admission that the web isn't enough, disguised as a cross-platform solution.

The war between web and native isn't over. But the web is losing - not because native is inherently better, but because the web's gatekeepers have made it structurally impossible for the web to compete. Every capability that would make web applications competitive with native - direct network access, hardware integration, custom security models - is locked behind the browser vendor's permission structure.

The question isn't web versus native. The question is: who controls the platform you build on? On the web, it's three browser vendors. On native, it's two app store operators. Either way, you're choosing your gatekeeper, not your freedom.

VIII. Conclusion: The CRUD Ceiling

Let's say it plainly: the web, as it exists in 2026, is a CRUD platform.

It is excellent at forms, tables, dashboards, and document display. It handles CRMs, project management tools, booking systems, inventory management, admin panels, and content management perfectly well. For these use cases - create, read, update, delete against a database, rendered in a browser - the web stack is mature, well-tooled, and fit for purpose.

It is structurally incapable of anything beyond that.

Not because the engineering is impossible. But because three companies have decided that the browser's job is to mediate, restrict, and control - not to enable. Every attempt to push past the CRUD ceiling runs into the same wall: the browser won't let you touch the network, the transport layer, the hardware, or the security model. You get JavaScript APIs that wrap browser-controlled abstractions, and you are told this is sufficient.

The evidence is everywhere in this article. You cannot build SRT-class streaming in a browser - so Apple had to invent an elaborate tower of hacks called LL-HLS to get TCP/HTTP to poorly imitate what UDP does natively. Google killed HTTP/2 Server Push - the one feature that could have helped - and nobody could stop them. You cannot load your own DRM module - so three companies collect rent on every protected stream. You cannot open a filtered socket from WASM - so every application that needs real network access must be a native app. Firefox blocks port 9100 on localhost and doesn't even tell you why - you're just expected to accept that the browser knows better than you do.

The "open web" is a useful fiction. The protocols are open. The standards are mostly open. But the runtime - the browser - is controlled by three companies who decide what you can build, how you can build it, and who gets to play. This isn't a conspiracy theory. It's a business model.

As I argued in The Open Source Trap, LLMs are simultaneously commoditizing the JavaScript ecosystem that sits on top of this platform. The web's CRUD layer - the one thing browsers actually do well - is exactly the layer that AI automates most effectively. Every React frontend, every REST API, every authentication flow is pattern-matching paradise for an LLM trained on millions of identical examples. The ceiling and the floor are closing in at the same time.

This leaves the web at a crossroads with only two exits:

Exit A: Browser vendors continue restricting capabilities. WASM remains a fast calculator in a sandbox. The web retreats to what it always was underneath the hype - a document viewer with a CRUD layer bolted on. Serious applications go native. The browser becomes irrelevant for anything that matters, and the JavaScript ecosystem that LLMs have already hollowed out collapses under its own weight.

Exit B: WASM + WASI gets real capabilities - controlled network access through policy-based security, hardware interfaces, a genuine runtime that treats developers as engineers rather than children. The web becomes an actual application platform. Browser vendors lose some control but gain a platform worth controlling. Innovation returns.

Exit B requires browser vendors to relinquish gatekeeping power they've held for two decades. Exit A requires nothing - it's the default trajectory, already in motion.

The engineers who understand the layers below the browser's abstraction - who know the difference between FTP's dual-channel architecture and SFTP's single tunnel, who can build custom transport protocols, who understand why a smartcard is more secure than a software CDM, who can write C that doesn't leak memory under load - these engineers will be increasingly valuable. Not because they're smarter, but because they understand the parts of the system that the browser doesn't want you to see, and that LLMs cannot replicate.

The web isn't dying. CRUD isn't going anywhere. But the pretense that the browser is a universal application platform - that pretense is on life support, and the gatekeepers are the ones holding the plug.

February 2026 | Key Aavoja

◄ Back to: Part II - The Open Source Trap