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).

Originally posted by @krgovind in #122 (comment)