Implement new referrer policies

Implement new referrer policies

This CL implements the policies 'same-origin' and 'strict-origin', and
repurposes existing logic that was previously only available behind a flag for
'strict-origin-when-cross-origin'. (I've left it as a TODO for a follow-up
to rename this policy to match the spec.)

Existing web platform tests cover the new policies and should now pass.

Intent to Implement and Ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/TgtPUowSWuU/Y-Sn2oRsCAAJ

BUG=627968
Review-Url: https://codereview.chromium.org/2918313002
Cr-Commit-Position: refs/heads/master@{#479182}
Committed: https://chromium.googlesource.com/chromium/src/+/c8ccba8b415fa20f5ded85c58a100cfb3cdda4c4

[estark, 2017-06-05 10:05:38]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 10:05:45]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-05 10:12:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 10:12:17]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[estark, 2017-06-05 21:50:37]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 21:51:39]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-05 22:01:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 22:01:45]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[estark, 2017-06-05 23:19:29]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 23:20:03]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[estark, 2017-06-05 23:21:02]

Description was changed from

==========
Implement new referrer policies

This CL implements the policies 'same-origin' and 'strict-origin', and
repurposes existing logic that was previously only available behind a flag for
'strict-origin-when-cross-origin'.

This does not yet update iOS logic. I've also left it as a TODO to rename the
policy that was behind a flag and should be named
strict-origin-when-cross-origin.

Existing web platform tests cover the new policies and should now pass.

BUG=627968
==========

to

==========
Implement new referrer policies

This CL implements the policies 'same-origin' and 'strict-origin', and
repurposes existing logic that was previously only available behind a flag for
'strict-origin-when-cross-origin'. (I've left it as a TODO for a follow-up
to rename this policy to match the spec.)

Existing web platform tests cover the new policies and should now pass.

Intent to Implement and Ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/TgtPUowSWuU/Y-Sn2oRs...

BUG=627968
==========

[estark, 2017-06-05 23:24:31]

estark@chromium.org changed reviewers:
+ jochen@chromium.org

[estark, 2017-06-05 23:24:32]

Jochen, PTAL? (Sorry for the large CL... a lot of it is mechanical.)
Caveats:
- I2S hasn't been approved yet, obviously I won't land before it is.
- I haven't built the iOS code locally, I'm doing it on the bots, so that part
might be nonsense.
Thanks!

[commit-bot: I haz the power, 2017-06-05 23:30:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 23:30:31]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[estark, 2017-06-05 23:38:20]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 23:39:11]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-05 23:50:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 23:50:42]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[estark, 2017-06-05 23:51:43]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 23:52:47]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-06 00:04:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-06 00:04:26]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[jochen (gone - plz use gerrit), 2017-06-06 14:51:27]

lgtm with nit

https://codereview.chromium.org/2918313002/diff/80001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebReferrerPolicy.h (right):

https://codereview.chromium.org/2918313002/diff/80001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebReferrerPolicy.h:43:
kWebReferrerPolicySameOrigin,
these should go at the end, as we write the static_cast<int> version to
navigation entries on disk/sync, and adding them in the middle will confuse
older clients

[estark, 2017-06-06 22:38:13]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-06 22:38:49]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[estark, 2017-06-06 22:40:59]

estark@chromium.org changed reviewers:
+ kkhorimoto@chromium.org, mmenke@chromium.org, pfeldman@chromium.org

[estark, 2017-06-06 22:41:00]

Thanks, Jochen. Adding in other owners:
- mmenke for net/
- kkhorimoto for ios/
- pfeldman for third_party/WebKit/Source/core/inspector/browser_protocol.json

https://codereview.chromium.org/2918313002/diff/80001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebReferrerPolicy.h (right):

https://codereview.chromium.org/2918313002/diff/80001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebReferrerPolicy.h:43:
kWebReferrerPolicySameOrigin,
On 2017/06/06 14:51:27, jochen wrote:
> these should go at the end, as we write the static_cast<int> version to
> navigation entries on disk/sync, and adding them in the middle will confuse
> older clients

Ah, ok, good to know. Switched the order, and added a comment at the top.

