
Safely Reviving Shared Memory - MindGods
https://hacks.mozilla.org/2020/07/safely-reviving-shared-memory/
======
dfabulich
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_9e8Jdc8ehuV4zME...](https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit)

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

~~~
ekr
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
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!

------
modeless
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...](https://developer.mozilla.org/en-
US/docs/Mozilla/Firefox/Releases/79#JavaScript)

This will be big for Web Assembly. Real threads will make it possible to port
more stuff and get better performance.

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

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

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

~~~
waynecochran
Do you think ancient Rome could have landed someone on the moon had they not
fell?

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

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

------
pjmlp
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
In Chrome we already require these headers on mobile, and plan to require them
on desktop soon.

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

------
secondcoming
The web is such a mess.

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

~~~
simlevesque
You can set headers with .htaccess.

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

~~~
duskwuff
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
> WordPress expects a working .htaccess for its URL structure

I haven't heard this. I'm running WordPress via NGINX with no issues.

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

------
gridlockd
_" 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.

~~~
dfabulich
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...](https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit)

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

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

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

~~~
roblabla
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/](https://web.dev/coop-coep/)

~~~
gridlockd
> 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...](https://www.chromium.org/Home/chromium-security/site-isolation)

