> Also, browsers could run in a simple and secure legacy mode when they connect via http.

:) What if, purely as a theoretical proposal, they display the webpage as normal, but just show a little icon in the address bar that marks the website as insecure?

Have I missed something? Is anybody actually talking about removing HTTP support from browsers? I don't think that this is the same scenario as Java or Flash at all, HTTP still works fine. All of the static websites that people are complaining about losing still load without any problems.

And even if it was the same scenario, Java is not a great example to use here, because the deprecation of Java and Flash, as painful as it was to many people, was also very clearly, almost universally recognized as necessary for security.

Java and Flash are probably the two best examples you could come up with if you wanted to argue, "sometimes it's necessary to take painful steps that break things to make a secure system. Sometimes you can't trust developers to do the right things until you force them."

Am I sad about Flash and Java? Of course, I have a fair amount of personal background in that area. We lost precious things. But should we have kept Java? No, of course not. Obviously not, that would have been such a terrible idea for both security and the Open web. I remember the pain of trying to get decent Flash support on Linux. It was a fantastic, open system for some people. But it was also proprietary, and filled with security holes, and being used in ridiculous ways for DRM and circumvention of Open browser standards, and frankly, the slow deprecation path just wasn't working.

I wish Flash had been handled better, but... I mean, we did have to get rid of it. I don't believe anyone could seriously argue to me that the web would be better if we were still using Java and Flash today.

So even in a theoretical world where we're actually talking about deprecating unencrypted HTTP support, we should still only be talking about preserving or emulating sites that will be lost. We shouldn't be talking about continuing to do something that's insecure.

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.

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

+1

Even if there are good reasons, it;'s still effectively deleting decades worth of the internet.

To blithely say that it's trivial to slap together a reverse proxy and keep it updated is both factually wrong and missing the point: something has been lost, and it's sad.

...is there talk of browsers actually dropping support for http connections?