[commit-bot: I haz the power, 2017-06-06 22:42:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-06 22:42:19]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[estark, 2017-06-06 22:49:55]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-06 22:50:30]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-06 23:00:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-06 23:00:58]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[mmenke, 2017-06-07 21:04:03]

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request.h (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request.h:99: // requests will send the full referrer.
Remove "(currently stripped down to an origin rather than a full URL)" - that
implies this is an ad hoc behavior, but now that there's a spec requiriing it,
seems like we should be less fuzzy about it.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request.h:112:
ORIGIN_CLEAR_ON_TRANSITION_FROM_SECURE_TO_INSECURE,
These names aren't accurate - not sure if there's a way to be clearer without
making them take up 5 lines each, but it's not the transition that makes us
clear the referrer, but rather having a secure referrer and an insecure page. 
Could update the descriptions, at least.

i.e., if https://secure/ requests http://foo.com/ with policy ORIGIN,
http://foo.com/ sees the referrer, but if foo.com then changes the policy with
"strict-origin" and redirects to http://bar.com/, bar.com does not see the
referrer, even though it's not a secure to insecure transition.

There are also lots of other fun cases (secure->insecure->secure and then set a
policy that only keeps referrer on secure sites won't retroactively remove the
referrer, for instance).

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_job.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job.cc:90: for (const auto& token : policy_tokens) {
Random question:  Is it right to take the last policy, or should we use the
first one we recognize?

If a site wanted up-to-date, fancy browsers to use one policy, but had a
fallback for sites that may not support shiny new policies, should the fallback
one be first or last?  With this code, it should be first.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job.cc:120: new_policy =
URLRequest::CLEAR_REFERRER_ON_TRANSITION_CROSS_ORIGIN;
Hrm...Wonder if it's better to have clearer policy names, or match names to the
tokens.  Ah, well, this matches the current pattern, regardless.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_job_unittest.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job_unittest.cc:399: policy */
Maybe replace "expected final policy" with "final policy" or put it before the
field?  The 2-3 lines of mostly whitespace makes it very easy (For me, at least)
to overlook the final line of the expectation.  I keep on getting lost in the
code, and forgetting these tests are checking the final referrer, and not just
the policy.  Another option is just to remove the expected final policy
comments.  I think readability is improved greatly without all the extra
whitespace.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_unittest.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8871:
VerifyReferrerAfterRedirect(URLRequest::ORIGIN, referrer.GetOrigin(),
first referrer.GetOrigin() -> referrer

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8880: referrer.GetOrigin(),
referrer.GetOrigin());
first referrer.GetOrigin() -> referrer

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8905:
VerifyReferrerAfterRedirect(URLRequest::ORIGIN, referrer.GetOrigin(),
first referrer.GetOrigin() -> referrer

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8913: referrer.GetOrigin(),
referrer.GetOrigin());
first referrer.GetOrigin() -> referrer

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8915:
VerifyReferrerAfterRedirect(URLRequest::NO_REFERRER, GURL(), GURL());
first GURL() -> referrer

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8936:
VerifyReferrerAfterRedirect(URLRequest::ORIGIN, referrer.GetOrigin(),
Please fix the rest of these, too.

[kkhorimoto, 2017-06-08 00:56:46]

https://codereview.chromium.org/2918313002/diff/120001/ios/web/public/referre...
File ios/web/public/referrer_util.cc (left):

https://codereview.chromium.org/2918313002/diff/120001/ios/web/public/referre...
ios/web/public/referrer_util.cc:73: return web::ReferrerPolicyNever;
It looks like we were intentionally using Never here per the spec above; can you
revert that change?

[estark, 2017-06-08 18:39:29]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-08 18:40:03]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[estark, 2017-06-08 18:42:58]

https://codereview.chromium.org/2918313002/diff/120001/ios/web/public/referre...
File ios/web/public/referrer_util.cc (left):

https://codereview.chromium.org/2918313002/diff/120001/ios/web/public/referre...
ios/web/public/referrer_util.cc:73: return web::ReferrerPolicyNever;
On 2017/06/08 00:56:46, kkhorimoto_ wrote:
> It looks like we were intentionally using Never here per the spec above; can
you
> revert that change?

Sorry, I should have explained this, but quite a while ago the spec changed to
ignore unknown values:
https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values

I can do this change in a separate CL if you prefer, but we should make this
change one way or another to match the spec.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request.h (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request.h:99: // requests will send the full referrer.
On 2017/06/07 21:03:57, mmenke wrote:
> Remove "(currently stripped down to an origin rather than a full URL)" - that
> implies this is an ad hoc behavior, but now that there's a spec requiriing it,
> seems like we should be less fuzzy about it.

Done.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request.h:112:
ORIGIN_CLEAR_ON_TRANSITION_FROM_SECURE_TO_INSECURE,
On 2017/06/07 21:03:57, mmenke wrote:
> These names aren't accurate - not sure if there's a way to be clearer without
> making them take up 5 lines each, but it's not the transition that makes us
> clear the referrer, but rather having a secure referrer and an insecure page. 
> Could update the descriptions, at least.
> 
> i.e., if https://secure/ requests http://foo.com/ with policy ORIGIN,
> http://foo.com/ sees the referrer, but if http://foo.com then changes the
policy with
> "strict-origin" and redirects to http://bar.com/, http://bar.com does not see
the
> referrer, even though it's not a secure to insecure transition.
> 
> There are also lots of other fun cases (secure->insecure->secure and then set
a
> policy that only keeps referrer on secure sites won't retroactively remove the
> referrer, for instance).

Updated the comments. I think it would also help to name these values to match
the spec, but perhaps that can be for a different CL.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_job.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job.cc:90: for (const auto& token : policy_tokens) {
On 2017/06/07 21:03:59, mmenke wrote:
> Random question:  Is it right to take the last policy, or should we use the
> first one we recognize?
> 
> If a site wanted up-to-date, fancy browsers to use one policy, but had a
> fallback for sites that may not support shiny new policies, should the
fallback
> one be first or last?  With this code, it should be first.

Yeah, that is intentional per spec:
https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values

I added a link here in a comment.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job.cc:120: new_policy =
URLRequest::CLEAR_REFERRER_ON_TRANSITION_CROSS_ORIGIN;
On 2017/06/07 21:03:58, mmenke wrote:
> Hrm...Wonder if it's better to have clearer policy names, or match names to
the
> tokens.  Ah, well, this matches the current pattern, regardless.

Agree, I think it would be better to match the token names from the spec, but
would prefer to do that rename in a separate CL.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_job_unittest.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job_unittest.cc:399: policy */
On 2017/06/07 21:04:00, mmenke wrote:
> Maybe replace "expected final policy" with "final policy" or put it before the
> field?  The 2-3 lines of mostly whitespace makes it very easy (For me, at
least)
> to overlook the final line of the expectation.  I keep on getting lost in the
> code, and forgetting these tests are checking the final referrer, and not just
> the policy.  Another option is just to remove the expected final policy
> comments.  I think readability is improved greatly without all the extra
> whitespace.

Done; I just removed it for these cases where the policy name is long.

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_unittest.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_unittest.cc:8871:
VerifyReferrerAfterRedirect(URLRequest::ORIGIN, referrer.GetOrigin(),
On 2017/06/07 21:04:03, mmenke wrote:
> first referrer.GetOrigin() -> referrer

Unintuitive as it is, this is actually intentional. URLRequest expects the
original referrer set with SetReferrer to already match the referrer policy, and
clears it if it doesn't. (The clearing part is surprising to me; I would have
expected it to be a DCHECK, but that part predates me so I'm not sure what the
motivation is.) See the comment at [1] ("the caller is response for setting the
initial Referer..."). Thus, these test cases are basically just checking that
the referrer doesn't get cleared or anything funky like that when following
redirects with these policies.

I've done 3 things to try to make this more clear:

1.) Added comments to URLRequest::SetReferrer and set_referrer_policy to make
the URLRequest contract more clear.
2.) Added comments to these test cases (though I ended up repeating the same
rather wordy comment in a bunch of places, not sure if that's more or less
readable...)
3.) Renamed URLRequestJob::ComputeReferrerForRedirect to
ComputeReferrerForPolicy, to make the code that enforces this contract more
clear. That is: URLRequest::StartJob was calling ComputeReferrerForRedirect to
check that the referrer matches the policy, and that was confused to me because
it was calling it even in non-redirect cases.

[1]
https://cs.chromium.org/chromium/src/net/url_request/url_request.h?q=URLReque...

[estark, 2017-06-08 18:45:46]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-08 18:46:00]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-08 18:57:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-08 18:57:16]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[mmenke, 2017-06-08 19:11:28]

