Field naming inconsistency

[Synchro]

In the spec itself, the feature that triggered the report is documented as featureId. Other fields are similarly camel-cased. However, the additional docs uses featureId as well, but other fields are snake-cased (like line_number).

I've configured reporting using Chrome Canary 143, and it delivers real reports that do not contain a featureId field at all, but a policyId field instead. The other fields are snake-cased, apart from source file which appears twice, once as source_file and once as sourceFile! Here's a real report body, as delivered to report-uri.com (which looks like it removes the outer Report-To elements):

{
    "columnNumber": 23,
    "lineNumber": 2,
    "message": "Permissions policy violation: Geolocation access has been blocked because of a permissions policy applied to the current document. See https://crbug.com/414348233 for more details.",
    "policyId": "geolocation",
    "sourceFile": "https://neo.hakr.site/js/permissions.js",
    "url": "https://neo.hakr.site/reporting.php",
    "source_file": "https://neo.hakr.site/js/permissions.js"
}

policyId does not appear anywhere in this repo, yet that appears to be what browsers have implemented! Similarly, the url property isn't in the spec for the report body, though it should appear in the outer report-to structure.

Consequently, I'm really not sure what I should be implementing; it's all very confused!

It would be good to know what @ScottHelme sees in actual reports.

[ScottHelme]

Hey @Synchro, I just captured this Reporting API request from latest stable Chrome:

[
    {
        "age": 11431,
        "body": {
            "columnNumber": 23,
            "disposition": "enforce",
            "lineNumber": 1,
            "message": "Permissions policy violation: Geolocation access has been blocked because of a permissions policy applied to the current document. See https://crbug.com/414348233 for more details.",
            "policyId": "geolocation"
        },
        "type": "permissions-policy-violation",
        "url": "https://report-uri.com/",
        "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
    }
]

With many of our telemetry events sent through the Reporting API, we can flatten them out and do a little normalisation, but we do show the actual raw data. The above event would show the body and possibly be enriched with other data too:

{
    "columnNumber": 23,
    "lineNumber": 1,
    "message": "Permissions policy violation: Geolocation access has been blocked because of a permissions policy applied to the current document. See https://crbug.com/414348233 for more details.",
    "policyId": "geolocation",
    "url": "https://report-uri.com/"
}

I believe the featureId is a remnant of Feature Policy [source] and we don't process those events now.

[ScottHelme]

I found an old Feature Policy report body that we use to process:

[
	{
		"type": "feature-policy-violation",
		"url": "https://report-uri.com",
		"age": 60000,
		"user_agent": "Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)",
		"body": {
			"featureId": "geolocation",
			"message": "Geolocation access has been blocked because of a Feature Policy applied to the current document. See https://goo.gl/EuHzyv for more details.",
			"source_file": "https://report-uri.com",
			"line_number": 20,
			"column_number": 37,
			"disposition": "enforce"
		}
	}
]

[Synchro]

Thanks Scott – I guess the implementations are getting ahead of the spec! Those first examples are missing a sourceFile property. Did you remove them, or are they really not there?

[ScottHelme]

If it's present we will process it, but it's also nullable and may not be present.

[Synchro]

As I see it, the top-level url property will reference a page, and sourceFile should reference a script loaded by that page, which I guess will be null or unset if it's an inline script.

[ScottHelme]

The Permissions Policy example I gave above was an inline violation so that tracks.

[Synchro]

Weirdly, Chromium source still contains featureId, but that doesn't seem to be what shows up in browsers. It also has additional allowAttribute and srcAttribute fields, but I don't know what they are for.