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

91–98 of 98 posts

Re: WebAssembly

#91

Post by Alexendoo »

rasz wrote: post #78
catlifeonmars wrote: post #17

Earlier quoted context omitted.

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.

None of these scriptlets would break if a site uses WASM, they're utilities for things like adding/removing/mutating elements from the DOM, modifying localStorage, stopping alert()

executesitefunction.js could arguably be effected, but that relies on a site installing a particular function on window, which isn't required when using JS, and could be still done where the function is backed by WASM

Re: WebAssembly

#92

Post by pjmlp »

afiori wrote: post #89
pjmlp wrote: post #83

Earlier quoted context omitted.

What matters is if WebAssembly actually holds the security guarantees used to sell it in detriment of PNaCL and CrossBridge. If not, then it was just smoke and mirrors to sell an agenda and delay progress 10 years. "Unreal Engine 3 Support for Adobe Flash Player - Epic Citadel" -> 2011 https://www.youtube.com/watch?v=xzyCTt5KLKU

I know very little about PNaCl, I cannot say whether wasm is better or worse, I am just defending the existence of the specific role for webassembly: lightweight sandboxing with strong sandboxing guarantees. Personally I have high expectations in this strategy. Regarding the "Everything Old Is New Again: Binary Security of WebAssembly" they find that compiling something like photoshop to a single wasm module forfeits…

I lost count how many bytecode formats and sandboxes I have used, or read about.

WebAssembly is what the browsers now offer us, so I have to accept it, that doesn't mean I buy into the security story, specially when basic stuff like bounds checking inside the same linear memory segment is not considered as relevant.

That paper is just the first of many yet to come.

Re: WebAssembly

#93

Post by rasz »

Alexendoo wrote: post #91
rasz wrote: post #78

Earlier quoted context omitted.

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.

None of these scriptlets would break if a site uses WASM, they're utilities for things like adding/removing/mutating elements from the DOM, modifying localStorage, stopping alert() executesitefunction.js could arguably be effected, but that relies on a site installing a particular function on window, which isn't required when using JS, and could be still done where the function is backed by WASM

Hmm this repo doesnt have the currently used scriptlets.js file, weird. I think this is the official one https://git.furworks.de/opensourcemirror/ublock-origin/src/b...

A lot of stubs, a lot of functionality to kill a script when tripping certain trigger action, or force some properties.

Re: WebAssembly

#94

Post by newintellectual »

Is making WASM able to operate almost completely independently of Javascript a design goal? In other words, be able to access and manipulate the DOM, CSS, browser functionality, and so on, without having to use Javascript.

Re: WebAssembly

#95

Post by haberman »

jez wrote: post #66
haberman wrote: post #54

Earlier quoted context omitted.

> I struggled a lot using Emscripten to port FFmpeg to wasm - you have to compile EVERY dependency to wasm This is a scenario where the Bazel model is a good fit IMHO. Bazel rebuilds all of your dependencies from source. This makes it easy to compile all of your dependencies with an extra flag (eg -fsanitize=address for ASAN) or using a different compiler (eg Emscripten). While it can be annoying to wait for the worl…

Do you have an example of getting bazel to work with emscripten? I’ll share mine if you share yours: https://github.com/sorbet/sorbet/tree/master/tools/toolchain... When we set this up to compile Sorbet (C++ codebase) for https://sorbet.run , it involved what I considered an inordinate amount of boilerplate and arcana. To be fair since we set it up it’s hardly ever needed to be touched, and I could probably cargo cul…

Yikes. That definitely seems more complicated than it should be. I have not used Emscripten in this way before, I was going from my experience of passing custom flags like -fsanitize=address.

I was under the impression that Emscripten was just an alternative compiler binary, such that you could just use CC=emcc. Is that not the case?

Re: WebAssembly

#96

Post by afiori »

pjmlp wrote: post #92
afiori wrote: post #89

Earlier quoted context omitted.

I know very little about PNaCl, I cannot say whether wasm is better or worse, I am just defending the existence of the specific role for webassembly: lightweight sandboxing with strong sandboxing guarantees. Personally I have high expectations in this strategy. Regarding the "Everything Old Is New Again: Binary Security of WebAssembly" they find that compiling something like photoshop to a single wasm module forfeits…

I lost count how many bytecode formats and sandboxes I have used, or read about. WebAssembly is what the browsers now offer us, so I have to accept it, that doesn't mean I buy into the security story, specially when basic stuff like bounds checking inside the same linear memory segment is not considered as relevant. That paper is just the first of many yet to come.

That is fair, trust should be earned, not granted; I hope we will see a world where that will happen :)

Re: WebAssembly

#97

Post by AgentME »

pjmlp wrote: post #73
AgentME wrote: post #70

Earlier quoted context omitted.

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.

Why would you want to block wasm specifically? There's nothing it can do that javascript can't.

Re: WebAssembly

#98

Post by jez »

haberman wrote: post #95
jez wrote: post #66

Earlier quoted context omitted.

Do you have an example of getting bazel to work with emscripten? I’ll share mine if you share yours: https://github.com/sorbet/sorbet/tree/master/tools/toolchain... When we set this up to compile Sorbet (C++ codebase) for https://sorbet.run , it involved what I considered an inordinate amount of boilerplate and arcana. To be fair since we set it up it’s hardly ever needed to be touched, and I could probably cargo cul…

Yikes. That definitely seems more complicated than it should be. I have not used Emscripten in this way before, I was going from my experience of passing custom flags like -fsanitize=address. I was under the impression that Emscripten was just an alternative compiler binary, such that you could just use CC=emcc. Is that not the case?

The trick is that to provide Bazel with a custom toolchain involves way more than just setting an environment variable, because Bazel wants to control installing and making available the compiler reliably (e.g., what if `emcc` is not present on the system where Bazel was invoked? Bazel solves that problem by fetching it and building it for that system)

There are projects that provide drop-in support for custom toolchains (e.g., we use this project[0] in Sorbet to fetch and build a custom LLVM/Clang toolchain for every host we build on (rather than relying on the system toolchain). But I'm not aware of a project that has done that for Emscripten. Maybe it would be as easy as plucking out what we've done in our project into a project that others could depend on, but to quote a colleague:

> Setting up a cc toolchain in Bazel is a unique sort of pain.

[0] https://github.com/grailbio/bazel-toolchain/

Post reply on HN