16 ms·

Safely Reviving Shared Memory

174 points by MindGods 6y ago

Santosh83 6y ago
So how will these headers work for shared hosting sites where you normally cannot modify the hosting provider's HTTP server?
- simlevesque 6y ago
  You can set headers with .htaccess.
  - birdyrooster 6y ago
    And boy do they, I used to be a shared hosting administrator and sometimes people would do stupid things like create 10MB .htaccess files with the subnets of all of the countries they wanted to block and then would call to complain that their site was loading slow. (Probably not a great idea to parse a config file for every request but at least it exists)
  - danudey 6y ago
    Only in specific situations, where the site is using Apache and has .htaccess files enabled. I would argue that using Apache in the first place is non-optimal, but enabling arbitrary .htaccess files for clients is also a potential disaster. Then again, I suppose there are enough people out there who just want to FTP up their wordpress code and call it a day, so... ugh.
    - the8472 6y ago
      If you're only uploading some stuff to wordpress do you need shared array buffers?
    - duskwuff 6y ago
      WordPress expects a working .htaccess for its URL structure, as do most modern PHP applications. So virtually all shared hosts will support .htaccess. > I would argue that using Apache in the first place is non-optimal What would you prefer? nginx is not suited to shared environments at all.
      - john-shaffer 6y ago
        > WordPress expects a working .htaccess for its URL structure I haven't heard this. I'm running WordPress via NGINX with no issues.
- deleted 6y ago
  [deleted]
- zelly 6y ago
  You only need this if you're doing multithreaded WebAssembly. The typical applications that need that (e.g. games) also require a huge amount of infrastructure, let alone a web server config.
  - pjmlp 6y ago
    Flash games don't need a huge amount of infrastructure.
    - Multicomp 6y ago
      Yep, but like rolling an XML web service or posting html forms, that would (be far too boring) || (come with its own set of trade offs). If we could get an open-source flash player that was not so insecure and/or make an open source equivalent to Adobe air that spits out web standard code, we would not lose the flexibility that adobe flash gave us. we really don't have an answer to losing Adobe flash, similarly to when we lost the spaghetti code enabling yet so pragmatically useful visual basic 6.
      - pjmlp 6y ago
        Here is the 2011 version of WebAssembly for Flash. https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ And here is Unreal Engine 3 using it, https://www.youtube.com/watch?v=UQiUP2Hd60Y https://www.youtube.com/watch?v=UQiUP2Hd60Y WebAssembly has delayed progress for 10 years, politcs that is all, and for what? "Everything Old is New Again: Binary Security of WebAssembly" - USENIX 2020 http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs...
nazgulsenpai 6y ago
I played with the K on the word HACKS at the top of the screen for far too long.
gridlockd 6y ago
"The system maintains backwards compatibility. We cannot ask billions of websites to rewrite their code." I don't understand this requirement. Very few sites use SharedArrayBuffer, those few that do probably had to rewrite code to deal with it being disabled. I also don't understand how cross-origin has anything to do with it either. Either your sandbox works, in that case cross-origin isolation shouldn't matter, or it doesn't work, in which case cross-origin isolation is not a real protection. Am I missing something here? Firefox is only maybe 5% of users and it has other performance problems, if SharedArrayBuffer doesn't "just work" then I'm inclined to have them take that performance hit or use a different browser.
- jefftk 6y ago
  To safely use SharedArrayBuffer you have to give something else up, like the ability to fetch arbitrary resources with <img>. Most sites that want SharedArrayBuffer would be fine with a tradeoff like this, and so this post describes a way they can opt in to the necessary restrictions.
- dfabulich 6y ago
  Under Spectre, if the attacker can run SharedArrayBuffer code in your process, even "sandboxed," it can read memory from anywhere else in that process. https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zME... So I guess you're right that if the sandbox "works" you don't care about cross-origin isolation, but it turns out that sandboxes don't work if you run multiple sandboxes in the same process. The mitigation browsers have chosen is to isolate each origin in its own process, preventing other origins from communicating with it. To regain access to SharedArrayBuffer, you have to opt in to this extreme form of cross-origin isolation. It would be nice to just make the whole web default to cross-origin isolation, but tons of websites rely on cross-origin communication features, and browsers can't just force them all to be compatible with isolation, so isolation has to be opt-in.
  - gridlockd 6y ago
    How exactly does site-isolation prevent cross-origin communication that doesn't rely on SharedArrayBuffer, i.e. that vast majority of use-cases? It's just message passing. I can see that site-isolation is arguably too expensive on mobile and why you might want an opt-in mechanism there, somewhere down the line. However, I don't think there are good arguments for not just enabling it on Desktop right now, without making developers jump through hoops. Until Chrome enables SharedArrayBuffers on mobile, I have no reason to care anyway.
