8 ms·

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

by 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.
        throwaway894345 2y ago
        I wasn’t suggesting it would happen, only that the “users would stop updating their browsers” scenario seemed unlikely.
    - connicpu 2y ago
      One spot where safari is in an advantageous position to force a new default, as long as they roll it out on iOS first.
  - dfedbeef 2y ago
    You just announce you are making a change and then turn it on later.
    - schrodinger 2y ago
      After building enterprise APIs for a few years, you’d be amazed at how hard it is to get companies to make even minor changes; backwards compatibility is key. Often it’s because they _can’t_ make the change themselves since they outsourced the code to a consulting agency. So they’d have to sign a new contract and get an agency to make the change. They just won’t, and you’ll have a browser that people stop using.
      - bee_rider 2y ago
        It is probably outside the scope of what one company can do (although Apple is quite large…). But we need to fix our understanding of backwards compatibility. If a computer system provides the ability to keep doing something, but the way it provides that capability requires it to be insecure, then the system should not really be thought of as “backward compatible.” Because reasonably prudent people can’t actually keep doing the thing they were doing before. Of source, modern computers on the modern web don’t really provide the ability to do much at all in a reasonably prudent fashion, so it is all a bit moot I guess.
    - lxgr 2y ago
      Announce what to whom? To the hundreds of millions of users out there that don't even know what a browser is, let alone why it's now talking to them about something called a "site isolation framework"?
      - plufz 2y ago
        I would guess you would use a deprecation message in the console? Like they have done over cookie changes, etc. A normal user would obviously not check the console, but the devs or admins of the site sure might.
        2y ago
- zamalek 2y ago
  We had the tech in the 80's for the browser to facilitate popup authentication with process isolation. It's this niche and esoteric tech called IPC[1], so niche that one really can't blame Apple for not hearing about it. It truly boggles the mind as to how all the other browsers pull it off. [1]: https://en.wikipedia.org/wiki/Inter-process_communication https://en.wikipedia.org/wiki/Inter-process_communication
  - lxgr 2y ago
    To be fair, there wasn't that much sensitive web content around in the 80s to leak (primarily due to the web not yet existing, nor browsers), so it's only fair that browsers didn't consider using IPC for site isolation back then.
    - zamalek 2y ago
      The point of my rather facetious comment is that IPC a well known thing (I struggle to even call it "tech") that has been around for 30-40 years. I don't understand why Apple needs people to make excuses for them, but this excuse would render Apple vastly more incompetent than neglecting to separate browser tabs in 2025.
      - lxgr 2y ago
        Browsers are incredibly complex, and moving them to an IPC model is not easy. Essentially, you need to ensure "same process like", performant JavaScript interoperability in some cases, often (but not always) due to backwards compatibility. Firefox has shared a lot about their efforts in moving there. If you're curious, there are a lot of blog posts and internal design docs under their project name "Project Fission". But yeah, the fact that both Chrome and Firefox have managed to do so does leave Apple looking slightly bad here.
        junon 2y ago
        We already have this with (iirc) postMessage API.
- asoneth 2y ago
  Why not a choice? Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.
  - jahewson 2y ago
    That’s not a real choice though. All it takes is one website that is essential to me not supporting the secure mode and I’m forced to opt-out. The upstream website is making the choice for me.
  - kergonath 2y ago
    > Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites. And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.
    - amatecha 2y ago
      idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browser that can load almost nothing", and basically nothing in between. I had to stop using Firefox on my old ThinkPad because after opening a few windows, it churns the CPU so hard it's not usable for a solid minute+. Let that finish up, and I have to wait again if I dare to open another page. i5-3220m, 8gb of RAM (where the OS uses like 200mb of RAM)... there's no excuse for this to not be able to browse the web. Some fun examples of "your browser is an OS on top of your OS": The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake... The Web Serial API provides a way for websites to read from and write to serial devices. https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_... The Window Management API allows you to get detailed information on the displays connected to your device and more easily place windows on specific screens, paving the way towards more effective multi-screen applications. https://developer.mozilla.org/en-US/docs/Web/API/Window_Management_API https://developer.mozilla.org/en-US/docs/Web/API/Window_Mana... The Compute Pressure API is a JavaScript API that enables you to observe the pressure of system resources such as the CPU. https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pressure_API https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pre... (my thesis is, not all web developers want this stuff, and usually when I talk to people in the industry they agree, it's excessive)
- BobbyTables2 2y ago
  Expecting websites to defend themselves against CPU side channel attacks is also absurd!
- omcnoe 2y ago
  But how much data are those popup based auth sending through? At the absolute most a few MB in a couple calls. Even if it's dramatically slower over IPC it's not going to cause issues.
- raxxorraxor 2y ago
  Similar problem with third-party-cookies. They would make some auth cases easier and safer, but we shouldn't generally allow them because they are abused for tracking. Here I would agree with you though.

