3 ms·

The usual security arguments for dropping those plug-ins have always been a bit dubious. There is no doubt that the old plug-ins were bug-ridden security nightm

The usual security arguments for dropping those plug-ins have always been a bit dubious. There is no doubt that the old plug-ins were bug-ridden security nightmares. However, click-to-play had mitigated the drive-by download problem. Perhaps more importantly, would an objective assessment of today's browsers really find that they are significantly more secure than the plug-ins were, where they have taken over providing similar functionality? Much the same attack surface is still there, it's just that the browsers are behind all of it now. The evergreen browsers tend to deploy updates more quietly, but if you check the changelogs, they still push out fixes for many significant security flaws in those updates. I'm not sure arguments about the proprietary nature of the old plug-ins are very strong either. After all, the main cheerleader for dumping them initially was Apple, but to this day Apple relies on proprietary and patent-encumbered technologies for playing multimedia content on iOS where just about everyone else in the world is using technically superior formats with open standards by now. I don't know if I would claim that the web would be better if we still had Java and Flash today. I think there are too many different dimensions to consider to make such a blanket statement. But I do think a lot of value was lost by turning them off, and I do think the security and openness benefits have been overstated, not because the plug-ins weren't deeply flawed in those respects but because people seem to overlook the all too similar failings in the replacements.

danShumway 6y ago
> However, click-to-play had mitigated the drive-by download problem Only for people who were security conscious and willing to not load certain web pages. For normal people, click-to-play was just another pop-up to click through. I do generally support people's abilities to choose to do insecure things, but there's a strong argument that the point of the web is to securely run untrusted code, and allowing developers a single step to bypass that sandbox is kind of antithetical to what the web is. > Perhaps more importantly, would an objective assessment of today's browsers really find that they are significantly more secure than the plug-ins were I would be very surprised if this wasn't the case. It's not just that modern browsers are less bug-ridden, it's also that their permission models are fundamentally different. HTML5 still doesn't allow you the same level of filesystem access that Java and Flash did, and its replacements allow debugging and extending at the DOM/script/network level. It's hard to imagine a version of adblockers that would work with Java applets. In contrast, I can use uMatrix to turn on/off individual request types to specific subdomains. I mention elsewhere that part of the problem with deprecation was that none of these companies allowed for effective emulation of the web stack. To be fair, part of the reason why emulation was (is) hard is that to this day, Java applets and Flash applets still have capabilities that can't be emulated in a web page. But that's also part of the security problem; we don't want those capabilities to be emulatable. > because people seem to overlook the all too similar failings in the replacements Flash just didn't work well on Linux. I couldn't watch Youtube videos. I remember how excited I was when Youtube started moving to HTML5 video containers instead of Flash, because the web doesn't have those problems, and I was so sick of trying to configure Flash plugins for Firefox in Ubuntu. Java plugins were also an issue, albeit to a somewhat lesser extent. But I used to always curse whenever I would see a Java plugin loading up, even as recently as 2015-2016 when I was using legacy enterprise apps. Not to mention Silverlight -- it's annoying that Apple uses proprietary codecs, but for a long time I just couldn't recommend Linux to anyone who wanted to have a Netflix account. People have a rosy view of these systems, but they weren't necessarily the open utopia that people remember. They just worked well for some people in some configurations. Given that post-deprecation Adobe still hasn't open-sourced any of its SWF runtime, I don't think there's strong evidence that this would have gotten any better without moving away from proprietary technologies and forcing devs to use Javascript. By and large, I think the replacements have all been a lot better. The only big exception I can think of is the awful DRM proposals for video, but at least the technology works mostly cross platform. Even at the video level, a proprietary video codec just isn't comparable to a black-box piece of code where I can't look at the network requests, that has a completely separate permission model from my browser, etc... There's a reason why everyone was comfortable providing DRM in Flash/Java/Silverlight, but why in a post-plugin world Google felt it was necessary to provide a completely separate 'solution' rather than just move the DRM into Javascript.

danShumway 6y ago

> However, click-to-play had mitigated the drive-by download problem Only for people who were security conscious and willing to not load certain web pages. For normal people, click-to-play was just another pop-up to click through. I do generally support people's abilities to choose to do insecure things, but there's a strong argument that the point of the web is to securely run untrusted code, and allowing developers a single step to bypass that sandbox is kind of antithetical to what the web is. > Perhaps more importantly, would an objective assessment of today's browsers really find that they are significantly more secure than the plug-ins were I would be very surprised if this wasn't the case. It's not just that modern browsers are less bug-ridden, it's also that their permission models are fundamentally different. HTML5 still doesn't allow you the same level of filesystem access that Java and Flash did, and its replacements allow debugging and extending at the DOM/script/network level. It's hard to imagine a version of adblockers that would work with Java applets. In contrast, I can use uMatrix to turn on/off individual request types to specific subdomains. I mention elsewhere that part of the problem with deprecation was that none of these companies allowed for effective emulation of the web stack. To be fair, part of the reason why emulation was (is) hard is that to this day, Java applets and Flash applets still have capabilities that can't be emulated in a web page. But that's also part of the security problem; we don't want those capabilities to be emulatable. > because people seem to overlook the all too similar failings in the replacements Flash just didn't work well on Linux. I couldn't watch Youtube videos. I remember how excited I was when Youtube started moving to HTML5 video containers instead of Flash, because the web doesn't have those problems, and I was so sick of trying to configure Flash plugins for Firefox in Ubuntu. Java plugins were also an issue, albeit to a somewhat lesser extent. But I used to always curse whenever I would see a Java plugin loading up, even as recently as 2015-2016 when I was using legacy enterprise apps. Not to mention Silverlight -- it's annoying that Apple uses proprietary codecs, but for a long time I just couldn't recommend Linux to anyone who wanted to have a Netflix account. People have a rosy view of these systems, but they weren't necessarily the open utopia that people remember. They just worked well for some people in some configurations. Given that post-deprecation Adobe still hasn't open-sourced any of its SWF runtime, I don't think there's strong evidence that this would have gotten any better without moving away from proprietary technologies and forcing devs to use Javascript. By and large, I think the replacements have all been a lot better. The only big exception I can think of is the awful DRM proposals for video, but at least the technology works mostly cross platform. Even at the video level, a proprietary video codec just isn't comparable to a black-box piece of code where I can't look at the network requests, that has a completely separate permission model from my browser, etc... There's a reason why everyone was comfortable providing DRM in Flash/Java/Silverlight, but why in a post-plugin world Google felt it was necessary to provide a completely separate 'solution' rather than just move the DRM into Javascript.