There is a difference between being able to do something once and being willing to take on some ongoing and occasionally time-consuming responsibility to maintain it.
Look at how many useful but Java-based demonstrations on academics' websites became inaccessible when the browsers decided Java plug-ins were evil and should be removed. What happened was not that people who had voluntarily spent considerable time over the course of possibly several years developing useful little bits of software suddenly dropped everything to redo all of that work again in a different language just because the browser developers had decided that other language was now flavour of the month. Instead, lots of valuable work was effectively lost.
They decided to drop java as a plugin because people would browse to a random webpage, and malware would automatically be downloaded to their machines.
Java plug-ins died off for a reason, but that doesn’t change the fact that deprecating http is effectively deleting decades worth of the internet for no good reason.
If someone can own my browser by mitm’ing a static html page, then they can do it more easily by serving malicious ads, or using seo / social engineering to steer me to a web server they control. I don’t buy that argument.
Also, browsers could run in a simple and secure legacy mode when they connect via http.
> 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.
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.
Every major browser had put Java applets behind at least a click-to-play safeguard long before that time.
I strongly suspect that the security arguments were always more of a convenient smokescreen than an honest concern. Browser developers wanted to drop Java applets because they wanted to dump some legacy plug-in infrastructure that was painful to maintain, and their management probably viewed support for old and unprofitable technologies as an acceptable loss to achieve that goal.
Everyone knows what happened. But the result was that a huge part of our history was lost. When we write a book, it is archived in the Library of Congress. As publishing moves online, and we deprecate technologies due to technical convenience, that's just lost.
Java changed its security model at the same time, and applets needed to run inside a web browser. (You could fix this by modifying the source, but why bother, since no one would use the result in practice?)
That seems like an issue with Java/Oracle then, not browser manufacturers.
This has also come up with Flash, where Adobe still hasn't opened up the technology to the point where people can effectively emulate it.
If a technology is insecure, and it gets removed from a specific environment for security reasons, and simultaneously a company makes it so that it's impossible to run outside of that environment -- the deprecation wasn't really the problem then.
The reason we've lost massive numbers of Java applets and Flash apps isn't because they got deprecated from web browsers, it's because alternative environments and emulators were never built or given the support they needed. Mozilla/Google can't just decide to change the Java security model for native applets.
Applets weren't necessarily standalone software, though. I built several professionally, and they were all integrated into a wider web page, not just a self-contained program.
The changes by the plug-in developers were often unhelpful in the final days before we gave up on those technologies entirely, but let's not pretend they were the root cause of the plug-ins' demise.
I don't think they were the root cause, but even though there are scenarios like you're talking about, I still think we'd be in a different world today if different companies were handling those plugins.
It's worth noting that from a preservation perspective, today we're at the point where people are pretty realistically looking into emulating SWF runtimes in Javascript inside web browsers. If that happened, you wouldn't even need click-to-play. SWFs would just work with the same sandboxing guarantees as the browser.
The biggest reason that hasn't really taken off is because the SWF format still hasn't been opened up. The reason why there isn't just a drop-in WASM library that lets you run Flash code on the web is because of Adobe, not Mozilla or Google.
Of course, especially in the case of Java we could only ever emulate features that browsers support. But that's why the plugins were deprecated in the first place; because they supported inherently insecure features that we either don't want in the browser, or don't want to support in the same way.
But that's true for lots of platforms, and yet I can already run C/Rust/Lua code in a web browser. The Lua runtime had been cross-compiled to ASM.js before Flash was dead (although today we have a lot better speed). But the difference between Lua/C and Java was that the most common Java runtime was proprietary. OpenJDK browser plugins would break most sites that I was using. So there wasn't anybody who was sitting down to say, "excluding the features that browsers don't support, is there any of this code that's salvageable?" They weren't really allowed to do that.
Even assuming that were technically possible, why should we assume that anyone who visited those pages and found them useful would know what a JAR or JVM is?
Look at how many useful but Java-based demonstrations on academics' websites became inaccessible when the browsers decided Java plug-ins were evil and should be removed. What happened was not that people who had voluntarily spent considerable time over the course of possibly several years developing useful little bits of software suddenly dropped everything to redo all of that work again in a different language just because the browser developers had decided that other language was now flavour of the month. Instead, lots of valuable work was effectively lost.