by omcnoe 2y ago

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.
      - throwaway894345 2y ago
        I wasn’t suggesting it would happen, only that the “users would stop updating their browsers” scenario seemed unlikely.
  - connicpu 2y ago
    One spot where safari is in an advantageous position to force a new default, as long as they roll it out on iOS first.
- dfedbeef 2y ago
  You just announce you are making a change and then turn it on later.
  - schrodinger 2y ago
    After building enterprise APIs for a few years, you’d be amazed at how hard it is to get companies to make even minor changes; backwards compatibility is key. Often it’s because they _can’t_ make the change themselves since they outsourced the code to a consulting agency. So they’d have to sign a new contract and get an agency to make the change. They just won’t, and you’ll have a browser that people stop using.
    - bee_rider 2y ago
      It is probably outside the scope of what one company can do (although Apple is quite large…). But we need to fix our understanding of backwards compatibility. If a computer system provides the ability to keep doing something, but the way it provides that capability requires it to be insecure, then the system should not really be thought of as “backward compatible.” Because reasonably prudent people can’t actually keep doing the thing they were doing before. Of source, modern computers on the modern web don’t really provide the ability to do much at all in a reasonably prudent fashion, so it is all a bit moot I guess.
  - lxgr 2y ago
    Announce what to whom? To the hundreds of millions of users out there that don't even know what a browser is, let alone why it's now talking to them about something called a "site isolation framework"?
    - plufz 2y ago
      I would guess you would use a deprecation message in the console? Like they have done over cookie changes, etc. A normal user would obviously not check the console, but the devs or admins of the site sure might.
      - 2y ago
zamalek 2y ago
We had the tech in the 80's for the browser to facilitate popup authentication with process isolation. It's this niche and esoteric tech called IPC[1], so niche that one really can't blame Apple for not hearing about it. It truly boggles the mind as to how all the other browsers pull it off. [1]: https://en.wikipedia.org/wiki/Inter-process_communication https://en.wikipedia.org/wiki/Inter-process_communication
- lxgr 2y ago
  To be fair, there wasn't that much sensitive web content around in the 80s to leak (primarily due to the web not yet existing, nor browsers), so it's only fair that browsers didn't consider using IPC for site isolation back then.
  - zamalek 2y ago
    The point of my rather facetious comment is that IPC a well known thing (I struggle to even call it "tech") that has been around for 30-40 years. I don't understand why Apple needs people to make excuses for them, but this excuse would render Apple vastly more incompetent than neglecting to separate browser tabs in 2025.
    - lxgr 2y ago
      Browsers are incredibly complex, and moving them to an IPC model is not easy. Essentially, you need to ensure "same process like", performant JavaScript interoperability in some cases, often (but not always) due to backwards compatibility. Firefox has shared a lot about their efforts in moving there. If you're curious, there are a lot of blog posts and internal design docs under their project name "Project Fission". But yeah, the fact that both Chrome and Firefox have managed to do so does leave Apple looking slightly bad here.
      - junon 2y ago
        We already have this with (iirc) postMessage API.
asoneth 2y ago
Why not a choice? Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.
- jahewson 2y ago
  That’s not a real choice though. All it takes is one website that is essential to me not supporting the secure mode and I’m forced to opt-out. The upstream website is making the choice for me.
- kergonath 2y ago
  > Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites. And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.
  - amatecha 2y ago
    idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browser that can load almost nothing", and basically nothing in between. I had to stop using Firefox on my old ThinkPad because after opening a few windows, it churns the CPU so hard it's not usable for a solid minute+. Let that finish up, and I have to wait again if I dare to open another page. i5-3220m, 8gb of RAM (where the OS uses like 200mb of RAM)... there's no excuse for this to not be able to browse the web. Some fun examples of "your browser is an OS on top of your OS": The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake... The Web Serial API provides a way for websites to read from and write to serial devices. https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_... The Window Management API allows you to get detailed information on the displays connected to your device and more easily place windows on specific screens, paving the way towards more effective multi-screen applications. https://developer.mozilla.org/en-US/docs/Web/API/Window_Management_API https://developer.mozilla.org/en-US/docs/Web/API/Window_Mana... The Compute Pressure API is a JavaScript API that enables you to observe the pressure of system resources such as the CPU. https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pressure_API https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pre... (my thesis is, not all web developers want this stuff, and usually when I talk to people in the industry they agree, it's excessive)
BobbyTables2 2y ago
Expecting websites to defend themselves against CPU side channel attacks is also absurd!
omcnoe 2y ago
But how much data are those popup based auth sending through? At the absolute most a few MB in a couple calls. Even if it's dramatically slower over IPC it's not going to cause issues.
raxxorraxor 2y ago
Similar problem with third-party-cookies. They would make some auth cases easier and safer, but we shouldn't generally allow them because they are abused for tracking. Here I would agree with you though.