7 ms·

That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By se

by lxgr 2y ago

That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...

wging 2y ago
So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.
- connicpu 2y ago
  It's not unreasonable to set a different header value for the login page only, where it should be safe because no external user data is being rendered.
- lxgr 2y ago
  Sites can also opt into the same behavior by setting the rel="noopener" or alternatively target="_blank" attributes on outgoing links (i.e. <a> tags). And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
  - wging 2y ago
    That is a little different, though: those attributes are for if you're example.com linking to protonmail, the header is for if you're protonmail deciding on security policies for interactions with example.com.
    - lxgr 2y ago
      The header works in both directions; cf. the table on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr....
omcnoe 2y ago
Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a penalty can opt their sites into the "same process" flag if really needed.
- lxgr 2y ago
  Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).
  - dfedbeef 2y ago
    It's super feasible if you own the API default.
    - lxgr 2y ago
      It's definitely a quick way to get all your users to switch to a different browser or figure out how to disable updates forever.
      - throwaway894345 2y ago
        I mean, if all major browsers do it roughly once then users will complain to the few broken websites. They won’t even think to blame the browser if every other site works fine and the broken site is broken on all browsers.
        lxgr 2y ago
        Good luck trying to get Google or Microsoft to throw their paying enterprise users under the bus in the interest of slightly safer sandboxing defaults.
deleted 2y ago
[deleted]
fweimer 2y ago
Would it help to use separate processes and share the data on demand only, via IPC with a robust speculation barrier?
- lxgr 2y ago
  Yes, and that’s what Firefox and Chrome are already doing.
eptcyka 2y ago
Other browsers do site isolation, why can’t Safari? (:
- zamalek 2y ago
  Right, in what sane world would the website determine operating system process semantics? What next, syscalls?
- astrange 2y ago
  Have you noticed how often people complain Chrome uses too much memory?
  - lxgr 2y ago
    Process-per-site isolation doesn't necessarily have to use (much) more memory. If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory. Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.
    - astrange 2y ago
      You can't fork a GUI process on Apple OSes, most of the system can't handle it. It'd also weaken any security protection based on randomness (eg ASLR slide, pointer encryption keys).
      - lxgr 2y ago
        Huh, TIL Chrome on macOS might actually not be using the “zygote process” paradigm! https://source.chromium.org/chromium/chromium/src/+/main:content/public/common/zygote/features.gni https://source.chromium.org/chromium/chromium/src/+/main:con...
    - bdd8f1df777b 2y ago
      Not possible on Windows, where most Chrome users are on.
davrosthedalek 2y ago
Would that performance hit be really that significant? I can't imagine there are more than a couple of calls total, and that's all dwarfed by any web access. Or do I misunderstand what's required?
dadrian 2y ago
It is not required by window.open semantics, you can absolutely implement site isolation even in the presence of COOP unsafe-none
- lxgr 2y ago
  Sorry, I was imprecise in my original post: It's definitely possible to isolate even sites in the same browsing context group, but it requires more work that Safari apparently just hasn't got around to yet.
lxgr 2y ago
Can't edit my original post anymore: Firefox and Chrome do seem to isolate even same-browsing-context-group and bridge the required APIs via IPC, so hopefully Safari will catch up at some point. Basically, there are three scenarios: - Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via '<a target="_blank' ...>" or 'rel="noopener"' references etc.) – these are relatively easily isolated if the browser supports it at all. All major (desktop!) browsers now largely do this, including Safari. - "Same browsing context group" (but different origin) sites. These can communicate via various APIs, and historically that was achieved by just letting them run in the same rendering process. But in the face of attacks such as this one, this can be insecure. Firefox and Chrome provide sandboxing via separate processes; Safari does not. - Same origin sites (without any stricter policy). These can fully access each other's DOM (if they have an opener/opened relationship), so there's not really any point in having them live in different renderers except possibly for fault isolation (e.g. one of them crashing not taking the other down). As far as I know, all browsers render these in the same process. Sites can opt out of the second and third category into the first via various HTTP headers and HTML link attributes. If we were to design the web from scratch, arguably the default for window.open should be the first behavior, with an opt in to the second, but that's backwards compatibility for you.
- MikeHolman 2y ago
  I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendors largely agreed that the only strong defense was complete process isolation. I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense.
  - leeter 2y ago
    To add to this and to quote a friend who has more NDAs in regards to microarchitecture than I can count and thus shall remain nameless: "You can have a fast CPU or a secure CPU: Pick one". Pretty much everything a modern CPU does has side effects that are something that any sufficiently motivated attacker can find a way to use (most likely). While many are core specific (register rename, execution port usage for example), many are not (speculative execution, speculative loads). Side channels are a persnickety thing, and nearly impossible to fully account for. Can you make a "Secure" CPU? In theory yes, but it won't be fast or as power efficient as it could in theory be. Because the things that allow those things are all possible side channels. This is why in theory the TPM in your machine is for those sorts of things (allegedly, they have their own side channels). The harder question is "what is enough?" e.g. at what level does it not matter that much anymore? The answer based on the post above this is based on quite a lot of risk analysis and design considerations. These design decisions were the best balance of security and speed given the available information at the time. Sure, can you build that theoretically perfect secure CPU? Yes. But, if you can't do anything that actually needs security on it because it's so slow; do you care?
fortran77 2y ago
So zealous to defend Apple that you didn’t check Firefox and Chrome before posting?

