Hacker News Reader

Comment by username223 | Hacker News Reader

> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors.

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.

View on HN

Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something, but that is a long way off.

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.

Not sure it’s a genie situation. Look at Java applets, Flash player.

The situation is apples and oranges.

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.

Big changes do happen and look small only in retrospect.

But they don't happen overnight. I didn't say change wouldn't happen, I said it wasn't likely to happen anytime soon.

Let the record note my gripe was only with the genie/bottle wording, which indicates an irreversible change :)

Depends, I white list JavaScript on the web sites I thrust, and use native apps when given the option.

On the OSes I use, I make sure all sandbox options are turned on.

Would you consider yourself a typical example of a naive user? The security default needs to work for everyone. I think the sandbox approach is better than expecting everyone to correctly decide when it is or isn't okay to allow a site to run code.

Yes in the context of iOS, Android and UWP native apps.

You must run in much better circles than I do. Nevermind a naive user, the average users I know wouldn't know how to disable javascript, or whitelist sites, or that there even were sandbox settings in the OS.

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.

You completely misunderstood me.

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.

> The web by and large requires javascript, and it's not likely to change.

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

The users didn't make the decision, the platforms did, and the decision was made after an alternative was available in Javascript.

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.

> If anyone killed Flash and Java, it was Apple by refusing to support either on the iPhone.

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.

> Client side Java and Flash are dead

Not paying attention to the news? Just wait until WebAssembly gets more mature.

I don't think WebAssembly is going to bring back Flash or Java Applets in any meaningful way. Maybe someone will hack something together and use it for niche old Flash game sites, but it's hard to see a reason for widespread adoption of anything new. People have moved on.

Flash and Java Applets may not be "dead" forever, but they also are not likely to ever be more than undead zombies.

Again, not paying attention to the news.

http://teavm.org/

https://forums.adobe.com/thread/2432179

http://www.mono-project.com/news/2017/08/09/hello-webassembl...

https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFut...

https://github.com/Microsoft/xaml-standard/issues/197

I think we are talking about different things. Half your links have nothing to do with Flash or Java Applets (.net, XAML?).

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.

TeaVM allows any Java application to be ported into WebAssembly, be it an applet or not.

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.

As I said, we are talking about different things. I am talking about running binary executables from old platforms and people making new binaries in the old way again, you seem to be talking about porting old source code to new platforms.

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 paying attention to the news? Just wait until WebAssembly gets more mature.

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.

> Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change.

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.

>> Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change.

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

> Personally I think it's easier and more likely that we attempt to fix a few web browsers than expect a millions of websites to change.

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.

And yet presumably you didn't get pwned in the process of writing that comment. It's true that securing the execution of untrusted code is hard. But it's not impossible.

Commenting here works just fine without JavaScript.

Yes, but at the cost of:

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

Then let's standardize generic ways that permit things like upvotes without reloading the page and without executing externally supplied code. :-)

You can do this already with iframes, link targets and :visited for css classes. Using javascript is unnecessary. This technique used to be popular before XMLHttpRequest.

Thanks for providing a solution.

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.

Embedding hundreds of iframes into existing pages isn't a viable solution.

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

> Embedding hundreds of iframes into existing pages isn't a viable solution.

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.

You'll have to come up with proof of a better alternative before you'll get agreement from people like me. Javascript and sandboxed executable code may not be a magic bullet, but it's the bullet we have.

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

Oh, I don't want to give all the freedom that JavaScript in the browser gives, and that's the whole point. If we came up with something that allowed the same things, then that would be a pointless exercise. There will be cuts in aspects, some necessary, some intentional.

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.

I will certainly agree that requiring JavaScript unnecessarily should be frowned on and progressive enhancement should be the norm. A least give user the option of taking on additional security risks associated with Javascript (and WebAssembly) or not (edit: where possible).

Agreed to a point. For some apps user interaction is required, and progressive enhancement isn't possible.

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.

Unfortunately the web seems to be moving away from a progressive enhancement world.

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.

Let's stick with the reddit example. The up/down vote links could be standard anchors with additional tags <a href="upvote" reload="comment#564534">^</a>. Inline posting could be similar.

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.

Online forums were already possible without JavaScript.

I would even rather read HN via NNTP, if given the option.

> I would even rather read HN via NNTP, if given the option.

https://github.com/gromnitsky/hackernews2nntp

Interesting, thanks for the heads up.

That comment could've been written without executing any Javascript.

// Edit: heh, someone already said the same.

I've whitelisted JS from this site, because I "trust" it enough. If HN sold their comment code through some opaque web of third parties, I would be more cautious.

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?

Reply on news.ycombinator.com