I think this rule in the report processing logic may have discarded your report @fgiunchedi:

# Apparently some User Agents don't follow the spec and ignore wildcards
# in the directive. Filter out false positives that come from that.
if RE_ALLOWED_DOMAINS.match(blocked_host):
    logger.debug("False report for %s: %s", tool, report["blocked-uri"])
    return resp

I have confirmed that toolforge.org is in the allowed_domains config list that is used to create the RE_ALLOWED_DOMAINS pattern at runtime.

I guess the question to ask now is if the me that decided this rule to filter out some obviously false positive reports from I assume older User-Agents is a good thing to retain.

I think I would argue that keeping the dashboards from reporting things that are confusing (like the CSP policy blocking sal.toolforge.org) is a benefit for end-user understanding of a potentially nuanced data set. I think that we should look for other mechanisms to discover implementation problems like something that would lead a User-Agent to attempt HTTP over port 443 which is apparently what happened to trigger the missing report.

T422829: Toolforge HTML head links sometimes are issued as http://<tool>.toolforge:443 seems to have been the problem behind the scenes here that led to the discarded report.

That's fair re: user confusion concerns. From my SRE POV I was surprised to find that the CSP report url we announce filters the feed of legitimate, albeit confusing to tool maintainers, reports. I am thinking of a middle ground where we collect all reports and present the report firehose unfiltered only on demand. The known-domains retention of course can be short as we don't really care for it except for operational problems. What do you think ?

In T422916#11828441, @fgiunchedi wrote:

That's fair re: user confusion concerns. From my SRE POV I was surprised to find that the CSP report url we announce filters the feed of legitimate, albeit confusing to tool maintainers, reports. I am thinking of a middle ground where we collect all reports and present the report firehose unfiltered only on demand. The known-domains retention of course can be short as we don't really care for it except for operational problems. What do you think ?

I'm not sure in the current pipeline where I would store reports with a different retention pattern or where I would insert output filtering to screen that noise from the maintainer facing interface. I don't have any objections to someone figuring those things out and implementing them if it feels like it would add value for administrative investigations.

In T422916#11830798, @bd808 wrote:

In T422916#11828441, @fgiunchedi wrote:

That's fair re: user confusion concerns. From my SRE POV I was surprised to find that the CSP report url we announce filters the feed of legitimate, albeit confusing to tool maintainers, reports. I am thinking of a middle ground where we collect all reports and present the report firehose unfiltered only on demand. The known-domains retention of course can be short as we don't really care for it except for operational problems. What do you think ?

I'm not sure in the current pipeline where I would store reports with a different retention pattern or where I would insert output filtering to screen that noise from the maintainer facing interface. I don't have any objections to someone figuring those things out and implementing them if it feels like it would add value for administrative investigations.

Ok! That's now T423847: Store and optionally show the full firehose in csp-report, resolving this task