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

WebAssembly

developer.mozilla.org

Post reply on HN
Print view View original

71–80 of 98 posts

Re: WebAssembly

#71

Post by infogulch »

pjmlp wrote: post #68
gandalfgeek wrote: post #46

Wasm is exciting because not only is it a clean, elegant instruction set that has learned a lot from the design warts of JVM and .NET, it also has formal verification as a first-class design goal. This makes it interesting for high-trust environments outside the web context as well. I made a couple of short explainer videos on it: - design goals and instruction set: https://youtu.be/VOaSaShAYb0 - mechanizing safety p…

And yet, "Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro

This came across HN before. [1] My conclusion then:

> Notably, they don't appear to even try to break the WA-host memory barrier, which I actually find to be a validation of the core design goal of WebAssembly: isolate the damage a vulnerable program can inflict to the memory space (and thus also output) of that program. Protect the host from the program, but not the program from itself. Also, maybe don't dump WA output you can't validate directly into DOM.

[1]: https://news.ycombinator.com/item?id=24216764

Re: WebAssembly

#72

Post by pjmlp »

infogulch wrote: post #71
pjmlp wrote: post #68

Earlier quoted context omitted.

And yet, "Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro

This came across HN before. [1] My conclusion then: > Notably, they don't appear to even try to break the WA-host memory barrier, which I actually find to be a validation of the core design goal of WebAssembly: isolate the damage a vulnerable program can inflict to the memory space (and thus also output) of that program. Protect the host from the program, but not the program from itself. Also, maybe don't dump WA out…

Regardless, WebAssembly just got one security group doing research against it, I expect plenty more to switch their attention into it, as WebAssemly slowly starts to gather more market share.

> Protect the host from the program, but not the program from itself.

All nice and dandy, except that the goal of WebAssembly is to extend the host, and have the host be dependant on the program behaviour.

A host unaware that the program is compromised can be led to take decisions that it wouldn't otherwise do, like allow a basic user to acquire admin credentials, that were supposedly correctly validated by the program.

I am really eager to see the amount of CVE's on WebAssembly to start poping up, then the whole WebAssembly advocates can tell the world why we had to ditch PNaCL and CrossBridge, 10 years of regress, and get the same outcome in the end.

Re: WebAssembly

#73

Post by pjmlp »

AgentME wrote: post #70
pjmlp wrote: post #69

Earlier quoted context omitted.

You cannot disable wasm.

This isn't true. If you block javascript from running, then that will include blocking WebAssembly. WebAssembly is only started through javascript, and if things ever changes so that webpages can include WebAssembly directly, presumably it will also be controlled by the same browser settings that control whether javascript is executed.

Yeah, but then you block everything and not only wasm.

Re: WebAssembly

#74

Post by FlashBlaze »

preommr wrote: post #37

My 2c about wasm so far: I've tried go, rust, c/cpp, webassembly. go - big bundle sizes because of gc I am guessing, idk. c/cpp - I haven't touched c/cpp in a really really long time, but probably the other really good fit. rust - I see rust as the successor to what I would've used c/cpp for, but not sure if rust ecosystem is still fully there. Last time, I had some weird issues with wasm-bindgen. AssemblyScript(AS)…

Really off-topic, but I have recently started learning Go and also just looked into V. The simple hello world compiled binary of Go is 2088KB while that of V is 415KB. I'm on Windows. So is the large size solely due to GC?

Re: WebAssembly

#75

Post by afiori »

pjmlp wrote: post #72
infogulch wrote: post #71

Earlier quoted context omitted.

This came across HN before. [1] My conclusion then: > Notably, they don't appear to even try to break the WA-host memory barrier, which I actually find to be a validation of the core design goal of WebAssembly: isolate the damage a vulnerable program can inflict to the memory space (and thus also output) of that program. Protect the host from the program, but not the program from itself. Also, maybe don't dump WA out…

Regardless, WebAssembly just got one security group doing research against it, I expect plenty more to switch their attention into it, as WebAssemly slowly starts to gather more market share. > Protect the host from the program, but not the program from itself. All nice and dandy, except that the goal of WebAssembly is to extend the host, and have the host be dependant on the program behaviour. A host unaware that th…

In this context the security guarantees are geared toward the attack threath the web faces: sandboxing untrusted code.

You could say that this is the most web-specific aspect of Web Assebly

Re: WebAssembly

#76

Post by afiori »

pshc wrote: post #57
Kuinox wrote: post #42

Earlier quoted context omitted.

They can bake the ad servers side in the binaries.

They could do bake ads in JS too, but websites aren’t really incentivized to do so as it would increase latency and complexity.

And also advertizers rightly do not trust the content provider not to lie about how many times they showed the ad.

Re: WebAssembly

#77

Post by rasz »

pjmlp wrote: post #69
AgentME wrote: post #4

Earlier quoted context omitted.

How is this any different than getting ads from minified blobs of javascript?

You cannot disable wasm.

    WebAssembly
    WebAssembly {compile: ƒ, validate: ƒ, instantiate: ƒ, compileStreaming: ƒ, instantiateStreaming: ƒ, …}
    delete WebAssembly
    Uncaught ReferenceError: WebAssembly is not defined

Re: WebAssembly

#78

Post by rasz »

catlifeonmars wrote: post #17
nyolfen wrote: post #15

Earlier quoted context omitted.

what i am envisioning here is the content of a webpage compiled with ads therein. it would be desirable by the googles of the world for this very reason.

This is still possible using JavaScript, and yet it is not widely seen. You can think of WebAssembly as another mechanism for executing code in the browser in the context of a web page. JavaScript is still required to (1) load the wasm binary, (2) evaluate it and (3) connect it to DOM APIs or really anything outside of the isolated wasm execution context.

How you block some forms of tracking/ads is you inject your own STUB javascript functionality before the offending script loads.

https://github.com/uBlock-user/uBO-Scriptlets

This wont work with webassembly.

Re: WebAssembly

#79

Post by rasz »

Waterluvian wrote: post #12
nyolfen wrote: post #3

i am not looking forward to having ads delivered by binary blobs. say farewell to the age of client-side scripting.

I don't think I've ever blocked an ad by way of javascript. My blocking is all done by pattern matching a blacklist of origins.

Thas means there are websites you cant load at all because ad code was bundled in the main html.

Re: WebAssembly

#80

Post by rasz »

AgentME wrote: post #4
nyolfen wrote: post #3

i am not looking forward to having ads delivered by binary blobs. say farewell to the age of client-side scripting.

How is this any different than getting ads from minified blobs of javascript?

doesnt matter if its minified as long as you can

    window.console.clear = function arsehole() {console.log(arsehole.caller, "Asshole script called console.clear()")}
before it executes

Stuff state of the art adblockers (uBO) inject to block ads today: https://raw.githubusercontent.com/uBlock-user/uBO-Scriptlets...

Post reply on HN