Resetting every 30 days overly restrictive?

[jkarlin]

In an effort to reduce the scope of joining user ids across sites, Shared Storage will delete an origin's contents 30 days after the first entry is written. This is perhaps overly restrictive, and prohibitive, for our users. For one, outside of the worklet, the caller has no idea how long the data will persist. It may be day 29, and writing a new key on the 29th day will result in it being deleted the next day. But also, there are use cases (such as reach) that will need to extend beyond 30 days.

An alternative proposal is to reduce the scope of joining user ids across sites without further interaction with the origin. This brings it closer to what FLEDGE is doing. That is, if a FLEDGE interest group already exists, and is written to again, its expiration time is reset. We could do the same thing with Shared Storage. If a key is written to (or would be written to if it didn't already exist), its timestamp is reset. This ensures that keys persist for at least 30 days, and can be extended longer so long as the origin sees the user again and updates the value.

Thoughts welcome.

[jkarlin]

Closing as this issue is a duplicate.