search

WICG / turtledove

TURTLEDOVE
https://wicg.github.io/turtledove/
Other
533 stars 236 forks source link

Patch'y Updates for IGs Previously Joined on Same Joining Origin, i.e. interest_groups.joining_origin=origin of current TLD #1162

Open thegreatfatzby opened 6 months ago

thegreatfatzby commented 6 months ago

Problem

We end up with a fun little riddle to solve w/r/t IG updates, that has come up twice in conversations over the last week, once internally with our DSP folks and once with another company:

NO NOT HOORAY! All of the ads, logic, etc, are wiped out. The IG cannot even participate in the auction anymore as it won't be invited due to no bidding signals and ads. Much debugging sadness ensues, foreheads are palmed, etc.

In the case of delegation this seems likely to happen a lot; even in the case of a DSP dropping their own IG it seems not unlikely the DSP might use the pattern of "drop the IG, let it trigger the update with the new tech that lets the updates trigger a lot, and then just let the server provide the configurations".

Rough Proposal

I think the following things would help, in decreasing order of my level of confidence in their privacy safety'ness:

When on the same origin as the JoiningOrigin of the IG (which is tracked internally and not available as part of the API, interest_groups.joining_origin I think) tech on page should be able to...

  1. Extend the TTL of the IG identified by (owner, name), without wiping out any other fields.
  2. Do a PATCH'y update of fields on an IG identified by (owner, name), i.e. not wiping out any other fields.
  3. Extend the TTL of all IGs that were previously joined on this JoiningOrigin for a given owner.
  4. Extend the TTL of all IGs that were previously joined by the given tech provided on that page.
  5. Extend the TTL of all IGs that were previously joined on this domain at all.

Some Details

(1) I think should be OK, and I'd thiiiink (2) as well. Things can get a bit more complicated, privacy and domain wise, for 3-5, but the value would be making it easier for a DSP/DMP doing more semantic things to be able to apply a broad brush to a class of things.

(5) seemed a bit odd to me at first but would potentially be of interest to the site owner (generally advertiser) I think, as opposed to the ad tech (although they'd benefit from it obvs). I guess allowing a specific tech to do this could be interesting, but if the call came from JS on the top level, i.e. we "know" it's the advertisers choice, maybe that's ok? You could see this getting tricky, b/c some IGs will be simply "opportunity to bid at all" indicators, but others will have semantic meaning that will expire eventually, and the advertiser likely wouldn't know the difference. I guess that could be solved with an additional IG field...maybe?

(3) I don't think is currently possible as I don't see a field in interest_groups tracking the "tech" that created it, and I can see that maybe being tricky, my Chromium internals knowledge isn't enough to say how that could work if you're not in an iframe...but that would seem valuable for me as a tech...maybe the same "additional IG field" mentioned above could help here?

dmdabbs commented 6 months ago

...the DSP might use the pattern of "drop the IG, let it trigger the update with the new tech that lets the updates trigger a lot, and then just let the server provide the configurations".

Is tech that lets the updates trigger a lot referring to updateIfOlderThanMs?

thegreatfatzby commented 6 months ago

Right.

dmdabbs commented 6 months ago

DSPs whose "inserts" start with an empty, eligible-but-not-biddable IG will have to wait until after the first post-auction update to use updateIfOlderThanMs. In the sunny, scaled PAAPI future that wait might not be very long. But, yeah, 'overwriting' the twenty-day-mature IG with the empty "insert" might mean waiting up to 24 hours for that next, restorative update.

  1. Extend the TTL of the IG identified by (owner, name), without wiping out any other fields.

Perhaps an approach to # 1 is to, say, include updateIfOlderThanMs in the "insert." If it is present, and the IG already exists, then the other IG attributes are ignored and you get an update, not just leaving the IG undisturbed.

In any event, this new mechanism would still increment the internal join count and recency, yes?

  1. Do a PATCH'y update of fields on an IG identified by (owner, name), i.e. not wiping out any other fields.

If the DSP is using empty "inserts" would it have any patchable values?

davideanastasia commented 6 months ago

My understanding is that updateIfOlderThanMs will trigger a fetch from the update URL, but the update URL cannot extend the TTL of the interest groups, hence 20 days into the life of the interest group, despite the refresh of its content, the IG will only live further 10 days. Am I understanding this incorrectly?

dmdabbs commented 6 months ago

Am I understanding this incorrectly?

You are not, Davide. My response was poorly worded. Implicit was an assumption that the new API surface/flag that will enable @thegreatfatzby's #1 will be updating the lifetimeMs expiry. I was wondering whether we could also get a shot at triggering the updateURL.

thegreatfatzby commented 6 months ago

That would seem a good option...I did put this on the list for coming Wednesday, maybe we'll get to it.

dmdabbs commented 6 months ago

Hmm. I forgot updateAdInterestGroups() exists (prolly why I asked for it to be added to the explainer). Paul J's PR today brought it to mind.

thegreatfatzby commented 6 months ago

That's not permanent, at least as of yet, right?

dmdabbs commented 6 months ago

That's not permanent, at least as of yet, right?

I've not seen any references that it is temporary. It is in the spec.

thegreatfatzby commented 6 months ago

Interesting, I was referring to this but maybe I've overinterpreted that as being temporary.

dmdabbs commented 6 months ago

If it were temporary they probably would not have patched the explainer or would have noted it.

JensenPaul commented 5 months ago

I suspect there is some possible improvement we could make to address this issue. One concern is how we avoid IGs containing information from multiple sites. For example if you join an IG on site A, then join (and overwrite) the IG on site B, then go back to site A and try to do a partial IG update, e.g. try to extend the IG's TTL. We discussed a similar risk in this comment and the group-by-origin optimization. The outcome in those two previous instances was to delete the IG (and in the case of group-by-origin, all other group-by-origin IGs joined on that site) if it was accessed on two different sites. Do you think this is a reasonable outcome here?