This is what it actually took. From the person who architected and drove Chrome’s Flash deprecation from proposal to the final removal in January 2021.
Press enter or click to view image in full size
Steve Jobs didn’t kill Flash. His famous April 2010 open letter “Thoughts on Flash” made headlines and sparked a fierce public battle with Adobe, but Flash continued running on billions of devices for another decade. What actually ended Flash was something far less dramatic but infinitely more difficult: a six-year, cross-industry effort that methodically built the web platform capabilities to replace it, coordinated deprecation timelines across competing browser vendors, and managed the transition without breaking the internet.
The catalyst wasn’t philosophical. It was existential. Chrome was drowning in Flash security vulnerabilities, forcing constant emergency respins that left millions of users exposed. Beneath the security crisis lurked an even more pervasive problem: Flash had become the web’s primary mechanism for tracking users across sites. The only way out was building a path forward for the entire ecosystem, one API at a time.
The Security and Privacy Crisis
In July 2015, the Hacking Team breach exposed three Flash zero-days simultaneously. Within 24 hours, criminal exploit kits had weaponized them for ransomware delivery. That year alone, Adobe Flash Player accumulated 314 security vulnerabilities, a 300% increase from the prior year.
Flash accumulated over 1,122 CVEs during its lifetime, with 79% enabling arbitrary code execution. State-sponsored actors from Russia (APT28), North Korea (APT37), and elsewhere treated Flash as their preferred attack vector. A 2015 Recorded Future analysis found that 8 of the top 10 vulnerabilities used by exploit kits were Flash-related.
Security was only half the story. By 2015, roughly 90% of Flash usage consisted of 1x1 tracking pixels: invisible elements used for ad viewability measurement and, more problematically, cross-site state persistence. Flash Local Shared Objects (LSOs), known as “Super Cookies,” could store 100KB of data per site (versus 4KB for HTTP cookies), couldn’t be cleared through normal browser controls, and persisted even after users deleted their cookies. Privacy researchers had documented how advertising networks used Flash LSOs to “respawn” deleted cookies, effectively making user tracking opt-out impossible.
Flash wasn’t just a security liability. It was a privacy nightmare baked into the web’s advertising infrastructure.
For Chrome, which bundled Flash, every Adobe emergency patch required rebuilding and redeploying the entire browser to millions of users. That summer of 2015, I coordinated the response to the Hacking Team zero-days: working with Adobe on patched binaries, managing emergency Chrome stable releases, scrambling across time zones while hoping we got fixes deployed before exploit kits reached critical mass. The window of exposure was simply too long.
That experience crystallized what had been brewing for months: we needed to make the deprecation plan real, not just faster patching.
There Was Nothing Natural About Building Flash’s Replacements
The “Steve Jobs killed Flash” narrative misses something important: Flash’s dominance stemmed from filling genuine capability gaps in the early web. Video playback, rich graphics, interactive games, audio processing, and ad viewability measurement all required Flash because browsers simply couldn’t do them.
Killing Flash meant closing every one of these gaps, and that work took years of deliberate platform investment.
For video: Encrypted Media Extensions (EME) emerged from a February 2012 proposal by Google, Microsoft, and Netflix engineers. It became the most controversial vote in W3C history before reaching Recommendation status in September 2017, enabling Netflix and YouTube to finally abandon Flash for video DRM. Without EME, every streaming service would have been stuck on Flash indefinitely.
For games: WebGL shipped its 1.0 specification in March 2011, enabling hardware-accelerated graphics. Games needed more than that. WebAssembly grew from Mozilla’s asm.js work starting in 2013, finally achieving cross-browser support by November 2017 with performance within 2x of native code.
We went to GDC and Unity Unite speaking with hundreds of developers to understand the technical landscape so that we could advocate for and build out the right technologies for the platform.
For ads: This was perhaps the most tactical replacement. Flash was used extensively to detect if an ad was actually visible on screen, a technique that exploited Flash’s behavior when the plugin was in view (which consumed significant resources). Intersection Observer shipped in Chrome 51 (2016), providing a native, performant alternative. Google’s DoubleClick explicitly announced it would enable viewability measurement without Flash. The IAB Tech Lab subsequently deprecated all Flash references in advertising standards as of January 2017.
Each of these APIs represented years of standardization work, browser implementation, and developer evangelism. None of it was inevitable. None of it done by a single person.
The Infrastructure That Made Gradual Deprecation Possible
Chrome 54 (October 2016) contained a change that rarely makes headlines but proved essential: decoupling Flash Player from Chrome’s distribution bundle to use the component updater exclusively.
The component updater runs in Chrome’s browser process, communicating with Google servers to download and install component updates independently. This meant Flash security patches could deploy within hours rather than waiting for the next Chrome release cycle.
This decoupling required developing in-line on-demand Flash component installs, differential component updates, and building out special serving infrastructure. The work never made a keynote, but it was the technical foundation that allowed Chrome to maintain Flash through a 4-year deprecation process without exposing users to constant security risk. The same system updated Widevine CDM, Safe Browsing data, and certificate verification: all components requiring rapid security response independent of browser releases.
Boiling the Frog
Chrome’s Flash deprecation demonstrates how to sunset critical technology without breaking the web. The strategy was deliberate friction escalation over years, giving developers time to migrate while steadily reducing user exposure.
The phases rolled out methodically:
Chrome 42 (September 2015): Plugin Power Savings Mode paused non-essential Flash content smaller than 400x300 pixels.
Chrome 53 (September 2016): Blocked tiny Flash elements from cross-origin domains, eliminating invisible tracking beacons.
Chrome 54 (October 2016): Decoupled Flash updates via component updater; YouTube embeds auto-rewrote to HTML5.
Chrome 55 (December 2016): HTML5 by Default. Sites had to request permission to run Flash, gated by Site Engagement scoring.
The Site Engagement pivot is worth explaining. The original plan called for a static top-10 whitelist of Flash sites based on usage, which would have effectively been Google deciding who got to keep using Flash. I pushed back on that approach. It created a gatekeeping problem (who decides the list?), invited lobbying from partners, and felt fundamentally inequitable.
Instead, we pivoted to Site Engagement scoring: a dynamic model where user behavior, not Google’s judgment, determined which sites could prompt for Flash. That required working with metrics, UX, and policy teams to ship something more defensible. The threshold increased gradually from 1 (January 2017) to 100 (October 2017), giving high-traffic sites time to migrate before their users experienced friction.
This change required communicating with hundreds of partners (CBS, Zynga, Viacom, and others) to ensure they understood the new system.
Chrome 76 (July 2019): Flash disabled by default.
Chrome 88 (January 2021): Flash completely removed from Chromium.
Data drove every decision. Daily Flash encounters dropped from over 80% of Chrome desktop users in 2014 to just 17% by July 2017.
The Unprecedented Industry Coordination of July 2017
On July 25, 2017, Adobe published “Flash & the Future of Interactive Content” announcing end-of-life for December 31, 2020. What made this announcement remarkable was its simultaneity: Adobe’s blog post linked directly to complementary announcements from Apple, Facebook, Google, Microsoft, and Mozilla.
This coordination didn’t happen by accident. In 2015, I initiated cross-browser planning sessions with Adobe, Apple, Microsoft, Mozilla, and Unity to align on the deprecation roadmap. Getting competitors in a room to agree on anything is hard. Getting them to agree on a shared timeline that none could defect from took two years of relationship-building and trust development.
We all agreed on the problem (security), the breakthrough came when we framed it as mutually assured deprecation: if any single browser extended Flash support to gain market share, the entire migration would unravel. The only stable equilibrium was a coordinated deadline everyone announced simultaneously.
Microsoft’s blog explicitly stated their timeline was “consistent across browsers, including Google, Mozilla, and Apple.” The coordinated announcement meant enterprises, developers, and users received a unified message with a 3.5-year runway.
The advertising industry aligned in parallel. Amazon stopped accepting Flash ads in September 2015. Google Ads banned new Flash display ads as of June 30, 2016, with complete prohibition from the Display Network by January 2, 2017. By the time Adobe made its announcement, the ad industry had largely completed the transition.
Holding the Line
The hardest part of a multi-year deprecation isn’t starting it. It’s finishing it and seeing it through.
Enterprise customers consistently requested extensions. Internal teams lobbied for exceptions. And then COVID-19 hit in March 2020, nine months before the deadline.
The pressure to delay was real. Remote work was chaos. Enterprise IT teams were underwater. Several internal stakeholders argued that holding a December 31 deadline during a pandemic was tone-deaf.
I pushed back, hard. Not because I was unsympathetic, but because I’d seen how deprecation extensions work: grant one, and you’ve invited ten more. Every exception erodes the credibility you’ve built with partners who did migrate on time. The entire cross-industry coordination depended on the deadline being immovable.
We made accommodations where we could. Timelines for related deprecations like Chrome Apps adjusted to reduce partner burden. The Flash deadline held. The coordinated cross-vendor commitment meant no single browser could extend without the entire deprecation unraveling.
On January 12, 2021, Chrome 88 shipped without Flash. Six years of work, complete.
Lessons for Teams Facing Similar Transitions
The Flash deprecation offers a template for managing large-scale platform transitions:
Build before you burn. Chrome couldn’t simply announce Flash was deprecated. Sites had no alternative. The strategy required first shipping Intersection Observer, EME, WebGL, and WebAssembly, then leveraging those capabilities to justify the transition. The replacement APIs took 5–11 years each to standardize; deprecation planning had to account for that timeline.
Infrastructure enables gradualism. The component updater wasn’t built for Flash deprecation, but it made the transition possible by decoupling Flash security from Chrome’s release cycle. Invest in infrastructure that provides optionality for future decisions you can’t yet anticipate.
Coordinate with competitors. Apple, Google, Microsoft, and Mozilla aligned on the December 2020 deadline despite being fierce competitors. The unified timeline and communications prevented any single browser from taking market share by extending Flash support, which would have undermined the entire migration. Cross-industry coordination isn’t just diplomacy. It’s strategic necessity.
Use data to pace the transition. Alignment between competitors came not just from understanding the common problem (immense security and privacy issues), but also from sharing telemetry and product roadmaps to align on both the problem and the solutions.
Personalized beats gatekeeper solutions. Chrome’s Site Engagement scoring rollout shows how to migrate users gradually based on actual usage patterns (i.e., turn it off first on the sites that they used the least). The threshold increases tracked migration progress, applying pressure where needed while avoiding unnecessary friction.
Give adequate notice. Adobe’s July 2017 announcement provided a 3.5-year runway to December 2020. This wasn’t arbitrary. Enterprises needed time to identify Flash dependencies, plan migrations, and execute.
Hold the line on deadlines. Every deprecation faces pressure for extensions. Grant them selectively and you undermine the credibility that makes the entire transition possible.
The Real Story
The “Steve Jobs killed Flash” narrative is satisfying because it features a singular hero making a bold decision. The actual story is messier: years of platform investment, infrastructure development, standards coordination, contract negotiations, partner communications, emergency security responses, and carefully sequenced deprecation milestones.
Flash died because browser vendors systematically eliminated every reason sites needed it, then gradually increased friction until migration became easier than resistance. That required a multi-year program spanning multiple companies, hundreds of partners, and thousands of engineering decisions.
There’s no launch announcement for “successfully managed transition without breaking anything.” The skill set (cross-functional coordination, external partnership management, data-driven milestone setting, graceful degradation planning) isn’t as visible as shipping new features. It’s exactly what large-scale platform transitions require.
For anyone facing similar challenges deprecating legacy systems, migrating platforms, or coordinating industry transitions: my hope is that Flash’s end offers both a template and a reminder. These transitions don’t happen because someone declares them. They happen because teams build the infrastructure to make them possible, then execute the plan one milestone at a time.