reporting of metadata such as browser engine+version or other metadata chosen by page?

[dbaron]

The explainer and draft don't seem to say much about reporting relevant metadata, such as what browser engine was in use. Yet some of the reports are going to be things that are specific to a browser engine, specific to a range of versions within an engine, or specific to other things. (In particular, the crash report example in the explainer, with only a crash report ID and without information saying which crash reporting system to look the ID up in, got me thinking about this.)

This led me to wonder:

• should there be metadata giving something like the User-Agent string of the browser in which the error occurred (which, given delayed reporting, might not be the same as the one submitting the report)?
• should there be other metadata associated with the report, either by default, or through a mechanism that the page could use?

(I suppose there might be some privacy issues to consider with the latter, but I'm not particularly concerned at first glance given that a page should be able to trigger reporting of things like script errors with per-user source URIs if they wanted to. At least, I'm not particularly concerned with the ability to associate metadata increasing any risks.)

(I got here via w3ctag/design-reviews#195.)

[RByers]

It's a good question, thanks. We're talking about the UA string in particular in #52 (I had thought the User-Agent header was enough, but Travis points out it may not be in all cases).

The JS API (ReportingObserver) is designed specifically to allow the page to capture any custom metadata it wants when it registers or unregisters an observer (eg. when entering/leaving the scope of a library). But for performance it doesn't have the ability to capture state at exactly the time of report generation. Is this good enough?

What other sort of metadata were you thinking about @dbaron?

[dbaron]

The site might want to include version information about the site itself, e.g., which revision it was built from, or which experiments were enabled. I'd missed the bit about the page being able to associate that already -- in which case that, plus something UA-string-like, seems likely to be sufficient.

[patrickkettner]

I think for the v1 the best ways to accomplish this would either be

1. Use the ReportingObserver and add whatever you want
2. Add an arbitrary query string to the reporting endpoint and parse it back there.

1 is sort of self evident if you are already using it, but 2 is probably less obvious. I'll PR to the explainer to explicitly call out this use case.

For user agent specific information, we started discussing it in #52