Consider annotating getMatchKey calls with an event type

[csharrison]

We should consider asking callers to annotate calls to getMatchKey with a type, e.g. source or trigger. This clarifies the use of the API and can help drive UX and UA-specific policy that might deviate across event types (e.g. permission prompts, user gesture gating, etc).

This may also end up being useful if we need to cap the sensitivity of the # of source and trigger events from the client, e.g. to support something like patcg/meetings#97, where the sensitivity of sources and triggers are different.

Note: we may want to have more specific types beyond source / trigger e.g. click, view, ghost-view to more clearly specify the intended event type.

[martinthomson]

I think that this is the right thing to do.

One thing that we've been debating on and off is whether we can bind each encrypted match key to the counter-party. That is, if you are generating a source encryption, you would provide the origin (really: site) of the expected trigger site. It's a little awkward for trigger events, as you can't know at the time where the source event might be, but the set of source sites should be finite. Asking for multiple encryptions is totally feasible and it doesn't represent much of a storage commitment to retain the ciphertext.

The catch here is that we would need to make the API take a flag that indicates whether each input is a source or trigger event. If the helpers don't know the type of event, they can't decrypt them. Our current implementation takes this input as a secret share. Obviously, once we get to sorting, this will need to be secret shared, but the helpers can trivially turn that into secret shares.

I'm less sure about the distinction between click/view/ghost. Are you thinking that you might like to either account for these differently in some way or provide some functionality? Who would this information be made available to?

[csharrison]

I'm less sure about the distinction between click/view/ghost. Are you thinking that you might like to either account for these differently in some way or provide some functionality? Who would this information be made available to?

I'm also not 100% sure about those, mostly just mentioned for completeness (and to highlight that we may want the field to be extensible). Here are a few idle ideas I had:

• Drive some in-page UX like the existing cookie viewer in Chrome ("the following sites obtained match keys on this page for these event types...")
• Have more sophisticated API gating (e.g. click events could be gated by a user gesture)
• Have different bounds for different types (e.g. click events are naturally rate limited by the above but maybe we'd set a limit on the # of views per page load or something)
• If the types are embedded in the encrypted payload, you could have different helper policy for different events (e.g. more noise required on events that don't have some browser verification like clicks might)

None of these ideas are fully thought out, but I wanted to start the conversation and at least see if we can make the API surface compatible with the general idea of annotating some metadata about what type of event is being emitted.

[bmcase]

We should consider asking callers to annotate calls to getMatchKey with a type, e.g. source or trigger.

Been thinking more about this recently, and I agree we should do this and let it be part of the authenticated associated data returned with the encrypted matchkey. I think if we don't do this there isn't a good way to enforce that a source-fan-out query only contains source events from the site which is submitting the query, since if source/trigger bit were encrypted the source site submitting the query could include source events from other source sites disguised as trigger reports.