Editorial: Recommendation for list update interval

[johannhof]

The spec draft currently says a user agent might update every 2 weeks but makes no recommendation. Should we have one?

cc @helenyc

[johannhof]

See #120

[miketaylr]

Is a once-per-major-release cadence sufficient?

[krgovind]

Is a once-per-major-release cadence sufficient?

@miketaylr Asking as a newbie to web specifications - are release cadences deterministic/specifiable? I wonder if specifying as a time interval (e.g. 2 weeks) is more appropriate, since it offers some amount of predictability to site authors?

To answer your question more generally, since FPS is intended as a mechanism to address use-cases impacted by third-party cookie deprecation; we anticipate that leading up to (and perhaps even during) the 3p cookie phase-out in Chrome, many websites may choose to adopt FPS to ensure continued site functioning. We think that at least during this adoption period, the cadence should be more frequent (as Johann mentioned, we are proposing a 2-week cadence here). It is possible that we could lower this cadence over time as set submissions slow down.

[dopry]

As a web developer and sysadmin who is considering this functionality. I would like to be able to from any domain I control, declare my first party set and set the caching and expiration rules. I don't see the point in a central repository controlled by a 3rd party and infrequently updated. The web is a distributed platform. This kind of centralization seems like a huge step in the wrong direction vs more traditional approaches such as headers issued from a webserver and verified by an ssl certificate.

[miketaylr]

@krgovind (oops, I totally missed your response!)

Asking as a newbie to web specifications - are release cadences deterministic/specifiable? I wonder if specifying as a time interval (e.g. 2 weeks) is more appropriate, since it offers some amount of predictability to site authors?

You can specify it, yes, but like you mention it's not as predictable as a set time interval. I would assume all UAs have some ability to update certain components outside of the major release cycle at this point (whether via out-of-band "system component" updates, or minor/dot releases). You could also give a range, aka "no fewer than every two weeks and no more than every major version". Lots of options. :)

(We could do a little bit more work to properly define "major version", it's referenced in https://compat.spec.whatwg.org/#ua-string-token-reference, and https://wicg.github.io/ua-client-hints/ - simple enough).

[krgovind]

As a web developer and sysadmin who is considering this functionality. I would like to be able to from any domain I control, declare my first party set and set the caching and expiration rules. I don't see the point in a central repository controlled by a 3rd party and infrequently updated. The web is a distributed platform. This kind of centralization seems like a huge step in the wrong direction vs more traditional approaches such as headers issued from a webserver and verified by an ssl certificate.

@dopry Thanks for the feedback. Indeed, using a central repository was not our first attempt at designing this. See "Signed Assertion and Set Discovery instead of static lists", and "Using EV Certificate information for dynamic verification of sets" for details on why we settled on the current static list approach. There is also an idea for an auto-compiled list being proposed in #128 which we are keeping in consideration for future development, but I'm not sure if that would address your concerns.

Note: What we explored was having the set primary and members serve a manifest file listing either (a) the sites within a set/group, in case of the primary domain; or (b) simply point to the primary, in case of a member domain. This is more ergonomic and efficient than headers, since:

• We expect set membership to be relatively static, and not changing within the context of the HTTP response. It's important that sets not be personalized per user, and be easily discoverable/observable for accountability, since privacy outcomes are tied to set membership.
• The size of a set can be large, so it doesn't seem prudent to specify it in a response header. Even though we enforce numeric limits on the "associated subset", there is currently no numeric limit on the ccTLD and service subset. Additionally, any limits can only be enforced at the time that browser consumes the list, but doesn't prevent a site from sending a very large list in an HTTP header.

If you have any additional feedback on this topic, I would recommend opening a new issue, so it's not lost in this very narrowly focused PR (which is likely to get closed at some point).