affected all platform besides OSX

Assigning to estark@, since referer is in her realm.

This is a preload issue. We pick up a document's referrer policy from meta tags if we scan one while preloading, but we don't use a referrer policy set via header. Looks like we just need to be using document->getReferrerPolicy() here: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp&sq=package:chromium&l=802&rcl=1461222997

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e49d943e9f5f90411313e64d0ae6b646edc85043

commit e49d943e9f5f90411313e64d0ae6b646edc85043
Author: estark <estark@chromium.org>
Date: Thu Apr 28 01:08:51 2016

Use document referrer policy when preloading

Previously, preload requests used the referrer policy from meta tags
encountered during scanning, but not from headers delivered with the
page. This CL uses the document's current referrer policy when the
preload scan starts.

BUG= 605451 

Review-Url: https://codereview.chromium.org/1913983002
Cr-Commit-Position: refs/heads/master@{#390264}

[add] https://crrev.com/e49d943e9f5f90411313e64d0ae6b646edc85043/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/referrer-from-document-on-preload-expected.html
[add] https://crrev.com/e49d943e9f5f90411313e64d0ae6b646edc85043/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/referrer-from-document-on-preload.php
[modify] https://crrev.com/e49d943e9f5f90411313e64d0ae6b646edc85043/third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp
[modify] https://crrev.com/e49d943e9f5f90411313e64d0ae6b646edc85043/third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp

Updating title to be more specific

Thank you for your quick response to this security issue.
How can i get a CVE number, could you assign it?  : )

+timwillis

Hello,

CVE-IDs are only assigned where the bug is in a stable build (this issue in in stable) and the bug meets the severity for a reward. We'll take this to our reward panel and let you know if it meets the threshold for a reward and a CVE-ID.

all right, this issue bypass the chrome W3C standard security policy , i think it should be assigned a CVE-ID. any way , waiting for your conclusions , thank you~ 

is there any conclusion?

Congratulation, the panel has decided to award $500 for this bug.  Our finance team will be in touch in the new few weeks with more details.

Thank you very much, i recieved a email from your finance team. i'll follow the steps in the email. so , is there a CVE-ID assigned or acknowledgment later ?  :)  hope for that

+awhalley@ whether to take this merge in for M53 Dev release on Tuesday (07/26).

Humm - this should already be in 53 (commit was at 390264, 53 branched at 403382).  

+mbarbella@ - a sheriffbot hiccup or me getting the wrong end of the stick?

This is related to the same issue we discussed yesterday (it's trying to request a merge to beta using stable + 1 instead of the actual beta milestone). I should be able to fix this later today.

+awhalley@, do we need a merge to M52?

Nope, already in M52.

[Automated comment] Commit may have occurred before M53 branch point (6/30/2016), needs manual review.

Per comment #24, this is already in M53 branch 2785. So removing "Merge-Review-53" label. 

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot