4 ms·

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

by niftich 10y ago

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 http://info.cern.ch/hypertext/WWW/TheProject.html

Chris_Newton 10y ago
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.
- bobajeff 10y ago
  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.
  - Chris_Newton 10y ago
    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.
    - bobajeff 10y ago
      (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.
dredmorbius 10y ago
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.
- niftich 10y ago
  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/ https://www.w3.org/TR/XMLHttpRequest/ [2] https://en.wikipedia.org/wiki/Canvas_element https://en.wikipedia.org/wiki/Canvas_element
  - dredmorbius 10y ago
    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.)

by niftich 10y ago

Chris_Newton 10y ago

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.

bobajeff 10y ago
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.
- Chris_Newton 10y ago
  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.
  - bobajeff 10y ago
    (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.

dredmorbius 10y ago

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.

niftich 10y ago
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/ https://www.w3.org/TR/XMLHttpRequest/ [2] https://en.wikipedia.org/wiki/Canvas_element https://en.wikipedia.org/wiki/Canvas_element
- dredmorbius 10y ago
  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.)