Re: [w3ctag/design-reviews] Reporting (#585)

Thanks for taking the time to look at this, @atanassov! I'll try to address each of those questions here -- note that some of these points have already been addressed as part of the [TAG review of ReportingObserver](https://github.com/w3ctag/design-reviews/issues/195) mentioned in the 'You should also know that' section.

As a general point, I'm not sure what you mean when you've used the word 'endpoint' -- in the spec, a [reporting endpoint](https://w3c.github.io/reporting/#concept-endpoints) is the location of an HTTP server which can accept POST requests containing reports. I feel like you're using it to mean something different here, so if I've misunderstood your questions, let me know and I'll try to clarify.

> * Can you provide an explicit list of the types of reports we are evaluating for?

Probably not, and this is by design -- the API is a generic framework for other other specs to use to achieve consistent reporting across features. I would prefer to evaluate this API on its own merits, based on what it can and cannot enable, rather than the specific list of current integrations. That said, I can understand that it's difficult to do that completely out of context. The current list of APIs which use this framework for reporting are:
 - [Content Security Policy Level 3](https://w3c.github.io/webappsec-csp/#reporting)
 - [Cross-origin Opener Policy](https://github.com/camillelamy/explainers/blob/master/coop_reporting.md)
 - [Permissions Policy](https://w3c.github.io/webappsec-permissions-policy/#reporting)
 - [Document Policy](https://wicg.github.io/document-policy/#reporting)
 - [Deprecation Reporting](https://wicg.github.io/deprecation-reporting/)
 - [Intervention Reporting](https://wicg.github.io/intervention-reporting/)
 - [Crash Reporting](https://wicg.github.io/crash-reporting/)
 - The related [Network Reporting API](https://w3c.github.io/reporting/network-reporting.html), which enables [Network Error Logging](https://w3c.github.io/network-error-logging/) (there is still work to do there to finish that integration)

(I hope I haven't missed any, but I'll comment if I find new ones)

> * Given this feature could be sending PII through such reports, can you please complete the Privacy & Security questionnaire?

Linked above at https://github.com/w3c/reporting/blob/master/security-and-privacy-questionnaire.md

> * Some of the report endpoints have to be sent by definition to different servers. That would mean we're exposing information to a 3rd party by design. Are we reading the proposal correctly?

The purpose of the reporting framework is to allow reports to be sent over HTTP to remote servers. Cross-origin and third-party servers are included by design, under the belief that:
 - It can be necessary, especially in the case of APIs such as network error logging, to have a report collector which is separate from the site which produces the error.
 - Organizations will probably want to have a central report collector, rather than hosting an endpoint on every origin.
 - Allowing third-party collectors enables an ecosystem of report hosting and analysis services, such as Report-uri.com and uriports.com, among others.
 - In general, the same or similar information could be communicated with third parties through other means (cross-origin subresources, XHR, beacons, etc).

> * What would the list of all types of endpoints be?

I'm not sure what you mean here -- endpoints are the URLs / servers to which reports are sent. They don't have types, unless you're drawing a 1p/3p distinction, or categorizing them by the types of reports which they choose to accept. Can you clarify this question?

> * Would an event be more appropriate?

There was [discussion](https://github.com/w3c/reporting/issues/29) on this when ReportingObserver was designed, although I wasn't part of those discussions at the time (@juliatuttle or @RByers may have additional historical context). I do believe that an observer would be preferable to an event, to support batching (reports are delivered as a list,) post hoc reporting (observers can be registered to retrieve reports from events which happened before they were created, which is useful for early-page-load events,) and to make it easy to write handlers for just some subset of report types. Additionally, the event infrastructure introduces complications such as bubbling, and can require coordination between multiple listeners, neither of which is useful here.

> * Using such reporting mechanism, do you expect to have user-generated events part of the same reports?

Not currently -- there are no free-form user-generated reports. The closest thing that exists is the test-driver-only generateTestReport API. However, it is not impossible for another spec to integrate in that way; nothing in this API prevents that. I suspect that would require a lot more scrutiny, for the possible XSS / injection issues at least. Is the TAG aware of other issues that would mean that we should strongly discourage such things?

> * Should all reports be visible to script?

No, by design there is an allowance for reports which are not visible. This can be just by necessity (crash reports, for instance), or it might be important for privacy, if there are cases where it's not advisable for the page to have immediate, real-time script access to user events.

> * Currently the JSON object includes keys in both underscore case (user_agent) and camelCase (lineNumber). For consistency, it would be best to use underscore case only.

This was discussed in https://github.com/w3c/reporting/issues/72, and I think that the decision was made to follow the TAGs recommendations wherever possible, but that in some cases (CSP reports, for instance,) backwards-compatibility issues meant keeping camelCase identifiers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/585#issuecomment-768563886