net/ LGTM

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
File net/url_request/url_request_job.cc (right):

https://codereview.chromium.org/2918313002/diff/120001/net/url_request/url_re...
net/url_request/url_request_job.cc:90: for (const auto& token : policy_tokens) {
On 2017/06/08 18:42:58, estark (slow thru Jun8) wrote:
> On 2017/06/07 21:03:59, mmenke wrote:
> > Random question:  Is it right to take the last policy, or should we use the
> > first one we recognize?
> > 
> > If a site wanted up-to-date, fancy browsers to use one policy, but had a
> > fallback for sites that may not support shiny new policies, should the
> fallback
> > one be first or last?  With this code, it should be first.
> 
> Yeah, that is intentional per spec:
> https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values
> 
> I added a link here in a comment.

Hrm...The spec looks ambiguous to me.  It says when multiple sources specify a
referrer policy, use the latest, but it doesn't define a "source".  I would
interpret a "source" to be a redirect leg / HTTP response, or possibly a
redirect header (In which case a header line with two comma-separated values is
still ambiguous).  If an HTTP response is a "source", the rule doesn't really
apply, and we don't know the temporal order in which headers were added,
anyways.

That having been said, example 12 does indicate this is the right behavior.

[estark, 2017-06-09 17:06:57]

Friendly ping to pfeldman (
third_party/WebKit/Source/core/inspector/browser_protocol.json) and kkhorimoto
(ios/)

[kkhorimoto, 2017-06-09 18:10:46]

ios/ lgtm

[estark, 2017-06-13 00:04:10]

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

[estark, 2017-06-13 00:04:11]

Another ping to pfeldman for 
third_party/WebKit/Source/core/inspector/browser_protocol.json

also +mkwst for IPC security review
(third_party/WebKit/public/platform/referrer.mojom)

[Mike West, 2017-06-13 08:49:58]

mojo LGTM. Tiny questions about tests.

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/external/wpt/beacon/headers/header-referrer-strict-origin-when-cross-origin.https-expected.txt
(right):

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/external/wpt/beacon/headers/header-referrer-strict-origin-when-cross-origin.https-expected.txt:3:
FAIL Test referer header http://web-platform.test:8001/beacon/resources/
assert_true: SendBeacon Succeeded expected true got false
Why does this still fail? Just the renaming you noted in the CL description?

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/external/wpt/beacon/headers/header-referrer-strict-origin.https-expected.txt
(right):

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/external/wpt/beacon/headers/header-referrer-strict-origin.https-expected.txt:3:
FAIL Test referer header http://web-platform.test:8001/beacon/resources/
assert_true: SendBeacon Succeeded expected true got false
Ditto?

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/security/referrer-policy-invalid-expected.txt
(right):

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/security/referrer-policy-invalid-expected.txt:1:
CONSOLE ERROR: line 8: Failed to set referrer policy: The value 'invalid' is not
one of 'always', 'default', 'never', 'origin-when-crossorigin', 'no-referrer',
'no-referrer-when-downgrade', 'origin', 'origin-when-cross-origin',
'same-origin', 'strict-origin', 'strict-origin-when-cross-origin', or
'unsafe-url'. The referrer policy has been left unchanged.
Do we still need this test?

[pfeldman, 2017-06-13 19:24:01]

browser_protocol.json lgtm

[estark, 2017-06-13 19:46:31]

Thanks, everyone.

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/external/wpt/beacon/headers/header-referrer-strict-origin-when-cross-origin.https-expected.txt
(right):

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/external/wpt/beacon/headers/header-referrer-strict-origin-when-cross-origin.https-expected.txt:3:
FAIL Test referer header http://web-platform.test:8001/beacon/resources/
assert_true: SendBeacon Succeeded expected true got false
On 2017/06/13 08:49:58, Mike West wrote:
> Why does this still fail? Just the renaming you noted in the CL description?

This seems like an unrelated bug; there are similar expectations for policies
that we already supported, like
external/wpt/beacon/headers/header-referrer-no-referrer-when-downgrade.https-expected.txt
and external/wpt/beacon/headers/header-referrer-unsafe-url.https-expected.txt

I couldn't find a bug on file for this so I filed crbug.com/732923

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/security/referrer-policy-invalid-expected.txt
(right):

https://codereview.chromium.org/2918313002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/security/referrer-policy-invalid-expected.txt:1:
CONSOLE ERROR: line 8: Failed to set referrer policy: The value 'invalid' is not
one of 'always', 'default', 'never', 'origin-when-crossorigin', 'no-referrer',
'no-referrer-when-downgrade', 'origin', 'origin-when-cross-origin',
'same-origin', 'strict-origin', 'strict-origin-when-cross-origin', or
'unsafe-url'. The referrer policy has been left unchanged.
On 2017/06/13 08:49:58, Mike West wrote:
> Do we still need this test?

Yeah, I think this is still good to have, to make sure we behave properly for
referrerpolicy="blahblahblah" or some such.

[estark, 2017-06-13 19:51:21]

The CQ bit was checked by estark@chromium.org

[estark, 2017-06-13 19:51:22]

The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org,
kkhorimoto@chromium.org, mkwst@chromium.org, mmenke@chromium.org,
pfeldman@chromium.org
Link to the patchset: https://codereview.chromium.org/2918313002/#ps180001
(title: "rebase")

[commit-bot: I haz the power, 2017-06-13 19:52:15]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-13 20:06:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-13 20:06:47]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[estark, 2017-06-13 20:07:38]

