As for relying on users ability to determine what code is safe to download... It's not like users can be relied on to do the right thing all the time even without javascript. People respond to phishing attacks, download executables sent to their email, reuse passwords... I think a sandbox is a better solution than relying on users to understand what code is trustworthy and what isn't.
Dumping Flash and Java took years, and was driven by rapid adoption of mobile devices that either didn't support them at all (Apple) or very well (everyone else). There was an already deployed alternative (Javascript).
Javascript is buried much deeper in modern websites and would be much more difficult to replace than either Flash or Java Applets were for most sites. For most sites Flash was just to play videos or display ads. Many sites only had to replace an object tag with a video tag. Java Applets were fairly niche in the first place, so aren't really comparable.
In addition there isn't currently a viable alternative for Javascript. Maybe WebAssembly someday, but currently it's designed to supplement Javascript not replace it.
On the OSes I use, I make sure all sandbox options are turned on.
Some of the older people I know can't even correctly choose between between writing a text message, and a facebook post.
If you think you are a typical example of a naive user, I would hate to see what you expect of the average user.
iOS, Android and UWP sandboxes for native apps are always enabled, there isn't any configuration for naive user available.
You just allow or not the access to specific actions and that's it.
On UWP you cannot even access files directly, the user has to select them for your application.
You can only change the way sandboxes behave via developer settings, but that is only in the context of debugging, which naive users will never do anyway.
While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting close to a situation where average people recognize that millisecond auctions to run arbitrary code on their machines are a bad idea, and those people also have the tools to say "no." Hope springs internal...
If anyone killed Flash and Java, it was Apple by refusing to support either on the iPhone. All the users did was make popular a platform that didn't support them. If Apple had supported Flash and Java we probably would still have them.
Signed code that users had to install was tried before with ActiveX. It didn't work either because you can't rely on random developers to write secure code either. It's also how IE ended up with Flash. Click here to download Flash (signed by Macromedia).
So basically everything sucks because we're human and make mistakes. Maybe one day we'll have machines that reason more thoroughly than us and they can come up with a secure platform. Until then... Javascript and sandboxes.
Apple may have put the nail in the coffin, but long before that quite a few developers and users were avoiding Java programs when there were alternatives, and ClickToFlash was a popular browser plug-in. As they often do, Apple saw which way the wind was blowing.
Not paying attention to the news? Just wait until WebAssembly gets more mature.
Flash and Java Applets may not be "dead" forever, but they also are not likely to ever be more than undead zombies.
You seem to be talking about new platforms that may derive some part from the old. I'm not saying WebAssembly won't be used for new platforms as that's sort of the whole point of it.
What I'm saying is that WebAssembly won't bring back people making Flash .swfs or writing classes derived from java.applet.Applet in any mainstream way. In that sense Flash and Java Applets are dead. Maybe someone will hack something together that allows you to run them, but that won't bring the developers back to the old platforms.
If Oracle or Adobe announce something, maybe the industry will jump on board, but currently I don't see anything in your list that makes me change my mind about Flash and Java Applets being dead and not coming back.
As3-WebAssembly is a compiler for porting Action Script 3, Flash's programming language, into WebAssembly. Already integrated into Flash Develop.
Microsoft and Xamarin efforts to port Mono into WebAssembly, will allow making Silverlight apps again.
You are free to believe this won't turn out into anything, I rather think we will end up in WebAssembly + Canvas/WebGL in a couple of years.
The new platforms may use the old languages, but the runtime libraries are not the same. The new platforms have different APIs and functionalities (no threads in TeaVM for instance).
To simplify my point. ActionScript is just a language. Adobe Flash was much more than that. Maybe companies really will find some compelling reason to start using ActionScript again... but Adobe Flash and it's SWFs will still be dead.
Not yet. If "WebAssembly" is anything like actual machine code, then it will be easy to compile a bunch of languages to "WebAssembly," and a huge pain to make them talk to each other. So nothing really changes.
This fatalist stance is childish, and dangerous. As long as there are people working to make things better, things do improve.
Sure, if you make sure that one small website works without JavaScript then that doesn't change the world. I hear a similiar argument when I explain why I don't eat meat; I'm told that animals will be killed anyways. But if I don't eat meat, then less will be killed. How many less? I can't specify the number, but I don't power-hungrily demand my own decision can magically change the world completely over night, and give up when I realize it doesn't.
Still, each and everyones has an influence. It's about doing what's right. And even if you are the only one doing the right thing, things will be a bit better for your actions. But in fact the situation isn't that bad, and one isn't alone.
> It's not like users can be relied on to do the right thing all the time anyway.
So, if you aren't sure you locked the front door of your house, then it also doesn't matter if you left the door to the garden open? Clearly it does matter!
This fatalism deems us into inaction and into accepting the status quo even if we know it's bad.
>This fatalist stance is childish, and dangerous. As long as there are people working to make things better, things do improve.
How is it any more of a fatalist stance than the idea that javascript or running untrusted code in a sandbox is fundamentally broken?
Personally I think it's easier and more likely that we attempt to fix a few web browsers than expect millions of websites to change. You might call it fatalism, but I think of it as realism.
>> It's not like users can be relied on to do the right thing all the time anyway.
> So, if you aren't sure you locked the front door of your house, then it also doesn't matter if you left the door to the garden open? Clearly not!
My point was not that security is useless because users are unreliable. My point was that it's better to keep the kids in the sandbox, than to have them play in a busy street. Security should be preserved in spite of users actions, not rely on them.
This is the same argument I criticized before. The world doesn't change completely over night because one changes their own actions, and that is fine. These million websites maybe never change, and that's what we'd have to live with.
1. Increased complexity on the server side to handle both cases.
2. Degraded experience on the client side (page reloading for simple actions like upvoting).
If using JavaScript to achieve this is easier/more efficient/better in some other way that is convincing, then we can think about standardizing better ways to do it. And if it's not better using JavaScript, then it's just an issue of raising awareness about not using JavaScript for it.
Consider that a single reddit comment requires at least: upvote, downvote, save, report, hide. Not to mention actually commenting, expanding/collapsing threads, or gilding comments.
A thread shows 200 comments by default (500 with Gold). Even 200 comments x 5 features requires a thousand iframes, each of which is embedding a complete document.
If you think web performance is bad now...
I know I'm repeating myself, but then let's standardize a better way to solve the problem without executing supplied code. JavaScript is not a magic bullet that solves problems that aren't solveable otherwise.
"Lets standardize a better way" doesn't give much to talk about if I don't buy into the issues you have with Javascript and executable code.
If you could give a compelling example of a better way that gives the same freedom I would love to hear it. The alternatives I know of all sacrifice something (speed, interactivity, flexibility, development cost) in the name of getting rid of something it seems most people don't have a fundamental problem with (namely sandboxed executable code).
I don't advocate for a better way to have apps on the web, but to have a better app-less web.
I'm a bit tired to talk about this topic right now. I'm also repeating myself. I talked a lot about JavaScript on HN recently, so you can read there more, and the surround comments have lots of other perspectives. Not everything has been said. Maybe I'll write up a structured and hopefully complete blog post about it some day soon.
For non-apps though, it's still very important. Articles should not require a JS bundle to load. When JS is used, it should be optimized.
Momentum seems to be with whatever is easiest. JavaScript frameworks, analytics companies, and ad companies would probably all have to make progressive enhancement the default way for that to change.
It doesn't take much to do 99% of what we want with javascript and server side rendering, we used hacks to do it before javascript so I'm sure we could design something even better. It doesn't sacrifice anything.
I would even rather read HN via NNTP, if given the option.
// Edit: heh, someone already said the same.
You're clearly an insider, and I'm clearly an outsider, so you understand the nuances here better than I do. What's your concept of securely executing untrusted code? Should users give up control over what runs on their machines? Should they know whose code may run before and/or after it does? Or what data it can or has already exfiltrated?
There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't type check. It's that the people running it don't consciously install it, the people distributing it don't know or care what it is, and the people writing it are often adversaries far more sophisticated than the people running it.