Safely Reviving Shared Memory(hacks.mozilla.org)
hacks.mozilla.org
Safely Reviving Shared Memory
https://hacks.mozilla.org/2020/07/safely-reviving-shared-memory/
86 comments
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)
But I just hate this growing complexity everywhere. HTTP can and should be much simpler than it's becoming.
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)
But I just hate this growing complexity everywhere. HTTP can and should be much simpler than it's becoming.
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!
This new complexity is about javascript execution, and creating a browser that can run javascript has never been simple!
Can I one-up your rant? We're in an era where complexity has gotten so out of hand, our phones catch on fire under the computational burden of sending text messages!
> The work needed to implement an HTTP server is growing and growing and growing.
It's a header. We've all had 25 years to get those implemented :)
It's a header. We've all had 25 years to get those implemented :)
We need something better than the web.
Let’s start by making native apps as instantly accessible as websites — iOS App Clips are a step in that direction.
Next, let people share links into native apps.
Let’s start by making native apps as instantly accessible as websites — iOS App Clips are a step in that direction.
Next, let people share links into native apps.
> I don't think there's any conscious conspiracy anywhere
Nor is it required, see evolution. Completely non-directed, but the beneficiary still benefits which reinforces the change.
It feels like some kind of selection pressure where big companies pollute the world with complexity to remove competition. This can be intentional of course, but even if it's an accidental random mutation then the result is the same.
Nor is it required, see evolution. Completely non-directed, but the beneficiary still benefits which reinforces the change.
It feels like some kind of selection pressure where big companies pollute the world with complexity to remove competition. This can be intentional of course, but even if it's an accidental random mutation then the result is the same.
The following articles also go into more detail:
- https://web.dev/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.
- https://web.dev/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.
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/Rel...
This will be big for Web Assembly. Real threads will make it possible to port more stuff and get better performance.
This will be big for Web Assembly. Real threads will make it possible to port more stuff and get better performance.
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.
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.
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.
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?
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?
> 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.
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.
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.
Very excited to dive back into some WASM/WebWorker projects that got abandoned due to performance limitations.
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.
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.
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.
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.
Is there a name for the sensation of being born the wrong species?
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.
Shakespeare's "thousand natural shocks that flesh is heir to"
Your estimation of the military is way off, I suspect.
Hey, these days the military is using consumer grad iPads, because they are cheaper and good enough.
There are more things in heaven and earth than just the military and SV.
One big example that's often brought up of military tech leading the way is programmable computers. And, yes, in our history that's what happened. But International Business Machines was hot on their heels purely for commercial computing. (If the militaries of the world hadn't blown up so many resources, business would have likely come up with programmable computers a few years earlier, thus completely eliminating the gap.)
Hey, these days the military is using consumer grad iPads, because they are cheaper and good enough.
There are more things in heaven and earth than just the military and SV.
One big example that's often brought up of military tech leading the way is programmable computers. And, yes, in our history that's what happened. But International Business Machines was hot on their heels purely for commercial computing. (If the militaries of the world hadn't blown up so many resources, business would have likely come up with programmable computers a few years earlier, thus completely eliminating the gap.)
I am not saying that any and all tech comes from the military. I am saying that the military is and always has been the driver for innovation more so than any other industry. IBM derives a large share of its profits from tech originally funded by the military for military purposes. The roads we drive on, the cars we drive, the semiconductors we use, the tampons and pads we use, are all pretty direct examples. Lots are indirect. The military also uses duct tape and drives Jeeps. Both were originally invented and built for the military in 1940s. DARPA is still a huge contributor to what we will be taking for granted 20 years from now. There are other researchers of course, I'm not disputing that. This year's National Science Foundation in the US has a budget of $7.1 billion, while military research combined totals $59 billion.
> Silicone Valley mostly provides the last 5%
Typo? Or are we finally acknowledging the contributions of the porn industry? :)
Typo? Or are we finally acknowledging the contributions of the porn industry? :)
I mean... given the contributions of the porn industry to the advancements of the web, an appropriate typo?
Do you think ancient Rome could have landed someone on the moon had they not fell?
Ancient Rome was very military driven. They also had classes of people, which I'd argue is about as selfish as you can get. They could absolutely land on the moon with enough time.
Absolutely not. The ones who did beat the Romans were the ones which then did the moon landing.
The Germans.
The Germans.
Given enough time, yes.
Roma Aeterna!
Yeah but as humans we have an ability to learn and change.
You can lead a horse to water...
In that world, since you don’t have bad actors, you would likely be ruled by a benevolent king or queen.
A large part of why have democracy and separation of powers is to protect from bad actors.
But yeah, not having to deal with bad actors can enable massive achievements. The pyramids were built when Egypt was more or less safe from any external invasion and ruled by god-kings who could coordinate massive building projects.
A large part of why have democracy and separation of powers is to protect from bad actors.
But yeah, not having to deal with bad actors can enable massive achievements. The pyramids were built when Egypt was more or less safe from any external invasion and ruled by god-kings who could coordinate massive building projects.
The problem with an enlightened and benevolent ruler is that even if he really is that good (and history uncovers a lot of dirt even for rulers popularly known as enlightened and benevolent) what do you do when they die or decide to quit ? Their children could be insane psychopats unfit to rule (as indeed often demonstrated in history) or there would be a civil war with various factions trying to fill the power vacuum.
With all its faults democracy has these edge cases handled and makes the elected group of rukers much more acountable with mens to get ridd of they if they turn out to be too unfit to rule.
With all its faults democracy has these edge cases handled and makes the elected group of rukers much more acountable with mens to get ridd of they if they turn out to be too unfit to rule.
Yeah, it has always been in the thoughts of mankind to have a benovolent, righteous king to even the point where the natural world and the animal kingdom would be in harmony. If the events of Isaiah 11 ever come to fruition, I imagine we'll cure cancer, have quantum computers, and unlock the mysteries of the universe.
What do you even need a government (with a benevolent leader at the top) for, if you don't have any bad actors?
You can still gain efficiency by centralising services. If you have centralised services you need some mechanism to coordinate them and make decisions about how they should work, and those decisions should ideally take input from the people using the services. Even in a no-bad-actors world you still have many different competing interests to balance due to different people's needs and preferences, so you probably want some kind of polling/citizens forum/whatever to gather input for making decisions, and an organisation that looks at all the details and makes the decisions on behalf of the collective.
Or by example: You still want someone to organise weekly garbage collection efficiently and equitably. The government does that.
Or by example: You still want someone to organise weekly garbage collection efficiently and equitably. The government does that.
Regular private companies work pretty well for coordinating and providing paid for services. Especially something like garbage collection.
Of course, details depend for example on what our 'no bad actor' assumption actually means, and perhaps on what ideas you have about human nature and history.
> Even in a no-bad-actors world you still have many different competing interests to balance due to different people's needs and preferences, so you probably want some kind of polling/citizens forum/whatever to gather input for making decisions, and an organisation that looks at all the details and makes the decisions on behalf of the collective.
Yes, you'll want some kind of organisation. My comment was just that the organisation would probably not look like a monarchy, benevolent or otherwise.
Of course, details depend for example on what our 'no bad actor' assumption actually means, and perhaps on what ideas you have about human nature and history.
> Even in a no-bad-actors world you still have many different competing interests to balance due to different people's needs and preferences, so you probably want some kind of polling/citizens forum/whatever to gather input for making decisions, and an organisation that looks at all the details and makes the decisions on behalf of the collective.
Yes, you'll want some kind of organisation. My comment was just that the organisation would probably not look like a monarchy, benevolent or otherwise.
Like, if I'm starving and must kill you to survive, am I bad actor (If we split the food, we both die)?
There's no such thing as bad actors. Just people who's interests are not aligned to yours (you are their "bad actor")
There's no such thing as bad actors. Just people who's interests are not aligned to yours (you are their "bad actor")
That's one very specific definition of 'bad actor'. Other definitions are possible, and probably what the original commenter had in mind.
Have a look at eg https://www.lesswrong.com/posts/tJQsxD34maYw2g5E4/thomas-c-s... or https://www.lesswrong.com/posts/2SeN2MjmMzZB25hBo/insights-f... for some ideas about alternative definitions.
You could also go by something like 'You are not a bad actor, if (outside of emergencies) you don't lie, cheat, murder or steal.' Or you can go with something closer to game theory, and emphasis cooperation in something like a prisoner dilemma.
Have a look at eg https://www.lesswrong.com/posts/tJQsxD34maYw2g5E4/thomas-c-s... or https://www.lesswrong.com/posts/2SeN2MjmMzZB25hBo/insights-f... for some ideas about alternative definitions.
You could also go by something like 'You are not a bad actor, if (outside of emergencies) you don't lie, cheat, murder or steal.' Or you can go with something closer to game theory, and emphasis cooperation in something like a prisoner dilemma.
...and no religion too
[cue John Lenon at the piano]
[cue John Lenon at the piano]
Yes, religion tends to make lots of bad actors. That is why Jesus excoriated the religious in Matthew 23.
We'll just conveniently ignore that while prattling on about Adam and Steve. \s
I would love to live in that world. Here’s hoping for human evolution.
So you're saying our genes are going to compete and evolve so that we no longer compete and evolve? That's not how it works.
But a less flippant way to put it is that a world without "bad" actors isn't a stable equilibrium. It cannot and will not ever happen. If you need convincing, look to nature. An equilibrium is only formed through a multitude of mixed strategies.
Artificial selection might result in what you desire, but that would be.. unpopular, to say the least.
But a less flippant way to put it is that a world without "bad" actors isn't a stable equilibrium. It cannot and will not ever happen. If you need convincing, look to nature. An equilibrium is only formed through a multitude of mixed strategies.
Artificial selection might result in what you desire, but that would be.. unpopular, to say the least.
I played with the K on the word HACKS at the top of the screen for far too long.
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.
In Chrome we already require these headers on mobile, and plan to require them on desktop soon.
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.
Just making a note that if you want to foster PWAs over native, or Electron workarounds, better not make us jump through many hoops.
So how will these headers work for shared hosting sites where you normally cannot modify the hosting provider's HTTP server?
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.
Flash games don't need a huge amount of infrastructure.
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.
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.
Here is the 2011 version of WebAssembly for Flash.
https://adobe-flash.github.io/crossbridge/
And here is Unreal Engine 3 using it,
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-WebAs...
https://adobe-flash.github.io/crossbridge/
And here is Unreal Engine 3 using it,
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-WebAs...
You can set headers with .htaccess.
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.
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.
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.
> 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.
> WordPress expects a working .htaccess for its URL structure
I haven't heard this. I'm running WordPress via NGINX with no issues.
I haven't heard this. I'm running WordPress via NGINX with no issues.
If you're only uploading some stuff to wordpress do you need shared array buffers?
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)
[deleted]
"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.
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.
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_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.
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.
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.
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.
It doesn’t need to, since that communication is consensual: the sender must explicitly send the information, and the receiver must explicitly be interested in it (and can check what origin it is from). The problem with SharedArrayBuffer (with Spectre) is that is allows the “receiver” to read whatever it wants from the other origin, just by virtue of ending up in the same browser context.
Site isolation disables all of it. With "Cross-Origin-Embedder-Policy: require-corp," you can't even embed a cross-site image unless the other image allows it with a "Cross-Origin-Resource-Policy: cross-origin"
Enabling that on desktop today would break every website that embeds cross-origin images, e.g. everybody using a separate CDN for images would be broken.
Enabling that on desktop today would break every website that embeds cross-origin images, e.g. everybody using a separate CDN for images would be broken.
You're describing how this proposed cross-origin isolation scheme works. I understand that, I don't understand why it is necessary to make it work that way.
Chrome has been doing site isolation with multiple processes for a for a while, it "just works" and it doesn't break sites.
Chrome has been doing site isolation with multiple processes for a for a while, it "just works" and it doesn't break sites.
Site isolation and origin isolation are separate concerns. In the "origin isolation" model, you need to ensure different origins are in different processes, and that their data don't leak from one to the other. In site isolation, you only care about tabs not being able to communicate with each-other.
Also, you seem to be missing something: Chrome is going to implement the same set of headers, with the same set of restrictions when they are applied. This isn't an arbitrary firefox decision, every web browser is expected to follow suit. See the various mentions of "chrome" in https://web.dev/coop-coep/
Also, you seem to be missing something: Chrome is going to implement the same set of headers, with the same set of restrictions when they are applied. This isn't an arbitrary firefox decision, every web browser is expected to follow suit. See the various mentions of "chrome" in https://web.dev/coop-coep/
> In site isolation, you only care about tabs not being able to communicate with each-other.
That is not true.
https://www.chromium.org/Home/chromium-security/site-isolati...
That is not true.
https://www.chromium.org/Home/chromium-security/site-isolati...
Chrome’s site isolation doesn’t solve the “image from another origin” problem. Those still exist in the containing origin process’s memory. It solves the “frame from another origin” problem, which is the more acute issue but not the only one.
> I don't understand this requirement.
Why? It's a straightforward matter. You can have the conventional behavior with the necessary limitations to which everyone has adapted, or you can opt in to a modified environment with new rules that would break some sites but provides additional capabilities.
> Am I missing something here?
Yes; the clearly explained rational is somehow being missed. The sandbox is an OS process as necessitated by Spectre. Without the new opt-in capability content from multiple origins -- some of them hostile -- are mixed into a process, and so the shared memory capabilities must be disabled. This new opt-in capability creates the necessary mapping; when enabled the content from arbitrary origins will not be mixed in a process and so the shared memory and HRT features can be permitted.
Why? It's a straightforward matter. You can have the conventional behavior with the necessary limitations to which everyone has adapted, or you can opt in to a modified environment with new rules that would break some sites but provides additional capabilities.
> Am I missing something here?
Yes; the clearly explained rational is somehow being missed. The sandbox is an OS process as necessitated by Spectre. Without the new opt-in capability content from multiple origins -- some of them hostile -- are mixed into a process, and so the shared memory capabilities must be disabled. This new opt-in capability creates the necessary mapping; when enabled the content from arbitrary origins will not be mixed in a process and so the shared memory and HRT features can be permitted.
> Without the new opt-in capability content from multiple origins -- some of them hostile -- are mixed into a process, and so the shared memory capabilities must be disabled.
That's an arbitrary requirement on the part of Firefox developers, and it's a security issue in its own right. Any of the numerous exploits that regularly show up in Firefox could take advantage of this, not just Spectre.
Chrome has site-isolation enabled by default, at least on Desktop, I don't see why Firefox shouldn't follow suit.
That's an arbitrary requirement on the part of Firefox developers, and it's a security issue in its own right. Any of the numerous exploits that regularly show up in Firefox could take advantage of this, not just Spectre.
Chrome has site-isolation enabled by default, at least on Desktop, I don't see why Firefox shouldn't follow suit.
This is a concern somewhat orthogonal to site isolation as implemented in Chrome.
Say you have a web page at https://a.com that does <img src="https://b.com/foo.png">. That's allowed in browsers (including Chrome with site isolation enabled), because it's _very_ common on the web and has been for a long time, and disallowing it would break very many sites. But in that situation the browser attempts to prevent a.com from reading the actual pixel data of the image (which comes from b.com). That protection would be violated if the site could just use a Spectre attack to read the pixel data.
So there are three options if you want to keep the security guarantee that you can't read image pixel data cross-site.
1) You could have the pixel data for the image living in a separate process but getting properly composited into the a.com webpage. This is not something any browser does right now, would involve a fair amount of engineering work, and comes with some memory tradeoffs that are not great. It would certainly be a bit of a research project to see how and whether this could be done reasonably.
2) You can attempt to prevent Spectre attacks, e.g. by disallowing things like SharedArrayBuffer. This is the current state in Firefox.
3) You can attempt to ensure that a site's process has access to _either_ SharedArrayBuffer _or_ cross-site image data but never both. This is the solution described in the article. Since current websites widely rely on cross-site images but not much on SharedArrayBuffer, the default is "cross-site images but no SharedArrayBuffer", but sites can opt into the "SharedArrayBuffer but no cross-site images" behavior. There is also an opt-in for the image itself to say "actually, I'm OK with being loaded cross-site even when SharedArrayBuffer is allowed"; in that case a site that opts into the "no cross-site images" behavior will still be able to load that specific image cross-site.
I guess you have a fourth option: Just give up on the security guarantee of "no cross-site pixel data reading". That's what Chrome has been doing on desktop for a while now, by shipping SharedArrayBuffer enabled unconditionally. They are now trying to move away from that to option 3 at the same time as Firefox is moving from option 2 to option 3.
Similar concerns apply to other resources that can currently be loaded cross-site but don't allow cross-site access to the raw bytes of the resource in that situation: video, audio, scripts, stylesheets.
I hope that explains what you are missing in your original comment in terms of the threat model being addressed here, but please do let me know if something is still not making sense!
Say you have a web page at https://a.com that does <img src="https://b.com/foo.png">. That's allowed in browsers (including Chrome with site isolation enabled), because it's _very_ common on the web and has been for a long time, and disallowing it would break very many sites. But in that situation the browser attempts to prevent a.com from reading the actual pixel data of the image (which comes from b.com). That protection would be violated if the site could just use a Spectre attack to read the pixel data.
![https://b.com/foo.png">](https://b.com/foo.png">){kind=link}
So there are three options if you want to keep the security guarantee that you can't read image pixel data cross-site.
1) You could have the pixel data for the image living in a separate process but getting properly composited into the a.com webpage. This is not something any browser does right now, would involve a fair amount of engineering work, and comes with some memory tradeoffs that are not great. It would certainly be a bit of a research project to see how and whether this could be done reasonably.
2) You can attempt to prevent Spectre attacks, e.g. by disallowing things like SharedArrayBuffer. This is the current state in Firefox.
3) You can attempt to ensure that a site's process has access to _either_ SharedArrayBuffer _or_ cross-site image data but never both. This is the solution described in the article. Since current websites widely rely on cross-site images but not much on SharedArrayBuffer, the default is "cross-site images but no SharedArrayBuffer", but sites can opt into the "SharedArrayBuffer but no cross-site images" behavior. There is also an opt-in for the image itself to say "actually, I'm OK with being loaded cross-site even when SharedArrayBuffer is allowed"; in that case a site that opts into the "no cross-site images" behavior will still be able to load that specific image cross-site.
I guess you have a fourth option: Just give up on the security guarantee of "no cross-site pixel data reading". That's what Chrome has been doing on desktop for a while now, by shipping SharedArrayBuffer enabled unconditionally. They are now trying to move away from that to option 3 at the same time as Firefox is moving from option 2 to option 3.
Similar concerns apply to other resources that can currently be loaded cross-site but don't allow cross-site access to the raw bytes of the resource in that situation: video, audio, scripts, stylesheets.
I hope that explains what you are missing in your original comment in terms of the threat model being addressed here, but please do let me know if something is still not making sense!
Keeping image/video/audio data out of process actually sounds kinda reasonable to me :-).
I think the really compelling example is cross-origin script loading. I can't imagine a realistic way to keep the script data out of process but let it be used with low overhead.
I think the really compelling example is cross-origin script loading. I can't imagine a realistic way to keep the script data out of process but let it be used with low overhead.
Oh, I think it's doable; the question is how much the memory overhead for the extra processes is.
I agree that doing this for script (and style) data is much harder from a conceptual point of view! On the other hand, the protections there are already much weaker: once you are running the script, you can find out all sorts of things about it based on its access patterns to various globals and built-in objects (which you control).
I agree that doing this for script (and style) data is much harder from a conceptual point of view! On the other hand, the protections there are already much weaker: once you are running the script, you can find out all sorts of things about it based on its access patterns to various globals and built-in objects (which you control).
Thank you for writing up this detailed breakdown.
I can see how option #4 is a problem from a theoretical standpoint, I still have trouble imagining an actual attack.
I can see how option #4 is a problem from a theoretical standpoint, I still have trouble imagining an actual attack.
If you're asking why the image data might matter, here are concrete examples of non-public images that people might want to get their hands on:
* Earnings projections (and in general slides from non-public presentations that the user but not the attacking website has access to)
* Medical imaging
That's after thinking about this for 15 seconds. I'm sure there are many more in practice.
Or is that not what you were asking?
* Earnings projections (and in general slides from non-public presentations that the user but not the attacking website has access to)
* Medical imaging
That's after thinking about this for 15 seconds. I'm sure there are many more in practice.
Or is that not what you were asking?
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.
> 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.
It doesn't work in general. It kind of works if you're putting each sandbox into its own process. Assuming there aren't any undiscovered microarchitectural attacks at the moment.
It doesn't work in general. It kind of works if you're putting each sandbox into its own process. Assuming there aren't any undiscovered microarchitectural attacks at the moment.
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.
`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.
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.
All in all, I thought it was a sober and mature approach to the problem.
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_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."