Actually a functional bug rather than security per-se, but setting embargo since it talks about affected sites.

mkwst - this was intentional, right?  

Got it, I'm trying to learn why the change happened in the latest release.  Was this how it was always intended to work or was there an explicit decision in 64 to disable this functionality?  We really get a ton of advantage out of this feature.  As you can imagine, we launch tons of new sites every day and even if they are on different origins we have rolled out the report-uri so we can capture XSS reports on those sites.  This has been one of our highest signal XSS monitoring solutions we use at Netflix.  

Nice to hear that it is (was) useful for you. We made the change in https://chromium-review.googlesource.com/c/chromium/src/+/768367 to avoid some privacy concerns, but perhaps it is too strong.

Contemplating possibilities, would a restriction of eTLD+1 (i.e. *.netflix.com) work for your use case? Or do you need to stand up sites on unrelated top-level domains?

Thanks the eTLD+1 would help, however, we have around 150+ TLDs and we inject the x-xss-protection report-uri header in our base image for all instances we deploy in AWS.  Since we aren't sure what TLD the underlying application will respond to, we are hoping all reports could be sent to our reporting server (example.netflix.com) regardless of TLD.


As an example, we may have an app such as foo.netflix.io where we set the reporting-uri to example.netflix.com because we have no idea what DNS record that host will resolve to in advance of pushing out our base image.  

Hi everyone,

Is there any update on this issue?

Thanks,
Scott

Hi, sorry, we need to discuss this more internally before coming to any conclusions, and some folks are away at the moment.

 Issue 817549  has been merged into this issue.

I don't think this should be embargoed, as the regressing change broke other sites (Youtube, t.co, etc) and the affected sites mentioned in #1 are public and Chrome announces the impact of the change simply by visiting the site and looking at the console. 

Thanks for adding me to this bug, my other issue was merged in as a dupe. 

I run https://report-uri.com and we're a security reporting service covering CSP, HPKP, Expect-CT, Expect-Staple and we were in the process of testing X-Xss-Protection reporting with some of our customers. 

We were caught off guard with this change and it resulted in error messages in the console for those participating in testing. 

The restriction of eTLD+1 wouldn't be helpful for us because all sites would be reporting to our 3rd party origin in the format {username}.report-uri.com which is our approach for all of the other reporting mechanisms. 

The other issue about an insecure reporting endpoint didn't make us look good either: https://bugs.chromium.org/p/chromium/issues/detail?id=807304

An ETA here would be great. 

I think it's probably reasonable to roll back the change. I believe we misunderstood the underlying issue it was meant to fix (https://bugs.chromium.org/p/chromium/issues/detail?id=441275), and we underestimated the usage the feature sees in the wild. Matching CSP's behavior here seems reasonable (along with eventually migrating this reporting functionality over to the Reporting API (and, you know, documenting it, at least a tiny little bit)).

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

commit 71f7b2b768f7edafdd46553e0c42376ddc96f117
Author: Mike West <mkwst@chromium.org>
Date: Tue Mar 06 19:37:34 2018

Restore cross-origin reporting to the XSS Auditor.

Bug:  811440 
Change-Id: I51253d721b30255f8270eacb67d5bcf629f90da1
Reviewed-on: https://chromium-review.googlesource.com/949046
Commit-Queue: Mike West <mkwst@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541173}
[modify] https://crrev.com/71f7b2b768f7edafdd46553e0c42376ddc96f117/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-expected.txt
[modify] https://crrev.com/71f7b2b768f7edafdd46553e0c42376ddc96f117/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-https-expected.txt
[modify] https://crrev.com/71f7b2b768f7edafdd46553e0c42376ddc96f117/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-https.html
[modify] https://crrev.com/71f7b2b768f7edafdd46553e0c42376ddc96f117/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp

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

commit a6c614be7313e8428f01f08d05a7ef3f59992c95
Author: Mike West <mkwst@chromium.org>
Date: Mon Mar 26 08:17:48 2018

Restore cross-origin reporting to the XSS Auditor.

TBR=mkwst@chromium.org

(cherry picked from commit 71f7b2b768f7edafdd46553e0c42376ddc96f117)

Bug:  811440 ,  823624 
Change-Id: I51253d721b30255f8270eacb67d5bcf629f90da1
Reviewed-on: https://chromium-review.googlesource.com/949046
Commit-Queue: Mike West <mkwst@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#541173}
Reviewed-on: https://chromium-review.googlesource.com/979654
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#422}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/a6c614be7313e8428f01f08d05a7ef3f59992c95/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-expected.txt
[modify] https://crrev.com/a6c614be7313e8428f01f08d05a7ef3f59992c95/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-https-expected.txt
[modify] https://crrev.com/a6c614be7313e8428f01f08d05a7ef3f59992c95/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-https.html
[modify] https://crrev.com/a6c614be7313e8428f01f08d05a7ef3f59992c95/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp

Removing Embargo flag per #9. There are no non-public URLs in this bug.

 Issue 828120  has been merged into this issue.