Live data from Hacker News

W3C recommends WebAssembly

w3.org

151–160 of 350 posts

Re: W3C recommends WebAssembly

#151

Earlier quoted context omitted.

I think about this too. uBlock origin is already running into issues with trackers disguising themselves as first-party, what about when those trackers are genuinely first-party, and bundled with the page's js (which you can't just outright block)? What happens when those trackers are bundled and compiled to wasm along with the sites js? Do we then analyze the wasm and try to guess which parts are necessary for a sit…

And this is why if blocking the "web"site JavaScript breaks the "web"site itself, then it never was a web site to start with! (Trackers using these kinds of tactics was only a matter of time between trackers and blockers...)

How I wish the problem were only breaking the "web" - these days, blocking tracking scripts on my router ends up breaking my desktop applications...

(Example of the day, Parsec; example from yesterday, NVidia's driver-update software :( )

Re: W3C recommends WebAssembly

#152
post #8

This is bad for frontend JavaScript being "open" for review, right? Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work. Yes, I'm sure there will be reverse-compilation tools for WASM, but still.

The advertisement industry is huge and it's the driving force behind Google and many other companies. webassembly is encouraging websites to dump megabytes of binary code in browsers. Obfuscated, analysis-resistant code to ensure that people cannot disable ads and tracking. It's appalling that we are accepting this.

And thanks to ubiquitous HTTPS, there's no way to analyze what information is leaving your device (especially on a mobile device).

Re: W3C recommends WebAssembly

#153

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

This already happens. See Figma: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps faster than the Electron mess we have now.

Re: W3C recommends WebAssembly

#155
post #118

Earlier quoted context omitted.

A binary format is no more obfuscated than minified JS? What now? Going to need some clarification on how that's the case.

WASM is a binary and a text format. You can turn any WASM binary to the text format and have a readable version of the blob. Firefox can automatically show you the text version of a WASM blob. So no, there is no difference with a minified JS. Just because there are in a text format don't make them any more easy to reverse engineer.

Unless I'm completely missing something the "text version" you're talking about is just WASM and there's quite a difference between that and minified JS.

ex:

   end $label121
   get_local $var7
   get_local $var9
   call $func3444
   get_local $var7
   call $func1500

Re: W3C recommends WebAssembly

#156
post #92
post #52

Earlier quoted context omitted.

When was the last time you were able to unminify a javascript file that you wanted to investigate and were able to make sense out of it?

Javascript is pretty accessible even when minified and optimised via something like closure. WASM requires a lot more knowhow to reverse engineer; I've had to do it a few times for CTFs and some blockchain-related tools that use them, and it's a lot trickier compared to JS.

The wat format seems decently readable. You can convert between the two easily unless there’s obfuscation tools already.

Re: W3C recommends WebAssembly

#157

Earlier quoted context omitted.

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

This already happens. See Figma: https://www.figma.com/blog/webassembly-cut-figmas-load-time-... To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps fa…

[deleted]

Re: W3C recommends WebAssembly

#158

Earlier quoted context omitted.

A binary format is no more obfuscated than minified JS? What now? Going to need some clarification on how that's the case.

I guess he's saying that an unminifier tool is effectively no different than a decompiler, and both are basically unreadable without it. That said, I don't know of any webassembly decompilers, although I guess they must exist by this point. But also historically decompilers have been imperfect as some of the structure of the code is lost in the compilation process and has to be inferred, sometimes incorrectly, by the…

That is correct, a minified JS will preserve most of the semantics of the original program. And since the original source can come from any language, how would one know which decompiler to use.

Re: W3C recommends WebAssembly

#159
post #134

Earlier quoted context omitted.

It's a binary format originally based on minified JS, with a standard textual form, and which can be viewed and debugged with exactly the same tools (and ease) as minified JS.

Can you point me to an example of this?

Thanks for the downvote whoever. Honestly, I want an example of how it "can be viewed and debugged with exactly the same tools (and ease) as minified JS".

I see nothing that states that is the case.

Re: W3C recommends WebAssembly

#160
post #118

Earlier quoted context omitted.

WASM is a binary and a text format. You can turn any WASM binary to the text format and have a readable version of the blob. Firefox can automatically show you the text version of a WASM blob. So no, there is no difference with a minified JS. Just because there are in a text format don't make them any more easy to reverse engineer.

Unless I'm completely missing something the "text version" you're talking about is just WASM and there's quite a difference between that and minified JS. ex: end $label121 get_local $var7 get_local $var9 call $func3444 get_local $var7 call $func1500

Yes this is what I am talking about. Once you know the instruction, I fail to see how it is more difficult to understand than javascript.
Post reply on HN