Consider making X-Frame-Options: deny to create a new browsing context group

[rniwa]

While exploring the latest proposal in #3740, we came to realization that much of the security benefits & needs of the header coincides with that of X-Frame-Options: deny with regards to severing opener and creating a new namespace for frames, etc..

Namely, websites that opts to set X-Frame-Options: deny often don't want other websites to be able to click jack, be able to navigate frames within the website, etc... We think almost all websites that currently opts to use X-Frame-Options: deny also want to sever opener relationship as well if they could.

Therefore we propose to make X-Frame-Options: deny sever the opener relationship by creating a new browsing context group as well, and we intend to experiment this behavior in WebKit.

[cdumez]

X-Frame-Options: deny & X-Frame-Options: sameorigin (when navigating cross-origin).

[annevk]

I'd be worried about OAuth providers setting this and no longer functioning afterwards, but it's worth experimenting with. What is the exact behavior you are going for? Some scenarios:

1. A either with or without this header set navigates to B with X-Frame-Options: deny or X-Frame-Options: sameorigin set (sounds like this creates a new browsing context group)
2. A without header set navigates to A' with either header set
3. A with X-Frame-Options: deny navigates to A' with X-Frame-Options: sameorigin, and vice versa

[annevk]

(This depends on #1230.)

[cdumez]

Both Google and Facebook OAuth popups seem to serve "X-Frame-Options: deny" (tested on Yelp.com) and yet rely on having an opener. I do not think this would be Web-compatible.

[rniwa]

Given this observation, we would recede this proposal.