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

Reply via email to