I've revised my position on this. I tend to think that - at least for an interim state - this might need to be bound to the browser profile.

Browser profiles fill a couple of needs. I know that some people use them to separate different activities, like their personal and business activities. But they are also used on a shared machine to support different people using the same machine.

That latter case is seeing less use though as operating systems get better user profile support, so I'm not too concerned about that from a utility perspective. The effect is that we get householding, where attribution works for the set of users that share the machine as though they were a single person; such things might need to be considered in modeling that uses the outputs of the system.

From a privacy perspective, this is a little less easy to justify. I think that there are certain expectations associated with creating separate profiles that this might not fit with. Though it seems odd that we might allow transfer of information from an app to a browser as operated by the same person, why would we not allow transfer between contexts in the same browser? The problem is that profiles are explicitly used to keep certain activities isolated from others, so having IPA violate that is counter to expectations.

Profiles are not that widely used (I don't have great numbers at hand, but somewhere between 75% and 95% of Firefox users on Windows have just one profile). The utility loss of breaking things up this way is hard to get excited about.

The OS integration story is gets complicated there though. If there are multiple profiles, but an OS-level match key, which of those profiles uses the OS store? My initial thought is that a profile would latch onto the OS-level API if no other active profile has taken it. Then, for most people, their "main" profile is where they get good attribution, but they can use profiles to get the privacy properties they expect (maybe with an option to re-enable manually, just as you would be able to disable manually).

That approach has a flaw though. Some people use different browsers to segregate their activities. If browsers all independently manage the latching, those people might be surprised to learn that there is something connecting those contexts.

My initial thought is that a profile would latch onto the OS-level API if no other active profile has taken it. Then, for most people, their "main" profile is where they get good attribution, but they can use profiles to get the privacy properties they expect (maybe with an option to re-enable manually, just as you would be able to disable manually).

This weird though right? Only the primary profile gets app<->web attribution and everything else is stuck in web<->web by default? The inconsistency doesn't make much sense, and "first come first serve" is a design smell.

I agree that sticking for now with per-profile match keys is the safer bet and aligns with existing expectations. We can spend more time thinking holistically about how app<->web could work here but I definitely think it needs more thought.

I'm not saying that I love it FCFS, but I don't know how to preserve the use of profiles as a privacy tool otherwise.

This would actually be easier to reason about if there were a “setMatchKey()” API!

In the case of two different people using the same device, we could expect that they’d sign into a Match Key Provider app/site with separate logins, and have separate storage. So a per-profile approach would work quite nicely.

I agree with you @benjaminsavage 😄 even more reason to figure out how to fix this unfortunate privacy bug in #57.

This would actually be easier to reason about if there were a “setMatchKey()” API!

In the case of two different people using the same device, we could expect that they’d sign into a Match Key Provider app/site with separate logins, and have separate storage. So a per-profile approach would work quite nicely.

Wouldn't it make it more complicated since if two users with different log-ins on a source site use the same browser profile, which match key would you use on a trigger site? Would you get two trigger events, one for each match key at the cost of double attribution? How was it done with third party cookies?

Wouldn't it make it more complicated since if two users with different log-ins on a source site use the same browser profile, which match key would you use on a trigger site? Would you get two trigger events, one for each match key at the cost of double attribution? How was it done with third party cookies?

I think with 3PC when you log out and log back in your 3PC will be replaced with the one for the new user. This would be equivalent to resetting the match key. I think in the privacy analysis to prevent malicious MKPs we disallowed this for IPA but in theory it could be supported if we could get the privacy right.

Agreed that sharing state for an attribution use-case across profiles (which are explicitly used for managing different identities) would be pretty strange. On a related note: have we noted down somewhere what getEncryptedMatchKey() will return in private browsing? (I'm guessing undefined based on this issue's description)

On a related note: have we noted down somewhere what getEncryptedMatchKey() will return in private browsing? (I'm guessing undefined based on this issue's description)

When people are opted out, getEncryptedMatchKey() will generate a random match key every time it is called. Since the match key is long, it is sufficiently unlikely that it will collide with other match keys.