Could there be a way to collect Crash/Intervention reports without collecting Depreciation reports?

[Sora2455]

Or any other combination of the above?

I ask because a proxy downstream of my site appears to be adding the Expect-CT header, which is causing my reporting server to be spammed with "Expect-CT is depreciated" depreciation reports. To stop the flood of reports, I have no choice but to stop collecting Depreciation, Intervention and Crash reports - when I only actually want to stop collecting Depreciation reports (or at least stop receiving that one report).

I can't contact the proxy (I don't even know for sure it exists or which of my clients might be using it), and I can't add a filter to the reporting server (it's a third-party service).

[clelland]

We should probably have a way to configure deprecation/intervention/crash reports independently of each other. I'm not sure where that configuration should go; maybe we should discuss in the WG.

[neilstuartcraig]

Yes, I completely agree. It's also somewhat odd to me that you only receive deprecation, intervention etc. reports to the default reporting endpoint (or at least that was the case last time I checked).

There's a similar proposal for NEL so perhaps the same syntax could be used in both for consistency.

[clelland]

That's still the case -- it made it really easy to configure, with the old Reporting header, but the downside is that you can't opt out of any of the three. There should be some way to configure these, and hopefully not requiring three additional headers.

[aluhrs13]

Could there be overlap between this and #45? Allowing sampling control per report type would probably handle both this issue and that one?

[rfmoz]

I also add the following sample image. The volume received from type intervention is ~500% over the other ones, and, in our case, is useless:

I think that the network-error failure_fraction capability must be a requirement for all reporting types.

Taking the same syntax proposed in w3c/network-error-logging#133 could solve the problem inside the network-error body, but maybe it's easier to define a nel header to cover all the types. For example:

{
  "network-error": {
    "failure_fraction": 1,
    "include": "dns,tcp,tls"
  },
  "network-error": {
    "failure_fraction": 0,
    "include": "http"
  },
  "intervention": {
    "report_to": "intervention",
    "max_age": 600,
    "failure_fraction": 0.5
  },
  "deprecation": {
    "failure_fraction": 0
  },
  "crash": {
    "failure_fraction": 0
  },
  "default": {
    "report_to": "default",
    "max_age": 3600,
    "failure_fraction": 1
  }
}

nel: {"network-error":{"failure_fraction":1,"include":"dns,tcp,tls"},"network-error":{"failure_fraction":0,"include":"http"},"intervention":{"report_to":"intervention","max_age":600,"failure_fraction":0.5},"deprecation":{"failure_fraction":0},"crash":{"failure_fraction":0},"default":{"report_to":"default","max_age":3600,"failure_fraction":1}}
report-to: {"group":"default","max_age":3600,"endpoints": [{"url":"https://example.com/default"}]}
report-to: {"group":"intervention","max_age":3600,"endpoints": [{"url":"https://example.com/intervention"}]}