by lxgr 2y ago

wging 2y ago

So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.

connicpu 2y ago
It's not unreasonable to set a different header value for the login page only, where it should be safe because no external user data is being rendered.
lxgr 2y ago
Sites can also opt into the same behavior by setting the rel="noopener" or alternatively target="_blank" attributes on outgoing links (i.e. <a> tags). And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
- wging 2y ago
  That is a little different, though: those attributes are for if you're example.com linking to protonmail, the header is for if you're protonmail deciding on security policies for interactions with example.com.
  - lxgr 2y ago
    The header works in both directions; cf. the table on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr....

omcnoe 2y ago

Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a penalty can opt their sites into the "same process" flag if really needed.

lxgr 2y ago
Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).
- dfedbeef 2y ago
  It's super feasible if you own the API default.
  - lxgr 2y ago
    It's definitely a quick way to get all your users to switch to a different browser or figure out how to disable updates forever.
    - throwaway894345 2y ago
      I mean, if all major browsers do it roughly once then users will complain to the few broken websites. They won’t even think to blame the browser if every other site works fine and the broken site is broken on all browsers.
      - lxgr 2y ago
        Good luck trying to get Google or Microsoft to throw their paying enterprise users under the bus in the interest of slightly safer sandboxing defaults.

deleted 2y ago

[deleted]

fweimer 2y ago

Would it help to use separate processes and share the data on demand only, via IPC with a robust speculation barrier?

lxgr 2y ago
Yes, and that’s what Firefox and Chrome are already doing.

eptcyka 2y ago

Other browsers do site isolation, why can’t Safari? (:

zamalek 2y ago
Right, in what sane world would the website determine operating system process semantics? What next, syscalls?
astrange 2y ago
Have you noticed how often people complain Chrome uses too much memory?
- lxgr 2y ago
  Process-per-site isolation doesn't necessarily have to use (much) more memory. If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory. Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.
  - astrange 2y ago
    You can't fork a GUI process on Apple OSes, most of the system can't handle it. It'd also weaken any security protection based on randomness (eg ASLR slide, pointer encryption keys).
    - lxgr 2y ago
      Huh, TIL Chrome on macOS might actually not be using the “zygote process” paradigm! https://source.chromium.org/chromium/chromium/src/+/main:content/public/common/zygote/features.gni https://source.chromium.org/chromium/chromium/src/+/main:con...
  - bdd8f1df777b 2y ago
    Not possible on Windows, where most Chrome users are on.

davrosthedalek 2y ago

Would that performance hit be really that significant? I can't imagine there are more than a couple of calls total, and that's all dwarfed by any web access. Or do I misunderstand what's required?

dadrian 2y ago

It is not required by window.open semantics, you can absolutely implement site isolation even in the presence of COOP unsafe-none

lxgr 2y ago
Sorry, I was imprecise in my original post: It's definitely possible to isolate even sites in the same browsing context group, but it requires more work that Safari apparently just hasn't got around to yet.

lxgr 2y ago

Can't edit my original post anymore: Firefox and Chrome do seem to isolate even same-browsing-context-group and bridge the required APIs via IPC, so hopefully Safari will catch up at some point. Basically, there are three scenarios: - Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via '<a target="_blank' ...>" or 'rel="noopener"' references etc.) – these are relatively easily isolated if the browser supports it at all. All major (desktop!) browsers now largely do this, including Safari. - "Same browsing context group" (but different origin) sites. These can communicate via various APIs, and historically that was achieved by just letting them run in the same rendering process. But in the face of attacks such as this one, this can be insecure. Firefox and Chrome provide sandboxing via separate processes; Safari does not. - Same origin sites (without any stricter policy). These can fully access each other's DOM (if they have an opener/opened relationship), so there's not really any point in having them live in different renderers except possibly for fault isolation (e.g. one of them crashing not taking the other down). As far as I know, all browsers render these in the same process. Sites can opt out of the second and third category into the first via various HTTP headers and HTML link attributes. If we were to design the web from scratch, arguably the default for window.open should be the first behavior, with an opt in to the second, but that's backwards compatibility for you.

MikeHolman 2y ago
I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendors largely agreed that the only strong defense was complete process isolation. I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense.
- leeter 2y ago
  To add to this and to quote a friend who has more NDAs in regards to microarchitecture than I can count and thus shall remain nameless: "You can have a fast CPU or a secure CPU: Pick one". Pretty much everything a modern CPU does has side effects that are something that any sufficiently motivated attacker can find a way to use (most likely). While many are core specific (register rename, execution port usage for example), many are not (speculative execution, speculative loads). Side channels are a persnickety thing, and nearly impossible to fully account for. Can you make a "Secure" CPU? In theory yes, but it won't be fast or as power efficient as it could in theory be. Because the things that allow those things are all possible side channels. This is why in theory the TPM in your machine is for those sorts of things (allegedly, they have their own side channels). The harder question is "what is enough?" e.g. at what level does it not matter that much anymore? The answer based on the post above this is based on quite a lot of risk analysis and design considerations. These design decisions were the best balance of security and speed given the available information at the time. Sure, can you build that theoretically perfect secure CPU? Yes. But, if you can't do anything that actually needs security on it because it's so slow; do you care?

fortran77 2y ago

So zealous to defend Apple that you didn’t check Firefox and Chrome before posting?