Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: a binary format for the web

2ality.com

Post reply on HN
Print view View original

111–120 of 164 posts

Re: WebAssembly: a binary format for the web

#111

Post by Mikushi »

13years wrote: post #107
zmmmmm wrote: post #97

As laudable as the goal of improving performance is, I hope this never takes off. Why? Because it will take about 5 minutes from 90% of the web to go from open, transparent, easily reverse engineerable source code to essentially giant blobs of secret binary code. People will pay lip service to performance but 99% of the reason that web sites will implement this will be to cover up their code, keep secret their implem…

Yet, isn't much of the web already unreadable due to minification of JS source?

If you think minification does anything to prevent anyone from reading it you are mistaken. Is it harder? Yes. Impossible, not even close, just annoying. I've reversed engineer JS libraries with 20K LOC that were minified and uglified in less than a day, hardly what I consider a hurdle.

Now, to have worked with asm.js recently, that's a whole different ball game. That is unreadable, at least without spending copious amounts of time on it and having a deep understanding of asm.js to be able to read it.

Re: WebAssembly: a binary format for the web

#112

Post by robbrown451 »

zmmmmm wrote: post #97

As laudable as the goal of improving performance is, I hope this never takes off. Why? Because it will take about 5 minutes from 90% of the web to go from open, transparent, easily reverse engineerable source code to essentially giant blobs of secret binary code. People will pay lip service to performance but 99% of the reason that web sites will implement this will be to cover up their code, keep secret their implem…

I don't see how obfuscated javascript is a lot easier to reverse engineer than webassembly binaries will be. You really scrutinize your bank's javascript for security issues? Really? I have a hard time believing that.

Re: WebAssembly: a binary format for the web

#113

Post by zmmmmm »

luhn wrote: post #105
zmmmmm wrote: post #97

As laudable as the goal of improving performance is, I hope this never takes off. Why? Because it will take about 5 minutes from 90% of the web to go from open, transparent, easily reverse engineerable source code to essentially giant blobs of secret binary code. People will pay lip service to performance but 99% of the reason that web sites will implement this will be to cover up their code, keep secret their implem…

> I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. Not really. Almost all websites obfuscate/minify their Javascript now, making manually interpreting the code much less than "trivial." I think WebAssembly will be no worse to figure out than obfuscated Javascript.

I think it will be much worse.

Minified Javascript is pretty easy to turn back into something moderately understandable just by "prettifying" it. I do this all the time. It works pretty well because it started as Javascript, so turning it back into Javascript has a relatively clean mapping. WebAssembly will have started as some other language or even as no language at all - there may be no mapping back to anything Javascript could represent. It will be much closer to disassembly of machine code, or Java byte code, which is possible but challenging enough that most ordinary developers never do it.

Re: WebAssembly: a binary format for the web

#114

Post by no1youknowz »

I am someone who makes a living having a SaaS that clients use.

I've had clients who have tried to "clone" my work, but eventually come back because they couldn't figure out the backend code or scale.

I would love something that is the equivalent of installing an app on a phone, that is using a compiled app in a browser. Where the source can't be viewed.

Even better, if I can give a rich UX. By having access to the system.

Yes, I believe in some very small cases this will be welcomed. Otherwise, I think for everyone like 95% of the web, html, js, css, etc, will see be the way to go.

Re: WebAssembly: a binary format for the web

#115

Post by lambdapie »

dbpokorny wrote: post #83
lambdapie wrote: post #74

Earlier quoted context omitted.

You can run untrusted code in an iframe (possibly with the sandbox attribute set). I think this would be what you're looking for.

Go to http://www.html5rocks.com/static/demos/evalbox/index.html type in console.log("foo") and click either button. It has access to the console even from the sandbox. Is there a way to say: I want this iframe to run a script, but don't give the script access to the console?

No, but I'd still recommend looking into content security policy (CSP), iframes, and the sandboxed attribute. Even though you seem to have developed your own notion of what isolation/security should look like, the HTML spec authors have thought very carefully about this and CSP has its own internal logic. Even if you still prefer your model, at least you will be able to explain how your model differs from CSP and why it's better.

Re: WebAssembly: a binary format for the web

