Are the reports unique? Might this be intentional deduplication?

bool ContentSecurityPolicy::ShouldSendViolationReport(
    const String& report) const {
  // Collisions have no security impact, so we can save space by storing only
  // the string's hash rather than the whole report.
  return !violation_reports_sent_.Contains(report.Impl()->GetHash());
}

void ContentSecurityPolicy::DidSendViolationReport(const String& report) {
  violation_reports_sent_.insert(report.Impl()->GetHash());
}

If you mean that not all report arrive, but just some (due to deduplication), that is not correct. NONE of the reports arrive after this point.

My question is whether the reports are *unique*. Chrome won't send the same report again due to deduplication. For example, the script in the GitHub repro appears to generate a single violation which would contain the same data every time, so you should only expect to ever see that report one time for the life of the Chrome instance.

> NONE of the reports arrive after this point.

If the any of the "reports after this point" are unique, that would be a bug. If they aren't unique, that would be intentional.

Do you by chance have a Chrome Network log (https://dev.chromium.org/for-testers/providing-network-details) of the browser when it's in the failure state?

Thanks! I'll be checking my browser when it is stuck in that state again.

For the uniqueness, this should not be happening: without restarting the browser, just hitting the refresh over demo.php, I get this:

2017-04-12 09:54:49.692018, start
2017-04-12 09:54:50.412719, violation
2017-04-12 09:54:51.533429, error
2017-04-12 09:55:00.498544, timeout

2017-04-12 09:56:02.734019, start
2017-04-12 09:56:04.9399, error
2017-04-12 09:56:04.9700, violation
2017-04-12 09:56:13.485701, timeout

2017-04-12 09:56:17.364472, start
2017-04-12 09:56:17.666913, violation
2017-04-12 09:56:17.722572, error
2017-04-12 09:56:28.468026, timeout 

But according what you are saying, as the report is static, there should be only a single violation reported. Interesting...

Thank you for providing more feedback. Adding requester "nparker@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Note that the deduplication elawrence@ talks about above is limited to a single `ContentSecurityPolicy` object, which in turn is tied to a Document's lifetime. We don't attempt to deduplicate across documents, nor do we attempt to deduplicate between page loads. That is, if you reload the page, I'd expect it to POST again. I think that's the behavior you're seeing in comment 6.

Thanks! But in that case, we need to fall back to my original report: there is still a bug to be eliminated. :)

Marking as a normal bug rather than a Security bug, since CSP violation reports are mostly for debugging rather than security. I'm leaving the RVG label because it sounds like the links in Comment 7 are meant to be private.

Could possibly be related to issue 612070? Though there's not really enough information in that bug to be sure.

You can open the ticket, I'll delete the URLs.

I can't access 612070.

Deleted links and un-restricted the bug. I've un-restricted the other bug as well.

The other report (612070) seems to be static, the bug is never sent. In our case, it happens only after a while, but no changes in circumstances.

I don't think I understand the issue: the code at https://github.com/gaborgulyas/csp_test looks like it generates the same violation over and over again. If that's the case, then it should only be sent once per page-load in Chrome's current implementation. Is that the bug you're reporting? If not, I don't understand what you'd like Chrome to do differently. :)

Based on the earlier discussion, I /think/ the claim is that, after Chrome is alive for a few days, it stops sending reports of violations entirely. The gaborgulyas/csp_test page is simply used to confirm that the browser is in this broken state. gaborgulyas@ can you confirm.

I can't think of any reason the browser could get into this state unless there's a more general problem in networking. Hence my request for Network Logs in Comment #3.

elawre...@ I confirm.

No one in the thread have yet proposed a legit explanation.

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Ok. Network logs would be helpful, but given that the reproduction steps are:

1. Open a page.
2. Wait several days.
3. Observe the lack of a CSP report.

It's not clear how we'd collect them. :)

I added more details to this blogpost:
https://gulyas.info/blog/read/28/

I'll send the logs if I encounter the issue again.