Open thegreatfatzby opened 9 months ago
The lifetimeMs
property of the Interest Group is the new and suggested way to do things. It's a good match for other web standards, which use milliseconds instead of seconds for basically everything else where you specify some duration in the browser.
The old second-argument-in-seconds technique will be supported for a while as a fallback, for backwards compatibility.
The behavior if you call Join a second time is just like it was before: it sets the lifetime of the IG to whatever you say it should be, overwriting whatever the previous expiration was. In this way you can keep extending the lifetime of an IG until 30 days after the person most recently visited the site where you're invoking the Join operation.
Thanks @michaelkleber that makes sense, can I just confirm the behavior of how this works when lifetimeMs
is returned in the response from a call to updateUrl
:
lifetimeMs
returned via updateUrl
be relative to t = lastVisit
or t = timeOfUpdate
? I.e. if the original lifetimeMs=5Days, and on day lastVisit + 4 your updateUrl
returns lifetimeMs=10Days, will that cause it to go to lastVisit + 10Days
or lastVisit + 14Days
?Updates ignore the lifetimeMs field, so they can't extend (or shorten) the lifetime of an interest group. Not allowing extending the field is a deliberate behavior, to avoid an interest group to be persisted indefinitely from a single site visit. Only a script on a page the user visits can extend the lifetime of an IG.
Hello fwends, I was commenting on one of our PRs internally which led to a conversation about how to tell the call to joinAdInterestGroup what the lifetime is. I now see that the Github doc lists lifetimeMs as being one of the properties of the object passed to the call, rather than the second argument; I also see this in the full spec. However we found that the old method seems supported based on both this doc and experiments.
So QQs: