4 ms·

Not being familiar with the usage of SharedArrayBuffer, is disabling it the nuclear option (eg bad for everyone involved and clearly not the best option if othe

by hirsin 9y ago

Not being familiar with the usage of SharedArrayBuffer, is disabling it the nuclear option (eg bad for everyone involved and clearly not the best option if others existed)? I see over 100 pages of commits on github referencing it, which tells me it's not exactly rare?

Game_Ender 9y ago
High performance applications need to share memory between threads. That feature let you do it in JS, and is the basis of the future shared memory multithreading feature in Web Assembly. So if you want the next Photoshop or Final Cut Pro to be browser based we’ll need to make it work securely.
- ec109685 9y ago
  Seems like virtualization is the way to go for JavaScript. Hypervisors such as XEN in HVM mode with modern processors don’t result in a large performance penalty, so I imagine Chrome will gravitate towards it for running untrusted code.
  - pcwalton 9y ago
    If running JS (that can access the DOM) in a separate process from the renderer were feasible, browsers would have done it long ago.
    - devit 9y ago
      You just need to run it in a process without any secret data from other origins or the browser/system. That seems feasible without significant performance loss in most cases. There is still a fingerprinting issue though that might not be possible to fully remove without huge performance cost.
      - contrarian_ 9y ago
        Process isolation does not prevent Spectre. In theory, you can carry out Spectre over the network.
      - pcwalton 9y ago
        That's what Site Isolation is, but it has significant drawbacks: it cannot always protect against cross origin cookie leakage, and pages can have a lot more cross domain iframes than a reasonable process limit can account for.
alangpierce 9y ago
It looks like SharedArrayBuffer was released in July 2017 in Chrome and August 2017 in Firefox [1], so I think it's new enough that almost any non-internal website using it would need a fallback anyway. So my impression is it's not quite as nuclear as other web technologies being disabled, but still pretty bad. I personally used it for a experimental hackathon project in April (in Chrome Canary, behind a flag), and I believe it was necessary for one of the aspects of the project, so it's a shame to see it disabled, but my impression is it's more "future web tech" than "the way the web works today". [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

by hirsin 9y ago

Game_Ender 9y ago

High performance applications need to share memory between threads. That feature let you do it in JS, and is the basis of the future shared memory multithreading feature in Web Assembly. So if you want the next Photoshop or Final Cut Pro to be browser based we’ll need to make it work securely.

ec109685 9y ago
Seems like virtualization is the way to go for JavaScript. Hypervisors such as XEN in HVM mode with modern processors don’t result in a large performance penalty, so I imagine Chrome will gravitate towards it for running untrusted code.
- pcwalton 9y ago
  If running JS (that can access the DOM) in a separate process from the renderer were feasible, browsers would have done it long ago.
  - devit 9y ago
    You just need to run it in a process without any secret data from other origins or the browser/system. That seems feasible without significant performance loss in most cases. There is still a fingerprinting issue though that might not be possible to fully remove without huge performance cost.
    - contrarian_ 9y ago
      Process isolation does not prevent Spectre. In theory, you can carry out Spectre over the network.
    - pcwalton 9y ago
      That's what Site Isolation is, but it has significant drawbacks: it cannot always protect against cross origin cookie leakage, and pages can have a lot more cross domain iframes than a reasonable process limit can account for.

alangpierce 9y ago

It looks like SharedArrayBuffer was released in July 2017 in Chrome and August 2017 in Firefox [1], so I think it's new enough that almost any non-internal website using it would need a fallback anyway. So my impression is it's not quite as nuclear as other web technologies being disabled, but still pretty bad. I personally used it for a experimental hackathon project in April (in Chrome Canary, behind a flag), and I believe it was necessary for one of the aspects of the project, so it's a shame to see it disabled, but my impression is it's more "future web tech" than "the way the web works today". [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...