I see what you're saying Michael and also agree it's serious. Would I be correct in thinking that MS Edge solves the problem by not returning window.opener cross-domain? Is the UA not a logical and uniform place for this?
BTW I've also experienced the CitHub topic-closure nazis many times :-( On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters <mpet...@domblogger.net> wrote: > Well if it was done as a header, I suppose it could be added as a > http-equiv meta tag for those who want to. > > Header is the easiest solution to make sure it is applied everywhere > without question. It could even be added at the front-end proxy to cover > numerous web applications on many domains at once. > > And I know this is conspiracy theory, but that's why I think there is such > resistance to it. > > Since the flaw is required for OAuth to work, companies invested in OAuth > and that profit from OAuth solutions don't want sites behind proxies that > would break OAuth and don't want webmasters to understand they have to > reduce security in order to implement an OAuth solution. > > That's just a suspicion of mine, but I can't think of any other logical > reason as to why a node attribute was chosen as the solution, and why there > is such resistance to doing it the right way with a header. To me it just > doesn't make sense. > > > On 12/01/2016 05:45 PM, Zac Spitzer wrote: > >> how about rather than requiring this on every <a> why not support a base >> tag directive >> for the whole document i.e. <base rel="noopener">, similar to <base >> target="_blank">? >> >> On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola <d...@domenic.me> wrote: >> >> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian >>> Hickson >>> >>> I believe that's a bit of an overstatement. There are certainly risks >>>> >>> involved in window.opener (they're briefly discussed in the spec itself), >>> but it doesn't remove the origin checks. >>> >>> This is the crucial point. >>> >>> Whenever you are discussing a supposed security issue, you need to make >>> clear what the threat model is. That is: >>> >>> - What would be the impact on the victim if the security hole is taken >>> advantage of? >>> - Is this something we are trying to prevent on the web platform? >>> >>> In this case, the impact on the victim (a user of a web browser) is that >>> they could click a link from page A to page B, which opens in a new tab >>> (tab B). Then, tab A could be navigated to a new URL, instead of staying >>> on >>> page A. >>> >>> This is not a big impact. Notably, page B is not able to read any of the >>> content of page A, which might be sensitive. Page B is not able to >>> interfere with the operation of any of page B's scripts. And crucially, >>> when page B navigates tab A to another page, the URL bar of tab A changes >>> to indicate that. >>> >>> There is no desired security guarantee on the platform that we want to >>> prevent pages from directing users to "bad" sites. We count on users >>> inspecting the URL bar to understand what page they are interacting with >>> in >>> a given tab. >>> >>> So, while it might be a bit surprising that suddenly tab A is navigating >>> somewhere else, there is no security issue here, and users are not >>> endangered in any way---at least, not in any more danger than they >>> already >>> are from browsing the web without looking at their URL bar to see where >>> they've ended up at. >>> >>> >> >> >> >