Hacker News Reader

Comment by ddtaylor | Hacker News Reader

I tried searching does anyone know if this is available in Firefox yet?

Nope: https://bugzilla.mozilla.org/show_bug.cgi?id=1389458

WebAssembly threads mostly depend on SharedArrayBuffer, which was yanked by everyone for security reasons. Chrome rearranged their browser memory model and re-enabled it, which let them deliver this feature while everyone else still has blockers.

https://caniuse.com/#feat=sharedarraybuffer

https://rustwasm.github.io/2018/10/24/multithreading-rust-an...

As it says in pretty_bubbles link, enable javascript.options.shared_memory in about:config

To be clear, Chrome re-enabled it without implementing mitigations that other browsers are likely to consider a basic requirement before re-enabling. A clear case of product or marketing trumping security...

Chrome is a new IE

They implemented site isolation and cross-origin read blocking. Unless the OS is also vulnerable, shouldn't that be enough to ensure sites can't access anything not already accessible to the current origin?

No, that's not enough. I can provide examples in a non-public venue.

Bold claim. If you can prove that, I'm sure google will give you a nice chrome security payout for letting them know. If they won't, why not pull a Google security style blog post exposing it?

Google won't give me a payout for a problem they already know about. I know they know about it, because we have discussed it with them. In case it wasn't clear: I work on a web browser that is not Chrome.

> why not pull a Google security style blog post exposing it

Because I don't think publicly exposing specific security problems in shipping software is necessarily the right thing to do.

> Because I don't think publicly exposing specific security problems in shipping software is necessarily the right thing to do.

I'm no security engineer, but isn't it best practice to expose security risks instead of letting them get knowingly exploited, especially if the parent company considers it designed as intended?

It depends on the exact situation. In this case there is coordination happening among multiple vendors who are working on various fixes in this space, which complicates things. Also complicated is that apart from "don't use Chrome" there's no useful mitigation users can do for this risk, and most Chrome users would never see any security-related blog post, nor act on it if they did.

There are times when "screw you, I'm going public with this" is in fact the right thing to do. Again, in this particular case I don't think it is.

What are some of these additional mitigations other browsers are eyeing?

The last proposal I saw floated involved sites sending a header to opt in to SharedArrayBuffer and the browser ensuring that all successful loads such a site does are done with CORS enabled. That ensures that such a site only has access to data that is either same-origin or explicitly shared by the other sites it's pulling data from, so there's no point in doing a spectre attack to start with.

You can enable it on Firefox nightly. I think the config name is something with shared_mem.

It's javascript.options.shared_memory. It's currently set to false in Firefox 63.

As other people already wrote, it was disabled at the beginning of the year because of timing attacks related to Spectre and Meltdown. Details at https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

We had this thread on HN about multithreading Rust with WASM https://news.ycombinator.com/item?id=18283110

Reply on news.ycombinator.com