5 ms·

Nope: https://bugzilla.mozilla.org/show_bug.cgi?id=1389458 https://bugzilla.mozilla.org/show_bug.cgi?id=1389458 WebAssembly threads mostly depend on SharedArra

Nope: https://bugzilla.mozilla.org/show_bug.cgi?id=1389458 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://caniuse.com/#feat=sharedarraybuffer

pretty_bubbles 8y ago
https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html https://rustwasm.github.io/2018/10/24/multithreading-rust-an...
markdog12 8y ago
As it says in pretty_bubbles link, enable javascript.options.shared_memory in about:config
bzbarsky 8y ago
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...
- Svoka 8y ago
  Chrome is a new IE
- Ajedi32 8y ago
  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?
  - bzbarsky 8y ago
    No, that's not enough. I can provide examples in a non-public venue.
    - mrep 8y ago
      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?
      - bzbarsky 8y ago
        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.
        mrep 8y ago
        > 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?
        bzbarsky 8y ago
        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.
- zamadatix 8y ago
  What are some of these additional mitigations other browsers are eyeing?
  - bzbarsky 8y ago
    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.

pretty_bubbles 8y ago

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

markdog12 8y ago

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

bzbarsky 8y ago

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...

Svoka 8y ago
Chrome is a new IE
Ajedi32 8y ago
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?
- bzbarsky 8y ago
  No, that's not enough. I can provide examples in a non-public venue.
  - mrep 8y ago
    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?
    - bzbarsky 8y ago
      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.
      - mrep 8y ago
        > 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?
        bzbarsky 8y ago
        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.
zamadatix 8y ago
What are some of these additional mitigations other browsers are eyeing?
- bzbarsky 8y ago
  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.