Privacy concerns regarding Reporting API

[pes10k]

I think this looks very promising, and am grateful for ya'll putting it together! I see a couple of privacy concerning issues though, that I'd like to work through / address:

1. I have the same concerns as @annevk and @johnwilander in Feedback from Mozilla #158. Report life times should be tied to the reporting document (e.g. if I panic and think a page is doing something wacky, I should have confidence that the page looses control when i close the tab, etc.)
2. Will reports be exposed to webExtension APIs, for extension controlled blocking and filtering?
3. Many privacy-preserving resource block on the basis of 1p vs 3p communication. There should be someway of mirroring this information to other decision points (e.g. an extension should see both the destination of the report and the source of it, and be able to say yes / no accordingly)
4. Tying valid endpoints to Origin Policy seems a promising long term option, but in the meantime, the Report API should be limited to eTLD+1 (or similar) endpoints, since some reports (e.g. bodies of CSP violations) can be used to share identifying tokens / track cross origin.
5. What information travels with the report, as described in the standard? Most importantly, I can't tell if cookies should be transmitted (and for vendors that double key storage, or otherwise constrain storage, whats the origin of the request)?

[igrigorik]

Thanks for the feedback, inline..

• I have the same concerns as @annevk and @johnwilander in Feedback from Mozilla #158. Report life times should be tied to the reporting document (e.g. if I panic and think a page is doing something wacky, I should have confidence that the page looses control when i close the tab, etc.)

Since we already have a conversation on this in #158, let's continue this particular discussion there.

• Will reports be exposed to webExtension APIs, for extension controlled blocking and filtering?
• Many privacy-preserving resource block on the basis of 1p vs 3p communication. There should be someway of mirroring this information to other decision points (e.g. an extension should see both the destination of the report and the source of it, and be able to say yes / no accordingly)

Good questions. We don't currently state anything about extension APIs and the challenge here is that there is no — afaik — shared standard or spec for webExtension APIs across different browsers. That said, Reporting relies on Fetch for delivery and my intuition is that if someone was to attempt defining what such an API should be able to see, it ought to be integrated and done at Fetch layer. For reporting requests in particular we set destination=reporting, so one can detect them as such within Fetch.

• Tying valid endpoints to Origin Policy seems a promising long term option, but in the meantime, the Report API should be limited to eTLD+1 (or similar) endpoints, since some reports (e.g. bodies of CSP violations) can be used to share identifying tokens / track cross origin.

I don't follow, how does Origin Policy and the limiting to eTLD+1 endpoints relate to each other?

5. What information travels with the report, as described in the standard? Most importantly, I can't tell if cookies should be transmitted (and for vendors that double key storage, or otherwise constrain storage, whats the origin of the request)?

You can see all the details here: https://w3c.github.io/reporting/#try-delivery. Re, cookies: see #161.

[pes10k]

Good questions. We don't currently state anything about extension APIs and the challenge here is that there is no — afaik — shared standard or spec for webExtension APIs across different browsers. That said, Reporting relies on Fetch for delivery and my intuition is that if someone was to attempt defining what such an API should be able to see, it ought to be integrated and done at Fetch layer. For reporting requests in particular we set destination=reporting, so one can detect them as such within Fetch.

This is all very helpful, thank you @igrigorik . Another key diff here is that since messages are sent in POST, most blocking tools (especially post manifest v3) will loose the ability to reason about these. What about a destination=reporting:csp, destination=reporting:nel, etc designation, and making sure that this info is available to blocking tools too.

Tying valid endpoints to Origin Policy seems a promising long term option, but in the meantime, the Report API should be limited to eTLD+1 (or similar) endpoints, since some reports (e.g. bodies of CSP violations) can be used to share identifying tokens / track cross origin.

I don't follow, how does Origin Policy and the limiting to eTLD+1 endpoints relate to each other?

Apologies, thats me being a dummy. I didn't mean origin policy, I meant something like https://mikewest.github.io/first-party-sets/ . No excuses on my end for the error, I don't know what I was thinking :)

[yoavweiss]

This is all very helpful, thank you @igrigorik . Another key diff here is that since messages are sent in POST, most blocking tools (especially post manifest v3) will loose the ability to reason about these. What about a destination=reporting:csp, destination=reporting:nel, etc designation, and making sure that this info is available to blocking tools too.

I don't know if Fetch would be thrilled to introduce the concept of "sub-destinations".
@annevk - thoughts?

Regarding availability of destination to extensions, see above :)

Apologies, thats me being a dummy. I didn't mean origin policy, I meant something like https://mikewest.github.io/first-party-sets/ . No excuses on my end for the error, I don't know what I was thinking :)

Can you describe the information leak scenario you're concerned with in a bit more detail?

