Limitations of group-by-origin Execution Mode

[fabricegaignier]

We are currently using the group-by-origin execution mode. However, this mode presents a significant limitation:

• When overwriting an interest group from another joiningOrigin, all interest groups created with the first joiningOrigin are deleted. This behavior is undesirable and constrains our interest group creation policy.

We are planning to increase the number of cross site interest groups. We understand that in this case we should use the ExecutionMode frozen-context, but as explained in the ticket Frozen-Context · Issue #1415 · WICG/turtledove we are facing issues with this mode. So we would like to keep the group-by-origin optimization.

The rationale behind this implementation is unclear, and we do not perceive a concrete privacy threat in relaxing this constraint.
Indeed, once interest groups joined from origin A are re-joined from a different origin B, they would be grouped according to their new origin B and all evaluated in the same execution environment.

Any interest group joined from origin A would be in another group, and thus evaluated in a different execution environment, preventing cross site leackage.

Question:

Could we consider relaxing this constraint to mitigate its impact on our interest group creation policy?

[MattMenke2]

The problem is that leaving interest groups can leak information. Let's suppose I'm an attacker, and there are three publisher origins involved: join.com, bonus_data.com, and auction.com. Normally, in an auction, we restrict a bidder from knowing information from the joining origin (join.com) and the page running an auction (auction.com), and no other top-level origins the user has visited (bonus_data.com). But if interest groups could be left, this breaks.

Example attack: Use visits join.com. He's joined to a "real" interest group that bids, and 32 "spy" interest groups that can share a context and script, but that merely report their presence, which the real interest group looks at. All IGs have group-by-origin set. Interest group scripts are run in priority order, so all the "spy" groups can be given a higher priority than the real one. Then when the user visits bonus_data.com, it can leave/re-join any of the 32 "spy" interest groups, to provide a 32-bit value to the "real" interest group. It can't see the new IGs when running an auction, but it can tell which of the 32 "spy" groups have been left, so could be passed data from bonus_data.com through that side channel.

[fabricegaignier]

Thank you for this explanation. Indeed, using such a method could leak information. However, if we need to create a set of interest groups when visiting a website and only rejoin part of these interest groups when visiting another website, we are left with two possible execution modes:

1. Compatibility, which is not optimized at all since it creates an execution environment per interest group.
2. Frozen-context, which would fit our use case perfectly. However, we have issues using it, as explained in this ticket: Frozen-Context #1415.

[JensenPaul]

I discussed the reason for the limitation you mentioned in this comment. Do you have an example of the use case that would necessitate rejoining only part of a set of interest groups when visiting another website? I should mention that one option is to make interest groups site-specific (e.g. include the current site in the name of the interest groups), that way they will never overlap between sites and you will never run into the limitation you mentioned, but you can still benefit from group-by-origin execution mode when possible.

[fabricegaignier]

Hello Paul,
To provide some context, for "acquisition campaigns" (campaigns targeting a broad audience), we may want to include them in an interest group regardless of the specific website the user visits.
As a result, we might end up creating two interest groups per visit:

1. One with the campaigns related to the website visited (IG1).
2. One with the acquisition campaigns (IG2).

However, the interest group created with the acquisition campaigns (IG2) will be overwritten each time the user visits a new website. We want to avoid having IG1 deleted, of course.

If, instead of creating a single interest group for all acquisition campaigns, we create one per campaign, to be able to link it with negative interest groups as described in this feature request, the group-by-origin option becomes important. However, we cannot use it without impacting IG1.