Leave all IGs for a given domain

[gianni-99]

Introduction

The current implementation of FLEDGE does not allow for easy management of IGs on devices. For example, there is no way to know if an IG is present or garbage collected. To make sure that the server side is mostly in sync with the client side we propose to have an API extension to delete all IGs on the device for the current domain with an exception list of IGs we would like to keep.
The scenario is that, at IG registration time on an advertiser website, we plan to delete all IGs on the device that are not part of the current profile. Subsequently, we plan to issue a join request for the IGs based on the new state of the profile. For publisher origin IGs we might not need to clear the IGs.

Motivation

The functionality would help in two ways:

• It resets the state of the device IGs making sure that the state is in sync with the server.
• We can avoid keeping track of the IGs server side and rely on a clean slate at registration time.

Design / Proposal

We propose to extend the Fledge API to allow for the following at IG registration time on advertiser website

...
owner = 'https://www.example-dsp.com/';
listOfIGNamesToKeep = ['womens-running-shoes', 'mens-running-shoes’];
leaveAllAdInterestGroups(owner, listOfIGNamesToKeep);
...
<continue with the registration of new IGs>

Where the function leaveAllAdInterestGroups removes all the interest groups from the current origin domain and owner not matching a name in the listOfIGNamesToKeep.

Implementation

This function can be cloned and remove the execution_mode restriction with a listOfNamesToKeep of IG names and made publicly available to be called just before the joinIG calls. Specifically we can add a lookup into a keep_list in this for loop.

while (same_cluster_groups.Step()) {
  if (!DoRemoveInterestGroup(db, blink::InterestGroupKey(owner,same_cluster_groups.ColumnString(0))))

Alternative

At a first glance also a call to this function followed by an iteration of calls to this function should be sufficient to support the functionality (while skipping IGs in listOfIGNamesToKeep).

[JensenPaul]

When you say "for a given domain", do you mean interest group owner domain and/or the site on which 'joinAdInterestGroup()' was called?

[gianni-99]

That would be the origin of the interest group (the domain from where the joinAdInterestGroup is called).

[MattMenke2]

That would be the origin of the interest group (the domain from where the joinAdInterestGroup is called).

This line confuses me - the origin of the top-level page where IGs are joined from and the IG owner origin are not necessarily the same. What behavior specifically are you proposing here? Only leaving all IGs from the owner origin joined from the current top-level origin (which would be an entirely novel behavior, not at all like what leaveAdInterestGroup() does), or leaving all IGs from the owner, regardless of what top-level origin they were joined from?

I think that if leaveAllAdInterestGroups() were restricted to IGs learned on the current top-level-origin, while leaveAdInterestGroup() was not, there'd be a lot of developer confusion about the very different behaviors of the two methods.

[gianni-99]

The functionality I would like to get implemented can be described with a user interaction:

• User goes to well-known-advertiser.com/catalog/very-well-known-product.html
  • User gets added to IG1, IG2, IG3 with joining_origin set to well-known-advertiser.com
• User navigates to well-known-competitor.com/catalog/very-well-known-alternative-product.html
  • User gets added to IGa, IGb with joining_origin set to well-known-competitor.com
• User returns to the 1st site to see an accessory well-known-advertiser.com/catalog/very-well-known-accessory.html
  • Server side we decide that the user should be in IG3 and IG4 and leave IG1,IG2

The new functionality would be used as follows in our script:

...
leaveAllAdInterestGroups(owner, [“IG3”]);
JoinAdInterestGroup(IG3);
JoinAdInterestGroup(IG4);
...

At the end of this interaction I would expect the user to have 2 joining_origin each with 2 igs: {well-known-advertiser.com:[IG3, IG4], well-known-competitor.com: [IGa, IGb]}.

This is similar to the behavior that I understand is implemented when an interest group with execution_mode=groupByOrigin where all the IGs for that joining_origin are removed when a user joins the same IG cross domain.
This new function would do the same on demand with a “keep list”.

[MattMenke2]

That's how the execution_mode=groupByOrigin case currently works, actually. If join 5 IGs on site A with execution_mode=groupByOrigin, 3 with some other execution_mode, and then on site B join 1 IG with execution_mode=groupByOrigin, and then leave one of the first 5 IGs from site C, all 5 IGs with that execution mode joined from site A will be left, and the 4 other IGs will remain. If it were left on site A instead, we'd just leave the single IG.

So this behavior sounds like it would be entirely different from how leaveAdIG() works with groupByOrigin mode.

[JensenPaul]

Since the behavior diverges from that of leaveAdInterestGroup() perhaps we should name this new API in a way that indicates this different behavior to prevent developer confusion. Since it sounds like the use case here mostly relates to clearing or resetting the state of IGs from (or joined on) this origin, perhaps a name like clearOriginAdInterestGroups() or clearOriginJoinedAdInterestGroups()?

[MattMenke2]

Another option would be to make take a parameter to either behave like leaveAdInterestGroup, or in a new manner (Then leaveAdInterestGroup could also be updated to take the same parameter, with a comparable effect).

[MattMenke2]

I've written a short PR (#829) with the proposed change. Went with clearOriginJoinedAdInterestGroups(). If there's demand for a global variant, we can just call it clearAdInterestGroups().

[gianni-99]

Thanks for the PR, it looks good to me. As for the global version, I did not think about what we could use it for yet.