[pes10k]

Regarding availability of destination to extensions, see above :)

I see in the above that "its not specified anywhere" currently, which isn't ideal, but at the very least, it would be useful to know what the plans are for major implementors, to reason through the privacy implications of Reporting API vs <img> or similar.

Can you describe the information leak scenario you're concerned with in a bit more detail?

Since Reporting API would give privacy / blocking tools less info to work with (or at least that seems like a possibility), and potentially open up new types of privacy sensitive info (e.g. nel) it would be ideal to balance this loss by restricting / preventing cross domain communication.

E.g. prevent (or at least slow) the creation of a 3p "track users through network information" service, or the translation of existing tracking services to Reporting API endpoints.

(I dont know if i've answered your question, happy to take another pass at if if not…)

[igrigorik]

I meant something like https://mikewest.github.io/first-party-sets/

Ah, hmm.. worth exploring. Off the top of my head, a few caveats:

• AFAIK, it's not yet available in any implementation and I'm not clear on overall status?
• We do know that many sites rely on specialized services (e.g. https://report-uri.com) that help them process, aggregate, and get various from reports. If the above is adopted, existing policies for such services would be broken, and deploying new policies becomes challenging.
  • In theory, such provider could be added to the set? But the provider would need to mirror and enumerate all of their clients in their own set as well, which creates an issues on its own, plus I don't think we want to see sets with large numbers of sites?
  • Alternatively, sites would have to switch to CNAME'ing such providers? But I'm not sure if that's a net win relative what we have today.

[clelland]

That doc seems to have moved; it's at https://github.com/krgovind/first-party-sets now.

It would be difficult for a reporting service provider to use that, though. It doesn't seem to be possible for an origin to be in more than one set, for one. The provider could try to own a single set containing all of its clients, but there is also a limit suggested of 20-30 origins per set, and it would also tie each of the clients to the others as part of the same set.

CNAMEs would allow a provider to get around that (either at the provider or client DNS), but as @igrigorik says, I don't know if we want to encourage (or require) that as a way around this.

[dcreager]

Reporting uploads are subject to CORS checks (comparing the origin of the report and the collector), so the user agent will have to send out a preflight request for 3p report uploads before POSTing the actual report content. Does that give us what we need for this?

[clelland]

I think that CORS is sufficient for (3), and I hope mitigates (4) -- with CORS indicating cooperation between the site and the endpoint. Tying it to domain name will just force people into CNAME tricks, without improving anything substantially.

For (1), I raised a proposal at TPAC to tie reports and reporting configuration for Crash, CSP, Deprecation, Feature Policy and Intervention reports to document lifetime. Network Error Logging and similar out-of-document reports have different requirements, but the plan is to start a separate document to standardize their behaviour.

I think @igrigorik and @yoavweiss covered (2) and (5)

[pes10k]

Re (1), that sounds great. Tying to document life time would be a strong improvement

Re (3) and (4), I don't think CORS addresses the concern, which is generally about restricting where this information can travel to a set of parties the user can reason about (since all this functionality involves the site riding on the user, to help the site owner achieve the site-owners' goals and responsibilities).

We discussed briefly at TPAC PING the idea that sites would need to explicitly request the user's permission to use reporting API (e.g. "would you like to submit diagnostics info to {sites,urls} X,Y and Z to help improve the site?"). That would of course mitigate this concern.

[yoavweiss]

We discussed briefly at TPAC PING the idea that sites would need to explicitly request the user's permission to use reporting API (e.g. "would you like to submit diagnostics info to {sites,urls} X,Y and Z to help improve the site?"). That would of course mitigate this concern.

Any particular reason why reporting requests are different from other cross-origin requests when it comes to user expectations? Are there implementations that are considering gating cross-origin requests behind a permission?

/cc @jyasskin @bslassey

[annevk]

I would also like to learn more about the threat model, in particular how it pertains to reporting that is scoped to document(s).

[pes10k]

1. some of the types of information i the Reporting API spec do not have non-Reporting API analogues (intervention, crash, etc). Doubly true for the types of information used in examples in Reporting API (e.g. nel)
2. Re user expectations: im sure most users have no real sense of whats going on behind the scenes, and so no specific "expectations" at all. But they do expect their browser to be their agent, helping them do things they want to do, for their benefit. All (or nearly all, if you're willing we are to conflate website interests with user interests) the use cases for Reporting API do not help the user accomplish the user's first order goals on the website.

So its not a "threat model" question, it's whether its appropriate to for the site to treat the user as the site's debugging agent w/o the user's consent, and especially when some of that debugging activity may be harmful to user interest / privacy (re: intervention, nel, etc)

[annevk]

Thanks, that's helpful.