Hacker News new | past | comments | ask | show | jobs | submit login

I'm very torn on this subject. I'm always wary when browser vendors force the hand of users, programmers, and everyone else.

I fully understand that Flash has had an outsized share of vulnerabilities 'affecting browsing' over the years; I fully understand that Adobe has deprecated Flash for new content production; I fully appreciate that the 'web platform' has acquired new APIs and capabilities over the last four years, making it a more potent platform than the days when people opted for Flash or Silverlight because an external runtime was the only way to reliably deliver the experiences those developers wanted.

But in a world where a HTML webpage from 1991 [1] still loads and renders fine, I'm worried about the sheer amount of content that exists in Flash from the 2000s that will be made inaccessible. Sure, those developers should have known that developing on a proprietary platform is a risky bet, but this was back when Javascript was awful, browsers were racing to implement not-yet-final enhancements to CSS3 with vendor prefixes, and powerful vendors were bickering about which formats to support in a proposed <video> tag. These developers of course should've known better, but they had no other choice.

What Mozilla is doing here is actually quite reasonable, but they're under pressure from Google Chrome who can unilaterally decide to ban flash from all but the top 10 sites, and get away with it due to their control of multiple platforms and their unwillingless to compromise.

If Mozilla's tactics stray too far from Google's, they risk being seen as followers, rather than policy drivers; furthemore they answer to a divided fanbase that on one hand wants an open, independent web (in which Flash has no place), and on the other hand, wants a refuge from the incumbent browser maker's unilateral policies (currently Google, previously Microsoft).

[1] http://info.cern.ch/hypertext/WWW/TheProject.html




Similar arguments were made for locking out Java applets, and other plugins. The trouble is, every time the big browser developers throw their weight around like this, a lot more content becomes inaccessible, and content is what the Web is all about. Much of the valuable material that isn’t in the top x% of sites wasn’t written recently and isn’t necessarily actively maintained, and this trend for writing off entire sections of the Web because they’re inconvenient is a very dangerous one, IMHO.

I’d have marginally more sympathy if the modern alternatives we’re supposed to use instead now actually worked as well as the technologies they allegedly replace, but often they do not, and the biggest advocates for the newer technologies are often among the worst offenders.

I’d also have marginally more sympathy if there was evidence that closing out the plugins would significantly improve security, but given that many of these changes just move the attack surface to the browser itself and that the popular plugins have mostly been subject to some sort of click-to-play safeguard for a while, I’m not sure the security argument holds much water either.

But in any case, actively cutting users off from large amounts of existing content with no workaround seems like a huge backward step to me.


The plugin system itself is very dangerous to the web. It prevents browser vendors from ensuring that the same content is available on all platforms. That's why it's being removed.

Already, many widely used devices can't access Flash content. Browser vendors are doing the responsible thing here by preventing any future situation like what has happened with Flash on mobile.


But some of the replacements also prevent browser developers from ensuring the same content is available on all platforms. For example, HTML5 media elements don’t prescribe specific codecs to be supported, and in practice several of the major ones are patent-encumbered and encoders and decoders are not freely available on all platforms without running into potential legal issues. So now, instead of relying on Flash being available and providing audio-visual content in a single format that Flash was known to support, we have to encode that audio-visual content in a variety of different formats to have any hope of it playing with as much portability, and there are still no guarantees that it will remain so in the future. I don’t see how this really improves anything: a useful de facto standard has been replaced by a de jure standard that is less useful and requires more work to comply. If unrestricted, good quality encodings for audio and video had been standardised along with the HTML5 media elements, it might have been a different story, but that is not what we actually have today.

One could make similar arguments about replacing complex and/or interactive graphical content once drawn using plugins with HTML5 canvas, SVG or WebGL elements. The quality of implementation, reliability and performance of these newer technologies are not quite universally awful across all browsers, but the situation is disturbingly close to that once you start using them for more demanding applications like complex animations or drawing interactive diagrams with thousands of elements.


