4 ms·

Most of these use postMessage.

dgoldstein0 10y ago
probably window.opener.postMessage. Though that doesn't excuse window.opener.location not being blocked in the name of the Same-Origin Policy...
- bzbarsky 10y ago
  "location" is not blocked cross-origin, because that allows you to navigate windows you opened, or subframes of yourself, even if they happen to not be same-origin with you at the moment. And it's been this way for over 20 years, and sites commonly depend on it. :( So what you're suggesting is either some sort of asymmetric "same-origin" checks or .... something.
  - stormbrew 10y ago
    I don't really see the problem with making this asymmetrical. The security implications of a frame navigating its parent and a parent navigating its child frame seem very clearly different to my mind. If you're suggesting it would be technically difficult, I'm extremely skeptical of that. The origin's relationship to the target frame should not be impossible to discern, and I'd be a little shocked if it isn't taken into account elsewhere.
    - bzbarsky 10y ago
      The problem with making it asymmetrical is that in the case of two toplevel tabs (as opposed to frame and child) determining who's the "parent" and who's the "child" is a lot more complicated. > If you're suggesting it would be technically difficult, I'm extremely skeptical of that. I think it's technically difficult to establish parent/child relationships between toplevel windows, given opener disowning and so forth. That's not even getting into the possible compat issues, of course, from the behavior change itself.
      - stormbrew 10y ago
        If that relationship weren't clear you wouldn't have a window.opener attribute to begin with. That said, I'm also skeptical of legitimate uses for controlling the location of another top level window as well, so I'm fine with killing that option too. Of course, I don't expect them to actually fix this, but I'm still waiting for a convincing argument that it should have been that way in the first place.
        bzbarsky 10y ago
        My point was that window.opener can be nulled out. > I'm also skeptical of legitimate uses for controlling the location of another top level window as well Happens all the time: open a popup, then navigate it to places. Not on web pages much nowadays, though it was more common in the past, but in various intranet apps? All the time.
        stormbrew 10y ago
        I'm sure it can. That does not mean the browser needs to forget it. The parent/child relationship of browser windows is not some massive technological feat. That something is used does not mean it is legitimate. I am not disputing that it is used. I am not saying I think they'll fix it. I am questioning the validity of the decision to allow it in the first place. I have no doubt that other means would be found to achieve the same end goals if it were not available.
        bzbarsky 10y ago
        > That something is used does not mean it is legitimate. While I agree, in practice what this means is that either all browsers need to coordinate rollout precisely (and even then the result will be that many users just stay on insecure versions of browsers instead of updating) or you will have pages (or employers) telling users to switch to whatever browser lags in rolling this out. We've seen this play out before. The result is that you end up with users picking whichever browser defects (which reduces the incentive for other browsers to do this) or being stuck on the equivalent of IE6. The benefit of changes that do NOT break compat is that browsers can just roll them out without needing to worry about the above side-effects.

probably window.opener.postMessage. Though that doesn't excuse window.opener.location not being blocked in the name of the Same-Origin Policy...

bzbarsky 10y ago
"location" is not blocked cross-origin, because that allows you to navigate windows you opened, or subframes of yourself, even if they happen to not be same-origin with you at the moment. And it's been this way for over 20 years, and sites commonly depend on it. :( So what you're suggesting is either some sort of asymmetric "same-origin" checks or .... something.
- stormbrew 10y ago
  I don't really see the problem with making this asymmetrical. The security implications of a frame navigating its parent and a parent navigating its child frame seem very clearly different to my mind. If you're suggesting it would be technically difficult, I'm extremely skeptical of that. The origin's relationship to the target frame should not be impossible to discern, and I'd be a little shocked if it isn't taken into account elsewhere.
  - bzbarsky 10y ago
    The problem with making it asymmetrical is that in the case of two toplevel tabs (as opposed to frame and child) determining who's the "parent" and who's the "child" is a lot more complicated. > If you're suggesting it would be technically difficult, I'm extremely skeptical of that. I think it's technically difficult to establish parent/child relationships between toplevel windows, given opener disowning and so forth. That's not even getting into the possible compat issues, of course, from the behavior change itself.
    - stormbrew 10y ago
      If that relationship weren't clear you wouldn't have a window.opener attribute to begin with. That said, I'm also skeptical of legitimate uses for controlling the location of another top level window as well, so I'm fine with killing that option too. Of course, I don't expect them to actually fix this, but I'm still waiting for a convincing argument that it should have been that way in the first place.
      - bzbarsky 10y ago
        My point was that window.opener can be nulled out. > I'm also skeptical of legitimate uses for controlling the location of another top level window as well Happens all the time: open a popup, then navigate it to places. Not on web pages much nowadays, though it was more common in the past, but in various intranet apps? All the time.
        stormbrew 10y ago
        I'm sure it can. That does not mean the browser needs to forget it. The parent/child relationship of browser windows is not some massive technological feat. That something is used does not mean it is legitimate. I am not disputing that it is used. I am not saying I think they'll fix it. I am questioning the validity of the decision to allow it in the first place. I have no doubt that other means would be found to achieve the same end goals if it were not available.
        bzbarsky 10y ago
        > That something is used does not mean it is legitimate. While I agree, in practice what this means is that either all browsers need to coordinate rollout precisely (and even then the result will be that many users just stay on insecure versions of browsers instead of updating) or you will have pages (or employers) telling users to switch to whatever browser lags in rolling this out. We've seen this play out before. The result is that you end up with users picking whichever browser defects (which reduces the incentive for other browsers to do this) or being stuck on the equivalent of IE6. The benefit of changes that do NOT break compat is that browsers can just roll them out without needing to worry about the above side-effects.