Restrictions on match key providers

[csharrison]

Given that match key providers have great power in the IPA proposal to do cross-device attribution and to match web events with arbitrary off-web events that can be linked to a given match key, we should consider possible mitigations to limit the harm here. I want to discuss two possible mitigations, but I’m open to more:

1. permission prompt for setMatchKey

   The UA can show a permission prompt in front of the user when setMatchKey is invoked. While we're mindful that the UX would need to be constructed in a user-understandable way, it would mitigate this issue, especially if the prompt mentioned possible linking with off-web or cross-device activities.

2. UA-allowlist for match key providers

   The UA can maintain an allowlist of match key providers, and anyone not on the list that tries to call setMatchKey will fail. This opens up the possibility of match key providers needing to abide by certain UA policies / guidelines to be allowed to set match keys. A policy layer is useful because IPA has no mechanism for technical enforcement of event provenance.

   Of course, this has downsides in that it opens up interoperability concerns if different UAs have different policies / allow lists of providers. It also makes the API less “open” in that it limits which entities can use the most powerful features. Still, something like this might be needed for some UAs to consider the proposal with setMatchKey “safe enough” for shipping.

[benjaminsavage]

Thanks for filing this issue @csharrison and starting this discussion.

we should consider possible mitigations to limit the harm here

The word "harm" is a pretty strong choice. The section of the document you linked to uses more neutral language about unbounded scope, inability to determine provenance, and contemplates what incentives this might create.

If you believe this could lead to "harm", could you outline that? What (more precisely) are the potential "harms" you're concerned about?

[csharrison]

Sorry, that should probably read as "possible harm", I didn't mean for extreme language and I don't consider this feature of IPA generally harmful, just that there's a possibility for misuse.

The primary thing I was concerned about here is the "unknown provenance" factor. e.g. the user's browsing activity being used to join up with data that users would not be comfortable sharing, possibly coming from data sources without robust user controls, sources which are considered "creepy" to users, etc.

Each individual platform that uses IPA can have controls and safeguards to make sure that their inputs to IPA are respectful of the user, but it's harder to make that guarantee about the joined data. I'd be nervous about an end state where "respectful" IPA inputs prop up an ecosystem of less respectful IPA inputs.

In the end, the difference mainly depends on the trustworthiness of the match key provider, hence my two suggestions about mitigation (does the user trust the provider, does the UA trust the provider).

[npdoty]

As a special case of this request: could we document a mode, and the implications of that mode, where the match key is provided by the browser instance?

This seems like the fallback in a couple of instances, but also seems quite useful on its own. It provides cross-origin attribution of events. Browser syncing could allow for attribution across devices when the user has chosen to sync their activity across devices. Users can reset the key at any time, and not have it respawned by a match key provider that they log into or provide PII to. It doesn't allow for insertion of offline events that the user would not have visibility over.

[csharrison]

@npdoty I think this is an interesting idea, and possibly fits into the framework of "UA-allowlist for match key providers" with the platform itself as one (possibly the only) trusted provider. Of course, it does unfortunately remove the "I" in "IPA" as we will no longer be able to join events across browsers/platforms unless those browsers/platforms share an ID.

[benjaminsavage]

I think I need to link to an issue we recently filed: #57

The TL;DR is that there is a potential attack that a malicious match key provider could mount - and we need some time to come up with a good mitigation.

In the meantime - as @npdoty has suggested - one can imagine a simpler system where devices simply generate a random match-key, which is never shared with ANY entity, but which could be synched across multiple devices via some vendor specific model (e.g. if my iPhone and my MacBook are both signed into iCloud they could share a consistent, randomly generated number).

While this is not as interoperable as I would ideally like to see (and we will continue to work on this problem), it could still be quite useful, and has a simpler threat model.