pjmlp 6y ago
Nice to see it is eventually going to be re-enabled, however if Firefox doesn't make it as easy as Chrome, that is what most costumers will focus on regarding applications that make use of threading alongside WebAssembly.
- domenicd 6y ago
  In Chrome we already require these headers on mobile, and plan to require them on desktop soon.
  - pjmlp 6y ago
    Fair enough, so far I only toyed around with the desktop version. Just making a note that if you want to foster PWAs over native, or Electron workarounds, better not make us jump through many hoops.
dfabulich 6y ago
In this article, Mozilla refers to new HTTP headers, COOP and COEP, that can be used to opt-in to cross-origin isolation and thereby grant access to features that would be dangerous under Spectre side channel attacks. IMO, this Google doc is a better explainer of COOP and COEP, how they work, and why they help. https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zME... > "We now assume any active code can read any data in the same address space. The plan going forward must be to keep sensitive cross-origin data out of address spaces that run untrustworthy code, rather than relying on in-process checks."
- domenicd 6y ago
  The following articles also go into more detail: - https://web.dev/coop-coep/ https://web.dev/coop-coep/ - https://web.dev/why-coop-coep/ https://web.dev/why-coop-coep/ although I think the Mozilla article in the OP is a really nice, succinct high-level overview.
- ekr 6y ago
  I may sound like a grumpy old man, but I really really dislike this non-stop influx of complexity into every level of the stack. This is a clear case of an abstraction leaking. Microprocessor vulnerabilities should never lead to changes in a high level application protocol like that. The work needed to implement an HTTP server is growing and growing and growing. There was some speculation a few days ago on why this is happening, and why big companies are benefiting from this. I don't think there's any conscious conspiracy anywhere, just a lot of people try to make a name for themselves. (There was a discussion on this a few days ago here: https://news.ycombinator.com/item?id=23833362 https://news.ycombinator.com/item?id=23833362) But I just hate this growing complexity everywhere. HTTP can and should be much simpler than it's becoming.
  - joosters 6y ago
    None of these changes impact HTTP server code. Pages that run javascript might want to set some new headers, but setting headers is something that web servers always have to do. Changing a site config to send some new headers is work for a web page creator, not the HTTP server developer. And the changes are backwards compatible, so you don't actually need to do anything if you don't want to. This new complexity is about javascript execution, and creating a browser that can run javascript has never been simple!
azmenak 6y ago
While still a ways away, its great to see progress on this front. After SABs were disabled, the use cases and power of WebWorkers shrank considerably. Very excited to dive back into some WASM/WebWorker projects that got abandoned due to performance limitations.
waynecochran 6y ago
Imagine what the world would be like if didn't need to worry about bad actors. This is a considerable amount of engineering energy to make this safe. I know safety isn't all about about malicious attacks, but I like to imagine living in a world without the need for locks, passwords, keys, safes, signatures, contracts, lawyers, ... we would probably all be fed and populating the solar system by now.
- IgorPartola 6y ago
  I have a hard time imagining such a world precisely because being a bad actor is a part of our DNA and the DNA of many many animals, plants, bacteria, and fungi we interact with. The unintended consequence of lack of selfishness could be mind boggling. Think about it this way: Silicone Valley mostly provides the last 5% of the tech needed to make any given product. You know where the rest comes from? Military tech that eventually makes its way to civilian use. Things like semiconductors, the Internet, GPS, rocket propulsion, etc. No conflict == no military == no tech == we wouldn’t be having this conversation. I am definitely not saying we couldn’t all be a whole lot nicer to each other. But I am saying that we wouldn’t be human if that was wired into us.
  - clusterfish 6y ago
    The military's role in this seems very much rooted in selfishness and adversity, to the extent that a more cooperative species (let's be honest it's not gonna be us) would find plenty of non-military motivation to do similar amounts of basic and applied research.
    - mnsc 6y ago
      Is there a name for the sensation of being born the wrong species?
      - IgorPartola 6y ago
        Maybe in German. I personally regularly curse the fact that I was born a human when I am confronted with uniquely human problems: having to cook, sweating my behind off, having to waste time using the bathroom, experiencing strong emotions like anger or jealousy or envy. These are the things that make us human, but they often times I find them highly annoying and wish my ancestors had evolved out of some of them.
modeless 6y ago
Cool! Looks like SharedArrayBuffer will be re-enabled next week with the release of Firefox 79: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#JavaScript https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel... This will be big for Web Assembly. Real threads will make it possible to port more stuff and get better performance.
- burfog 6y ago
  It's better performance for one web site, at the expense of whatever may be in other tabs or even outside the browser. I really don't want to grant that. Web browsers are failing badly at resource controls. I don't want to hand my whole computer over to a greedy web site. I expect my browser to stop the abusive web site resource consumption, not enable it.
  - codys 6y ago
    While I agree that browsers generally currently appear to exercise poor control over resources like cpu time and memory amount, I'm not sure that aiming to cripple all sites equally is the right tactic here. It seems like better "scheduling" and other resource management would be something that needs work regardless of whether we expose tools to improve web application performance to websites.
inetknght 6y ago
tl;dr: `about:config` -> `dom.workers.serialized-sab-access` -> true Otherwise you risk sites opting in to Spectre. Why Mozilla thinks this is a good thing is beyond me.
- jdlshore 6y ago
  This is either astoundingly bad reading comprehension, or a willful mischaracterization. The whole article is about what they're doing to prevent Spectre-like problems. The config option is their backup plan in case they made a mistake in their threat analysis. All in all, I thought it was a sober and mature approach to the problem.
secondcoming 6y ago
The web is such a mess.
- justAnotherNET 6y ago
  UI is the worst. I can’t tell you the number of web apps that render UI off screen, fail to resize when adjusted, etc
eximius 6y ago
Notably disappointing: Cross-Origin-Opener-Policy must be set on a page to isolate it as the default value is not safe. i.e., if I have a page with sensitive client side data, I need to set this header to prevent a page on a different domain from opening a popup to that page then doing a Spectre-like attack on my web page and exfiltrating that sensitive client side data. I don't actually entirely understand the purpose or effect of Cross-Origin-Embedder-Policy. I thought browsers already blocked cross origin requests without CORS headers in the response that allow it. Does this header UNDO that by default?
- dragonwriter 6y ago
  > I don't actually entirely understand the purpose or effect of Cross-Origin-Embedder-Policy. I thought browsers already blocked cross origin requests without CORS headers in the response that allow it. CORS applies to XHR/fetch APIs, not browser loading of subresources specified in the HTML of the page. COEP optionally extends CORS-type protection to subresources.

174 points by MindGods 6y ago

So how will these headers work for shared hosting sites where you normally cannot modify the hosting provider's HTTP server?

simlevesque 6y ago
You can set headers with .htaccess.
- birdyrooster 6y ago
  And boy do they, I used to be a shared hosting administrator and sometimes people would do stupid things like create 10MB .htaccess files with the subnets of all of the countries they wanted to block and then would call to complain that their site was loading slow. (Probably not a great idea to parse a config file for every request but at least it exists)
- danudey 6y ago
  Only in specific situations, where the site is using Apache and has .htaccess files enabled. I would argue that using Apache in the first place is non-optimal, but enabling arbitrary .htaccess files for clients is also a potential disaster. Then again, I suppose there are enough people out there who just want to FTP up their wordpress code and call it a day, so... ugh.
  - the8472 6y ago
    If you're only uploading some stuff to wordpress do you need shared array buffers?
  - duskwuff 6y ago
    WordPress expects a working .htaccess for its URL structure, as do most modern PHP applications. So virtually all shared hosts will support .htaccess. > I would argue that using Apache in the first place is non-optimal What would you prefer? nginx is not suited to shared environments at all.
    - john-shaffer 6y ago
      > WordPress expects a working .htaccess for its URL structure I haven't heard this. I'm running WordPress via NGINX with no issues.
deleted 6y ago
[deleted]
zelly 6y ago
You only need this if you're doing multithreaded WebAssembly. The typical applications that need that (e.g. games) also require a huge amount of infrastructure, let alone a web server config.
- pjmlp 6y ago
  Flash games don't need a huge amount of infrastructure.
  - Multicomp 6y ago
    Yep, but like rolling an XML web service or posting html forms, that would (be far too boring) || (come with its own set of trade offs). If we could get an open-source flash player that was not so insecure and/or make an open source equivalent to Adobe air that spits out web standard code, we would not lose the flexibility that adobe flash gave us. we really don't have an answer to losing Adobe flash, similarly to when we lost the spaghetti code enabling yet so pragmatically useful visual basic 6.
    - pjmlp 6y ago
      Here is the 2011 version of WebAssembly for Flash. https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ And here is Unreal Engine 3 using it, https://www.youtube.com/watch?v=UQiUP2Hd60Y https://www.youtube.com/watch?v=UQiUP2Hd60Y WebAssembly has delayed progress for 10 years, politcs that is all, and for what? "Everything Old is New Again: Binary Security of WebAssembly" - USENIX 2020 http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs...

nazgulsenpai 6y ago

I played with the K on the word HACKS at the top of the screen for far too long.

gridlockd 6y ago

"The system maintains backwards compatibility. We cannot ask billions of websites to rewrite their code." I don't understand this requirement. Very few sites use SharedArrayBuffer, those few that do probably had to rewrite code to deal with it being disabled. I also don't understand how cross-origin has anything to do with it either. Either your sandbox works, in that case cross-origin isolation shouldn't matter, or it doesn't work, in which case cross-origin isolation is not a real protection. Am I missing something here? Firefox is only maybe 5% of users and it has other performance problems, if SharedArrayBuffer doesn't "just work" then I'm inclined to have them take that performance hit or use a different browser.

jefftk 6y ago
To safely use SharedArrayBuffer you have to give something else up, like the ability to fetch arbitrary resources with <img>. Most sites that want SharedArrayBuffer would be fine with a tradeoff like this, and so this post describes a way they can opt in to the necessary restrictions.
dfabulich 6y ago
Under Spectre, if the attacker can run SharedArrayBuffer code in your process, even "sandboxed," it can read memory from anywhere else in that process. https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zME... So I guess you're right that if the sandbox "works" you don't care about cross-origin isolation, but it turns out that sandboxes don't work if you run multiple sandboxes in the same process. The mitigation browsers have chosen is to isolate each origin in its own process, preventing other origins from communicating with it. To regain access to SharedArrayBuffer, you have to opt in to this extreme form of cross-origin isolation. It would be nice to just make the whole web default to cross-origin isolation, but tons of websites rely on cross-origin communication features, and browsers can't just force them all to be compatible with isolation, so isolation has to be opt-in.
- gridlockd 6y ago
  How exactly does site-isolation prevent cross-origin communication that doesn't rely on SharedArrayBuffer, i.e. that vast majority of use-cases? It's just message passing. I can see that site-isolation is arguably too expensive on mobile and why you might want an opt-in mechanism there, somewhere down the line. However, I don't think there are good arguments for not just enabling it on Desktop right now, without making developers jump through hoops. Until Chrome enables SharedArrayBuffers on mobile, I have no reason to care anyway.

pjmlp 6y ago

Nice to see it is eventually going to be re-enabled, however if Firefox doesn't make it as easy as Chrome, that is what most costumers will focus on regarding applications that make use of threading alongside WebAssembly.

domenicd 6y ago
In Chrome we already require these headers on mobile, and plan to require them on desktop soon.
- pjmlp 6y ago
  Fair enough, so far I only toyed around with the desktop version. Just making a note that if you want to foster PWAs over native, or Electron workarounds, better not make us jump through many hoops.

dfabulich 6y ago

In this article, Mozilla refers to new HTTP headers, COOP and COEP, that can be used to opt-in to cross-origin isolation and thereby grant access to features that would be dangerous under Spectre side channel attacks. IMO, this Google doc is a better explainer of COOP and COEP, how they work, and why they help. https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zME... > "We now assume any active code can read any data in the same address space. The plan going forward must be to keep sensitive cross-origin data out of address spaces that run untrustworthy code, rather than relying on in-process checks."

domenicd 6y ago
The following articles also go into more detail: - https://web.dev/coop-coep/ https://web.dev/coop-coep/ - https://web.dev/why-coop-coep/ https://web.dev/why-coop-coep/ although I think the Mozilla article in the OP is a really nice, succinct high-level overview.
ekr 6y ago
I may sound like a grumpy old man, but I really really dislike this non-stop influx of complexity into every level of the stack. This is a clear case of an abstraction leaking. Microprocessor vulnerabilities should never lead to changes in a high level application protocol like that. The work needed to implement an HTTP server is growing and growing and growing. There was some speculation a few days ago on why this is happening, and why big companies are benefiting from this. I don't think there's any conscious conspiracy anywhere, just a lot of people try to make a name for themselves. (There was a discussion on this a few days ago here: https://news.ycombinator.com/item?id=23833362 https://news.ycombinator.com/item?id=23833362) But I just hate this growing complexity everywhere. HTTP can and should be much simpler than it's becoming.
- joosters 6y ago
  None of these changes impact HTTP server code. Pages that run javascript might want to set some new headers, but setting headers is something that web servers always have to do. Changing a site config to send some new headers is work for a web page creator, not the HTTP server developer. And the changes are backwards compatible, so you don't actually need to do anything if you don't want to. This new complexity is about javascript execution, and creating a browser that can run javascript has never been simple!

azmenak 6y ago

While still a ways away, its great to see progress on this front. After SABs were disabled, the use cases and power of WebWorkers shrank considerably. Very excited to dive back into some WASM/WebWorker projects that got abandoned due to performance limitations.

waynecochran 6y ago

Imagine what the world would be like if didn't need to worry about bad actors. This is a considerable amount of engineering energy to make this safe. I know safety isn't all about about malicious attacks, but I like to imagine living in a world without the need for locks, passwords, keys, safes, signatures, contracts, lawyers, ... we would probably all be fed and populating the solar system by now.

IgorPartola 6y ago
I have a hard time imagining such a world precisely because being a bad actor is a part of our DNA and the DNA of many many animals, plants, bacteria, and fungi we interact with. The unintended consequence of lack of selfishness could be mind boggling. Think about it this way: Silicone Valley mostly provides the last 5% of the tech needed to make any given product. You know where the rest comes from? Military tech that eventually makes its way to civilian use. Things like semiconductors, the Internet, GPS, rocket propulsion, etc. No conflict == no military == no tech == we wouldn’t be having this conversation. I am definitely not saying we couldn’t all be a whole lot nicer to each other. But I am saying that we wouldn’t be human if that was wired into us.
- clusterfish 6y ago
  The military's role in this seems very much rooted in selfishness and adversity, to the extent that a more cooperative species (let's be honest it's not gonna be us) would find plenty of non-military motivation to do similar amounts of basic and applied research.
  - mnsc 6y ago
    Is there a name for the sensation of being born the wrong species?
    - IgorPartola 6y ago
      Maybe in German. I personally regularly curse the fact that I was born a human when I am confronted with uniquely human problems: having to cook, sweating my behind off, having to waste time using the bathroom, experiencing strong emotions like anger or jealousy or envy. These are the things that make us human, but they often times I find them highly annoying and wish my ancestors had evolved out of some of them.

modeless 6y ago

Cool! Looks like SharedArrayBuffer will be re-enabled next week with the release of Firefox 79: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#JavaScript https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel... This will be big for Web Assembly. Real threads will make it possible to port more stuff and get better performance.

burfog 6y ago
It's better performance for one web site, at the expense of whatever may be in other tabs or even outside the browser. I really don't want to grant that. Web browsers are failing badly at resource controls. I don't want to hand my whole computer over to a greedy web site. I expect my browser to stop the abusive web site resource consumption, not enable it.
- codys 6y ago
  While I agree that browsers generally currently appear to exercise poor control over resources like cpu time and memory amount, I'm not sure that aiming to cripple all sites equally is the right tactic here. It seems like better "scheduling" and other resource management would be something that needs work regardless of whether we expose tools to improve web application performance to websites.

inetknght 6y ago

tl;dr: `about:config` -> `dom.workers.serialized-sab-access` -> true Otherwise you risk sites opting in to Spectre. Why Mozilla thinks this is a good thing is beyond me.

jdlshore 6y ago
This is either astoundingly bad reading comprehension, or a willful mischaracterization. The whole article is about what they're doing to prevent Spectre-like problems. The config option is their backup plan in case they made a mistake in their threat analysis. All in all, I thought it was a sober and mature approach to the problem.

secondcoming 6y ago

The web is such a mess.

justAnotherNET 6y ago
UI is the worst. I can’t tell you the number of web apps that render UI off screen, fail to resize when adjusted, etc

eximius 6y ago

Notably disappointing: Cross-Origin-Opener-Policy must be set on a page to isolate it as the default value is not safe. i.e., if I have a page with sensitive client side data, I need to set this header to prevent a page on a different domain from opening a popup to that page then doing a Spectre-like attack on my web page and exfiltrating that sensitive client side data. I don't actually entirely understand the purpose or effect of Cross-Origin-Embedder-Policy. I thought browsers already blocked cross origin requests without CORS headers in the response that allow it. Does this header UNDO that by default?

dragonwriter 6y ago
> I don't actually entirely understand the purpose or effect of Cross-Origin-Embedder-Policy. I thought browsers already blocked cross origin requests without CORS headers in the response that allow it. CORS applies to XHR/fetch APIs, not browser loading of subresources specified in the HTML of the page. COEP optionally extends CORS-type protection to subresources.