The CQ bit was checked by estark@chromium.org

[estark, 2017-06-13 20:07:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
kkhorimoto@chromium.org, mkwst@chromium.org, jochen@chromium.org,
mmenke@chromium.org, pfeldman@chromium.org
Link to the patchset: https://codereview.chromium.org/2918313002/#ps200001
(title: "update public/platform/OWNERS per presubmit")

[commit-bot: I haz the power, 2017-06-13 20:08:14]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-13 22:37:43]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1497384458681330,
"parent_rev": "98258cced1d9ed158af9e98706225119b6765e2d", "commit_rev":
"c8ccba8b415fa20f5ded85c58a100cfb3cdda4c4"}

[commit-bot: I haz the power, 2017-06-13 22:38:01]

Description was changed from

==========
Implement new referrer policies

This CL implements the policies 'same-origin' and 'strict-origin', and
repurposes existing logic that was previously only available behind a flag for
'strict-origin-when-cross-origin'. (I've left it as a TODO for a follow-up
to rename this policy to match the spec.)

Existing web platform tests cover the new policies and should now pass.

Intent to Implement and Ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/TgtPUowSWuU/Y-Sn2oRs...

BUG=627968
==========

to

==========
Implement new referrer policies

This CL implements the policies 'same-origin' and 'strict-origin', and
repurposes existing logic that was previously only available behind a flag for
'strict-origin-when-cross-origin'. (I've left it as a TODO for a follow-up
to rename this policy to match the spec.)

Existing web platform tests cover the new policies and should now pass.

Intent to Implement and Ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/TgtPUowSWuU/Y-Sn2oRs...

BUG=627968

Review-Url: https://codereview.chromium.org/2918313002
Cr-Commit-Position: refs/heads/master@{#479182}
Committed:
https://chromium.googlesource.com/chromium/src/+/c8ccba8b415fa20f5ded85c58a10...
==========

[commit-bot: I haz the power, 2017-06-13 22:38:04]

Committed patchset #11 (id:200001) as
https://chromium.googlesource.com/chromium/src/+/c8ccba8b415fa20f5ded85c58a10...