#116

Post by ycosynot »

dbpokorny wrote: post #34

As far as the intersection of (innovation in web technology) and (innovation in programming languages) is concerned, I think the focus on performance is like going backwards in time, perhaps to the mid 90s. I feel like these innovations are being turned into a kind of "social media spectacle" with relatively little discussion of what innovation really means in this context. For example: I don't understand why Python,…

Doesn't web assembly prevent the idea? More and more wall-gardening. Then you'll see, you'll only be able to run licenced assemblies, because now, it's not transparent. And I bet it'll cost something, the licence. And I bet it won't be open source, so we can't learn from what they do. Another barrier to entry... "Google, Microsoft, Mozilla, and a few other people have been secretly toiling away in a new W3C WebAssembly". Another loss of freedom for the user, which isn't able to modify the website anymore, is he? We could have imagined extension which include best deals from competitors, but we can't imagine them anymore, because we need this speed so very much. I am again impressed by such demonstration of altruism.

Re: WebAssembly: a binary format for the web

#117

Post by sciurus »

zmmmmm wrote: post #113
luhn wrote: post #105

Earlier quoted context omitted.

> I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. Not really. Almost all websites obfuscate/minify their Javascript now, making manually interpreting the code much less than "trivial." I think WebAssembly will be no worse to figure out than obfuscated Javascript.

I think it will be much worse. Minified Javascript is pretty easy to turn back into something moderately understandable just by "prettifying" it. I do this all the time. It works pretty well because it started as Javascript, so turning it back into Javascript has a relatively clean mapping. WebAssembly will have started as some other language or even as no language at all - there may be no mapping back to anything Ja…

True, but this is already happening with asm.js. Is webassembly any more objectionable than that? Instead of causing existing applications to further obfuscate their code, it seems to be bringing new types of applications to the browser.

Re: WebAssembly: a binary format for the web

#118

Post by pcwalton »

denniskane wrote: post #30
corysama wrote: post #19

Earlier quoted context omitted.

In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's wo…

Portable Native Client is a really huge project that takes a lot of PhD-level talent to implement correctly, and it requires a very specific type of organization that has the requisite "will" and "way" to make it happen. Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large s…

> Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do.

And implementing a modern JS engine isn't? Or developing Rust? Come on.

The objections that many other browser vendors have to integrating PNaCl into the Web platform have been detailed repeatedly and have nothing to do with "X browser vendor doesn't have the talent on staff to implement the technology".

Re: WebAssembly: a binary format for the web

#119

Post by Stratoscope »

mstade wrote: post #25
corysama wrote: post #2

A good talk from a week ago on WebAssembly: https://www.youtube.com/watch?v=NhAPPQqKCi8

Merits of the contents aside, the guy presenting has a very judgmental and condescending tone making it difficult to appreciate what he's actually saying. Saying things like "this doesn't look anything like a programming language, especially if you're coming from the javascript world" or "I will explain shared memory multi-threading in a bit, especially for the front end developers" really doesn't help. I find statem…

I'm really sensitive to the issue you mention, and I appreciate your bringing it up.

It annoys me no end when someone talks down to me, or maybe even worse, asks about my skill level in a particular area when the implication is that they will then know how to dumb down what they're saying to a level that even I may understand.

But after watching the first 15 minutes of the video, I'm not seeing any kind of judgmental or condescending tone. Was it something in the remaining half hour?

He did ask for a show of hands of front end vs. native developers, but you have to admit that front end developers who've only done front end may never have been exposed to the concept of threads with shared memory - his topic for the next few minutes.

So my suggestion is to give it another shot. Based on the first 15 minutes, it seems like a fairly interesting and insightful talk.

Re: WebAssembly: a binary format for the web

#120

Post by pcwalton »

derefr wrote: post #22
josteink wrote: post #5

Earlier quoted context omitted.

PNaCl is cancer to the web and requires Google Spyware. No thanks.

PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.

For a feature to not be proprietary in the modern browser landscape, it has to have multiple parties able to participate in the design. Including the core design decisions of "should we use JS as a basis" (the consensus solution) vs. "should we use LLVM as a basis" (the PNaCl solution).
Post reply on HN