Enable reporting via meta tag (or otherwise via JS)?

[RByers]

The spec doesn't say anything about <meta http-equiv=report-to> tags. Should they be supported? In particular, can reporting be enabled/disabled at any point during the page lifetime?

@nicjansma points out that it can be very difficult for RUM providers to get customers to change request headers, while running a bit of JavaScript to enable reporting is no big deal.

So should there be some way to enable reporting from JavaScript?

[patrickkettner]

👍 to non header based method, how much of an issue is it if a random actor inserts these into the dom without permission?

[igrigorik]

Trying to find old thread(s) on this... but not having much luck at the moment.

We did discuss this before though and the decision at the time was "no", because: we don't want arbitrary JS to modify reporting policies on behalf of the origin -- e.g. third party script disabling reporting of security violations (CSP, or some such); enabling <meta> but disabling JS modifications opens another large can of worms, etc. In other words, the SOASTA use case was an explicit "no".

[RByers]

Interesting. I can see that that makes sense for CSP, but is perhaps the wrong tradeoff for something like deprecation warnings? Could we get the best of both worlds by allowing policies to be extended via meta but not modified/removed?

[igrigorik]

Well, stepping back, is modifying reporting policies even the right primitive? For deprecations, perhaps we ought to expose those directly to javascript, such that tools can pick them up and beacon them directly? If the developer also sets a reporting policy.. then we'd ping them there as well.

[RByers]

Yeah I suppose we could just have two completely independent mechanisms the way CSP does (#29). Not all report types would necessarily have an event (eg. doesn't make sense for crash reports), but by convention many could. @patrickkettner @mikewest thoughts?

[igrigorik]

I don't think we have to expose every report via JS... navigation errors, crashes, etc, are all good examples where the report doesn't have a context to deliver to, and yet is often still time sensitive. Where it makes sense, and it is safe to do so, we can expose JS events and give developers an option to route those via reporting API; for some it'll be reporting API only.

[RByers]

Yep that makes sense to me.

[patrickkettner]

re: reports that happen contexts, could these be handled/modified via service worker (ie expose these events for any context that is running on the "correct" domain)? I would really prefer for any report to be in some way modifiable from JS because of the vast number of ways folks track sessions/users/A-B tests across. Most crashes i've dealt with in the wild is the result some combination of these variables that have to be traced back. Giving a straight forward way to tie these front end variables back on your backend would be a huge win for devs

[RByers]

Facebook folks (@n8schloss I believe) also said they'd like some way to add their own data to reports. But IIRC they said that it wasn't really a big deal because they already have their own metrics pipeline and server-side data aggregation, so they can always just use a unique reporting endpoint per page load and then correlate all the data on the server.

[igrigorik]

Facebook folks (@n8schloss I believe) also said they'd like some way to add their own data to reports.

My two cents: I think this should be explicitly out of scope. We are not trying to build a new "send an arbitrary request API", there are plenty of great options for that already. The value of this API is in exposing a common mechanism for UA-initiated reports that have well defined structure that everyone can parse and knows what to expect.

But IIRC they said that it wasn't really a big deal because they already have their own metrics pipeline and server-side data aggregation, so they can always just use a unique reporting endpoint per page load and then correlate all the data on the server.

Use cookies?

[juliatuttle]

Cookies aren't sent with report uploads. Per request endpoints won't work; you might need to set them on a dozen origins, and you'd need to remove the previous ones, and it wouldn't work with parallel page loads. What if we assigned reports a uuid? Facebook could correlate the two, but we don't need to let them add their own data to requests.

…

On Tue, Mar 28, 2017, 19:49 Ilya Grigorik ***@***.***> wrote: Facebook folks ***@***.*** <https://github.com/n8schloss> I believe) also said they'd like some way to add their own data to reports. My two cents: I think this should be explicitly out of scope. We are not trying to build a new "send an arbitrary request API", there are plenty of great options for that already. The value of this API is in exposing a common mechanism for UA-initiated reports that have well defined structure that everyone can parse and knows what to expect. But IIRC they said that it wasn't really a big deal because they already have their own metrics pipeline and server-side data aggregation, so they can always just use a unique reporting endpoint per page load and then correlate all the data on the server. Use cookies? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/WICG/reporting/issues/28#issuecomment-289939340>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYojxjiWWlYlq5KSAf6sr6bbBrHxwkXks5rqZxugaJpZM4L0L_E> .

[dcreager]

I think we can close this, because all of the points are being discussed in other issues:

some way to add their own data to reports

#61, #85

Not all report types would necessarily have an event

Different report types define whether they're observable from JS or not

ought to expose those directly to javascript, such that tools can pick them up and beacon them directly

ReportingObserver covers this, I think