Enforcement against formation of large sets

[krgovind]

To aid user understanding, and prevent abuse, it is desirable to prevent the formation of excessively large sets. What are some ways to prevent or disincentivize formation of large sets?

• Technical limit on the size of a set: Is there a reasonable limit we can place on the number of domains in a set?
  • ccTLD variants can number in the 100s. Should those be discounted against the limit?
• Storage limits: Could we apply counterpressure against formation of large sets by applying storage limits per set, instead of per domain?
• Entropy limits: Could we apply counterpressure against formation of large sets by applying entropy limits (e.g. Privacy Budget ) will be applied per set, instead of per domain. Can these be an effective counterpressure?
• Other ideas?

[bslassey]

Since there will be communication within a set, Privacy Budget limits will have to apply to the entire set. Whether or not that is effective counterpressure to forming large sets can reasonably debated of course.

[krgovind]

Since there will be communication within a set, Privacy Budget limits will have to apply to the entire set. Whether or not that is effective counterpressure to forming large sets can reasonably debated of course.

Indeed. Edited the original post to reflect this.

[hpsin]

@krgovind the size of the allowed set is of significant interest to established corporations like Microsoft, who have ~300 domains in use for our applications that we'd need to put in a single set. Is there a plan to place a hard upper limit on the set size? Happy to open this as a separate issue.

[othermaciej]

Hundreds of domains in a set has clear abuse potential. There should be some sort of limit.

[hpsin]

Agreed - there will always be tension with forcing changes and improving privacy. We can pick winners amongst our apps if need be. Understanding if the limit is 3 (non-starter for us, 3 barely covers our login pages) or 20, or 50, is a good starting point that we can use to drive domain convergence.

[krgovind]

@hpsin: Could you elaborate on whether all ~300 domains would need to be in the same set?

• Do they all need access to the same user identity within a given browsing session?
• Do some of them serve as utility domains that could make use of partitioned state? For instance, Firefox is doing this in ETP strict mode.

Note that a single organization would have the ability to form multiple sets. For instance you could divide up your domains based on how users interact across them.

[hpsin]

Generally yes - they are all "top level" products that a user would interact with and expect to see SSO between them. We could look at reducing this to perhaps 100 domains once we strip out CDNs, back-end sites, sites that don't require cookie auth, etc - at which point it does not accurately capture the set of domains we own. No matter how we divide up the domains, all of them overlap on our login domain (thus breaking the "one set per domain" rule).

We could use (and plan to use) partitioning for some domains (think the spellcheck plugin for a word processor) with some significant updates to the auth model, which may reduce our count down to 75.

[johannhof]

I think this was solved through the subsets design and particularly limiting the number of "associated" subset members. There's still an open question whether the new design is able to solve all use cases properly (#96) but for now I'd say that in general the design is effective in preventing (non-contextual) large set formation.