Commit empty document instead of canceling the load for blocked CSP/XFO responses.

Commit empty document instead of canceling the load for blocked CSP/XFO responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
TEST=http/tests/security/contentSecurityPolicy/1.1/frame-ancestors/* and http/tests/security/XFrameOptions/* still pass

Committed: https://crrev.com/77f6ed50529fb670db4cb3989bae5d93515a33a5
Cr-Commit-Position: refs/heads/master@{#378762}

[alexmos, 2016-03-01 06:10:00]

Description was changed from

==========
Better follow the spec for blocked CSP/XFO responses.

BUG=584845
==========

to

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
==========

[alexmos, 2016-03-01 06:10:27]

Description was changed from

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
==========

to

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
==========

[alexmos, 2016-03-01 06:20:05]

Description was changed from

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
==========

to

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
TEST=http/tests/security/contentSecurityPolicy/1.1/frame-ancestors/* and
http/tests/security/XFrameOptions/* still pass
==========

[alexmos, 2016-03-01 07:31:47]

alexmos@chromium.org changed reviewers:
+ mkwst@chromium.org

[alexmos, 2016-03-01 07:31:47]

Mike, what do you think about this change and my reasoning in the description?

Basically, when a load is blocked by CSO/XFO, we currently cancel it, but that
is problematic for OOPIFs.  I tried to fix it first by propagating the
cancellation across processes, resulting in a pretty ugly CL
(https://codereview.chromium.org/1710283003/), where in the discussion, we
realized that the current behavior of leaving the old page around is actually
pretty bad and doesn't follow the spec.  Here, I've tried to change things to
follow the spec and pretend that there was an empty 200 response for blocked
loads, which doesn't seem as hard, and it solves a bunch of OOPIF-related
problems for free.  Is there any reason not to do this?  Trybots all seem happy
with this - just slight rebaselining of three XFO tests, where the order of a
couple of output lines changed.  Let me know is this is a good way to do this;
I'm not that familiar with loading code.

[Mike West, 2016-03-01 19:42:25]

This LGTM, though I wonder if it means we ought to change the behavior of the
meta version of XFO:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit....
Do go ahead and land it.

That said, I have a halfway completed implementation of XFO in the browser
process (https://codereview.chromium.org/1617043002) which uses a throttle to
cancel requests which would fail the XFO check. Do you have thoughts about how
we'd implement something similar to this patch's behavior in the browser
process?

[Nate Chapin, 2016-03-01 20:26:10]

japhet@chromium.org changed reviewers:
+ japhet@chromium.org

[Nate Chapin, 2016-03-01 20:26:11]

https://codereview.chromium.org/1742923002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/DocumentInit.cpp (right):

https://codereview.chromium.org/1742923002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/DocumentInit.cpp:114: DocumentLoader*
documentLoader = loader->provisionalDocumentLoader() ?
loader->provisionalDocumentLoader() : loader->documentLoader();
Is it really possible for this to be either document loader? I would have
thought it's always one or the other.

[alexmos, 2016-03-02 01:30:56]

Thanks!  Nate - I fixed the loader check and left a question there for Mike.

On 2016/03/01 19:42:25, Mike West wrote:
> This LGTM, though I wonder if it means we ought to change the behavior of the
> meta version of XFO:
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit....
> Do go ahead and land it.

Oh, thanks for pointing that out, I wasn't aware that this even existed.  That
path doesn't look as problematic, since it has already committed and replaced
the old page with a new Document, and the extra navigation to
urlWithUniqueSecurityOrigin actually seems to arrive at an equivalent state
compared to what I'm doing here.
 
> That said, I have a halfway completed implementation of XFO in the browser
> process (https://codereview.chromium.org/1617043002) which uses a throttle to
> cancel requests which would fail the XFO check. Do you have thoughts about how
> we'd implement something similar to this patch's behavior in the browser
> process?

I'm not that familiar with throttles, unfortunately.  Maybe instead of
canceling, you might be able to pretend it's a redirect to something like
urlWithUniqueSecurityOrigin?

https://codereview.chromium.org/1742923002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/DocumentInit.cpp (right):

https://codereview.chromium.org/1742923002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/DocumentInit.cpp:114: DocumentLoader*
documentLoader = loader->provisionalDocumentLoader() ?
loader->provisionalDocumentLoader() : loader->documentLoader();
On 2016/03/01 20:26:11, Nate Chapin wrote:
> Is it really possible for this to be either document loader? I would have
> thought it's always one or the other.

Good point.  Looking closer I think this should just use documentLoader(). 
(This is called after FrameLoader::prepareForCommit, which releases the
provisional one.)  I've changed it and things still work.

That said, I based this off of DocumentInit::isHostedInReservedIPRange(), which
has this check and is also used solely in Document::initSecurityContext.  Mike,
you added it in https://codereview.chromium.org/845303003 - was there a reason
for checking both loaders?

[Mike West, 2016-03-02 13:57:11]

On 2016/03/02 at 01:30:56, alexmos wrote:
> Thanks!  Nate - I fixed the loader check and left a question there for Mike.
> 
> On 2016/03/01 19:42:25, Mike West wrote:
> > This LGTM, though I wonder if it means we ought to change the behavior of
the
> > meta version of XFO:
> >
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit....
> > Do go ahead and land it.
> 
> Oh, thanks for pointing that out, I wasn't aware that this even existed.  That
path doesn't look as problematic, since it has already committed and replaced
the old page with a new Document, and the extra navigation to
urlWithUniqueSecurityOrigin actually seems to arrive at an equivalent state
compared to what I'm doing here.

Great! I'm not entirely sure we should keep that behavior honestly, as no one
else has implemented it. But, a question for another time.

> > That said, I have a halfway completed implementation of XFO in the browser
> > process (https://codereview.chromium.org/1617043002) which uses a throttle
to
> > cancel requests which would fail the XFO check. Do you have thoughts about
how
> > we'd implement something similar to this patch's behavior in the browser
> > process?
> 
> I'm not that familiar with throttles, unfortunately.  Maybe instead of
canceling, you might be able to pretend it's a redirect to something like
urlWithUniqueSecurityOrigin?

Hrm. I'll make clamy@ explain to me how that might work. :)

>
https://codereview.chromium.org/1742923002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/dom/DocumentInit.cpp:114: DocumentLoader*
documentLoader = loader->provisionalDocumentLoader() ?
loader->provisionalDocumentLoader() : loader->documentLoader();
> On 2016/03/01 20:26:11, Nate Chapin wrote:
> > Is it really possible for this to be either document loader? I would have
> > thought it's always one or the other.
> 
> Good point.  Looking closer I think this should just use documentLoader(). 
(This is called after FrameLoader::prepareForCommit, which releases the
provisional one.)  I've changed it and things still work.
> 
> That said, I based this off of DocumentInit::isHostedInReservedIPRange(),
which has this check and is also used solely in Document::initSecurityContext. 
Mike, you added it in https://codereview.chromium.org/845303003 - was there a
reason for checking both loaders?

I'm sure there was, but it doesn't make much sense to me today. I think Nate's
right.

[alexmos, 2016-03-02 15:54:02]

The CQ bit was checked by alexmos@chromium.org

[alexmos, 2016-03-02 15:54:02]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/1742923002/#ps80001
(title: "Address japhet@'s comment")

[commit-bot: I haz the power, 2016-03-02 15:54:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1742923002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1742923002/80001

[commit-bot: I haz the power, 2016-03-02 17:05:02]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-03-02 17:06:40]

Description was changed from

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
TEST=http/tests/security/contentSecurityPolicy/1.1/frame-ancestors/* and
http/tests/security/XFrameOptions/* still pass
==========

to

==========
Commit empty document instead of canceling the load for blocked CSP/XFO
responses.

Currently, loads that are blocked due to X-Frame-Options or CSP
frame-ancestors are canceled (firing DidFailProvisionalLoad).  As part
of blocking, the current Document's origin is also changed to unique,
and the load event is fired in the FrameOwner, presumably so that the
load looks like a normal cross-origin load, where one can't discover
whether or not it was blocked.

The current implementation means that if the frame was showing another
page before attempting the blocked load, that old page will still be
showing and interactive after the block.  However, the old page's
origin becomes unique, so it loses ability to communicate with its
original origin.  This is not only confusing, but also seems
dangerous, as it gives someone an ability to revoke the effective
origin of a page by navigating it to something known to be blocked.
Besides DoS, this also gives an attacker a way to probe if the block
happened or not: if the attacker owns the subframe's current page and
the navigation is blocked, the current page will keep existing and can
check in with the server.

Additionally, this behavior is not compliant with the spec
(https://www.w3.org/TR/CSP2/#directive-frame-ancestors), which says that
the user agent should:
- Act as if it received an empty HTTP 200 response.
- Redirect the user to a friendly error page which provides the option of
  opening the blocked page in a new top-level browsing context.

This CL changes things to follow the first option in the spec and
pretend that a blocked frame receives an empty 200 response.  It still
sets the unique origin on the resulting Document, since that is also
part of the spec (the spec actually says to sandbox the Document fully
and not just with SandboxOrigin, but that change can be done
separately if desired, as it will likely break a bunch of layout
tests).  The load event on the FrameOwner will now be fired during the
regular commit process on the empty document, as opposed to special
logic in DocumentLoader::cancelLoadAfterXFrameOptionsOrCSPDenied.

The original motivation for this change was that canceling blocked
loads led to problems with cross-process iframes, since the blocking
happened after process swap, when the browser process assumes the
frame's new process is going to commit, but it doesn't.  This change
is more compatible with OOPIFs, and in fact fixes a bunch of layout
tests with --site-per-process and all the problems mentioned in issue
584845 without any special logic in content/.

BUG=584845
TEST=http/tests/security/contentSecurityPolicy/1.1/frame-ancestors/* and
http/tests/security/XFrameOptions/* still pass

Committed: https://crrev.com/77f6ed50529fb670db4cb3989bae5d93515a33a5
Cr-Commit-Position: refs/heads/master@{#378762}
==========

[commit-bot: I haz the power, 2016-03-02 17:06:41]

Patchset 5 (id:??) landed as
https://crrev.com/77f6ed50529fb670db4cb3989bae5d93515a33a5
Cr-Commit-Position: refs/heads/master@{#378762}