Arguably, so is the web. A long series of extremely complicated and constantly changing data formats that are nightmarishly difficult to parse, which has to be done in C++ for speed reasons, combined with a full scripting language, which has to be JIT compiled for speed reasons, combined with 30 years of legacy and a security model that was completely ad hoc and more discovered than designed (e.g. the different variants of the same origin policy). Take that and add on top a browser community that doesn't philosophically recognize any limits on what the web is meant to do, so it just keeps getting more and more APIs until one day both Mozilla and the Chrome team decided to just stop pretending and build full blown operating systems on top of them.
I don't think Flash was harder to secure than HTML itself. People just gave up trying because browser vendors used security to purge the web of anything they didn't control.
Right, so that was exactly what I was thinking when I wrote that. All three of Flash, PDF, and the browser DOM are expansive, ambitious metaformats, containers for every piece of technology that has ever had a bug.
Your take on why Flash didn't survive is more cynical than mine. I genuinely think Apple threw up their hands at the prospect of attempting to solve a security problem on the same scale as the browser itself (something it took them a long time to get a handle on --- along with everyone else --- even after they put the kibosh on Flash).
My memory of this time is getting a bit fuzzy tbh, but from what I remember Google in the first part of the 2010s put Flash inside their renderer sandbox and Safari/Firefox were still lagging on browser sandboxing at that time. I think Adobe had shared the plugin code with Google to make this possible.
There are certainly obvious issues with securing a third party codebase you don't control, and it's likely that the browser makers had more budget to spend on security than Adobe. But there was no technical reason Flash couldn't have been treated as an alternative rendering engine from a sandboxing perspective, and I think Chrome did it. Pepper was an initiative to generalize that. Blink is full of holes as other comments point out and it's only the kernel sandboxing that makes adding new features viable at all.
I'm cynical because when the browser makers talked about phasing out plugins it wasn't primarily security they talked about. This blog post talks about speed and energy usage first:
"While Flash historically has been critical for rich media on the web, today in many cases HTML5 provides a more integrated media experience with faster load times and lower power consumption."
Security isn't mentioned, perhaps because trying to argue that their own pile of C++ was somehow meaningfully more robust than Adobe's big pile of C++ wasn't going to be convincing.
Their writings about this were also very heavy on "open web" ideology, although the SWF format was documented by that point and openness doesn't go well with deliberately wiping out a tech that was voluntarily deployed by 80%+ of websites. If openness means anything it means open to extension, which plugins provided and forcing everyone to use HTML5 did not. When they deprecated NPAPI they even sort of admitted to this:
"The Netscape Plug-in API (NPAPI) ushered in an early era of web innovation by offering the first standard mechanism to extend the browser. In fact, many modern web platform features—including video and audio support—first saw mainstream deployment through NPAPI-based plug-ins. But the web has evolved. Today’s browsers are speedier, safer, and more capable than their ancestors."
I always found this blog post curiously worded. It has a Fukuyama-style "end of history" vibe to it. Yes plugins boosted innovation because the web platform always lagged years behind, but now the web has "evolved" and the innovation era isn't needed anymore.
Arguably, so is the web. A long series of extremely complicated and constantly changing data formats that are nightmarishly difficult to parse, which has to be done in C++ for speed reasons, combined with a full scripting language, which has to be JIT compiled for speed reasons, combined with 30 years of legacy and a security model that was completely ad hoc and more discovered than designed (e.g. the different variants of the same origin policy). Take that and add on top a browser community that doesn't philosophically recognize any limits on what the web is meant to do, so it just keeps getting more and more APIs until one day both Mozilla and the Chrome team decided to just stop pretending and build full blown operating systems on top of them.
I don't think Flash was harder to secure than HTML itself. People just gave up trying because browser vendors used security to purge the web of anything they didn't control.
Right, so that was exactly what I was thinking when I wrote that. All three of Flash, PDF, and the browser DOM are expansive, ambitious metaformats, containers for every piece of technology that has ever had a bug.
Your take on why Flash didn't survive is more cynical than mine. I genuinely think Apple threw up their hands at the prospect of attempting to solve a security problem on the same scale as the browser itself (something it took them a long time to get a handle on --- along with everyone else --- even after they put the kibosh on Flash).
My memory of this time is getting a bit fuzzy tbh, but from what I remember Google in the first part of the 2010s put Flash inside their renderer sandbox and Safari/Firefox were still lagging on browser sandboxing at that time. I think Adobe had shared the plugin code with Google to make this possible.
There are certainly obvious issues with securing a third party codebase you don't control, and it's likely that the browser makers had more budget to spend on security than Adobe. But there was no technical reason Flash couldn't have been treated as an alternative rendering engine from a sandboxing perspective, and I think Chrome did it. Pepper was an initiative to generalize that. Blink is full of holes as other comments point out and it's only the kernel sandboxing that makes adding new features viable at all.
I'm cynical because when the browser makers talked about phasing out plugins it wasn't primarily security they talked about. This blog post talks about speed and energy usage first:
https://blog.google/products-and-platforms/products/chrome/s...
The same language can be found in the announcement of their HTML5 by default strategy here:
https://groups.google.com/a/chromium.org/g/chromium-dev/c/0w...
"While Flash historically has been critical for rich media on the web, today in many cases HTML5 provides a more integrated media experience with faster load times and lower power consumption."
Security isn't mentioned, perhaps because trying to argue that their own pile of C++ was somehow meaningfully more robust than Adobe's big pile of C++ wasn't going to be convincing.
Their writings about this were also very heavy on "open web" ideology, although the SWF format was documented by that point and openness doesn't go well with deliberately wiping out a tech that was voluntarily deployed by 80%+ of websites. If openness means anything it means open to extension, which plugins provided and forcing everyone to use HTML5 did not. When they deprecated NPAPI they even sort of admitted to this:
https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-...
"The Netscape Plug-in API (NPAPI) ushered in an early era of web innovation by offering the first standard mechanism to extend the browser. In fact, many modern web platform features—including video and audio support—first saw mainstream deployment through NPAPI-based plug-ins. But the web has evolved. Today’s browsers are speedier, safer, and more capable than their ancestors."
I always found this blog post curiously worded. It has a Fukuyama-style "end of history" vibe to it. Yes plugins boosted innovation because the web platform always lagged years behind, but now the web has "evolved" and the innovation era isn't needed anymore.
1 reply →
You mean intentionally?
I think they just had the focus on features and speed and fps. Not security nor efficency (battery life).
Not intentionally, but it's one of a couple 90s designs (PDF is another one) that turned out to be goliath security problems just architecturally.