Validate cookie domain against public suffixes?

[tmenier]

The latest RFC describing cookies (6265) concedes that effectively preventing "supercookies" from being set at too high of a domain level (.com, .co.uk, etc.) can't be done via simple dot-counting algorithms and requires validating against an actual list of public suffixes. In addition to com, co.uk, etc, this list includes things like blogspot.com (and about 9000 others). Validation would ensure that my.blogspot.com can't set a cookie for your.blogspot.com by sending Domain=blogspot.com in the Set-Cookie header. In other words, our blogs should be treated as independent "sites" from a privacy perspective.

The official(est) list of public suffixes is maintained here. Flurl could use this list to validate, but it's too big to simply embed in the library. It could fetch the list via an HTTP call and/or allow specifying a local file cache.

Is Flurl obligated to do this validation?

No. Most any HTTP client library (including .NET's HttpClient) gives you the ability to set whatever request headers you want and ultimately can't prevent the programmer from doing something malicious. In other words, absolutely enforcing security/privacy rules is outside the scope of the library. So just to be clear, this would be an opt-in feature, not something required by any standard or spec.