> 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

> 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.