(Not sure what you're talking about with codecs. H.264, AAC and MP3 are supported in all major browsers.)

Well you can't rely on Flash being available anyways. It's not available at all on mobile.

Nothing anyone has ever made (or will ever make) in Flash will work on mobile today.


(Not sure what you're talking about with codecs. H.264, AAC and MP3 are supported in all major browsers.)

For example, H.264 is patent-encumbered. It’s now supported to some degree for HTML5 video elements by all the major browsers on most platforms, but it has been a long road to get that far.

Mozilla struggled for a long time with getting support into Firefox across platforms. To this day, Firefox still relies on third party software and/or hardware decoding to provide the required functionality, and this was a real world limitation on at least one major platform as recently as two years ago. A similar limitation would affect any other browser whose developer wasn’t in on the patent pool or paying royalties to it.

Google also threatened to pull H.264 support from Chrome for a while, reportedly because of concerns over the licensing costs.

Anyone distributing video encoded using H.264 also needs to be mindful of the licensing rules. Although small scale and non-commercial uses typically don’t require royalty payments under the current rules, there is a legal minefield here for anyone operating a larger business who might be affected. This is a significant concern in itself given that some major browsers only support H.264 for HTML5 video.

Beyond the patent issues, we also have the issue that H.264 comes in many flavours, and support for those isn’t standardised across browsers and platforms either. Unless you’re only talking about the least common denominator, it’s not really sufficient to refer to H.264 support; you need to know which specific variations are supported on any given browser, OS and hardware in order to serve video with the best possible quality and efficiency. Finding that information is not straightforward, even if you have the resources to then encode in many different variations once you know.

Looking at the above, it’s hard to see anywhere that the current situation is actually better than what we had for a long time with plugin-based players, except on newer systems that don’t support those plugins. Which brings us to…

Well you can't rely on Flash being available anyways. It's not available at all on mobile.

Of course you can’t rely on it now, but that is mostly an artificial limitation imposed first by the mobile browser developers and subsequently by Adobe themselves in response. A Flash player was available on Android for a long time, and Microsoft were reportedly keen to see a version running on Windows Phone as well.

What we’re really talking about here is Apple starting the ball rolling by refusing to allow plugins on iOS, for reasons we may or may not believe are what Apple publicly claimed at the time. Considering that there have been numerous significant problems with Apple’s support for HTML5 video on iOS devices — not least relying on the infamous AppleCoreMedia to handle that content instead of the browser itself for a very long time, causing all sorts of functionality to break — and that Apple’s policies prevent any other browser on iOS from doing better, I have always found their stance on this rather hypocritical.


Sure, BlackBerry and Windows Phone could've maintained Adobe's support for their platforms. But that would've been expensive, a poor user experience (like Android's version) and depend entirely on Adobe continuing to allow access to their source code and distribution of the flash player.

No matter who you want blame however doesn't change the fact the Flash isn't ubiquitous. It's ubiquity always depended on a single vendor supporting it on every platform.


Causality is inverted. The harm was done in electing to use non-free, proprietary, single-player data formats. I've been watching that error be made for 30+ years now.

Don't lock yourself in to that crap in the first place.

Consider the pain an educational expense.


On the contrary, I wrote in my post that there was no free, open choice at that time.

In fact, XMLHttpRequest didn't become a W3C Working Draft until 2006 [1], before then it was a proprietary Microsoft extension. Canvas didn't become a standard until 2007 [2], until then it was Apple's proprietary trick. The DOM was the only API of what we now call the 'web platform' for many, many years.

Between 2000-2006, Flash, Shockwave, and Java Applets were delivering rich interactivity while the open standards were nowhere to be found. While we can and should celebrate that the 'web platform' is finally good enough to replace proprietary applets, the schadenfreude is unnecessary.

[1] https://www.w3.org/TR/XMLHttpRequest/

[2] https://en.wikipedia.org/wiki/Canvas_element


I didn't say the harm was in choosing a proprietary standard over an open one. I said it was in choosing a proprietary standard.

I'll allow there were few alternatives at the time, for in-browser, run-many-places interactive content. You could have ginned something up in JS, Java, or distributed binaries for your target platforms.

But if you find yourself gazing into the abyss of "well, I've got to use a proprietary standard to do that", you can be virtually certain of the consequence you've noted here.

(Not that open standards last forever either, but the track record is vastly superior.)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: