Google switching Chrome to its homemade BoringSSL to make its browser safer
Google has exhausted a lot of resources patching up OpenSSL, so much in fact, the company has elected to create its own fork aptly named BoringSSL. Preparing to move the platform to Chrome …
Context & Ripple Effects
Google first unveiled BoringSSL in June 2014 as an independent fork of OpenSSL, and this move is the payoff: the fork graduates from experiment to production, with Chrome preparing to switch its TLS stack to Google's own code. The stated reason is exhaustion — patching upstream OpenSSL consumed more resources than maintaining a trimmed-down fork built for one consumer's needs.
The decision extends a pattern visible since at least 2012, when Google detailed its Chrome security-testing technology: the company treats browser security as infrastructure it must own end-to-end rather than inherit from a community project it only partially controls.
First-order effects
- Chrome's TLS handling moves onto code Google alone maintains, so fixes ship on Chrome's release cadence instead of waiting on upstream OpenSSL releases — and OpenSSL loses one of its highest-profile corporate contributors and auditors.
Second-order effects
- Other large OpenSSL consumers face the same calculus Google just made explicit, forcing them either to fund upstream maintenance or follow the fork path — splitting effort that previously pooled in one library.
Third-order effects
- If the biggest platform vendors each maintain their own hardened crypto stacks, shared open-source security infrastructure drifts toward underfunded commons status, with the burden of keeping the web's encryption current falling on whoever ships the browsers.
The trend: Platform-scale vendors are pulling critical security dependencies in-house, trading community-shared maintenance for direct control over their own attack surface.