Adding quipelements.com domain for Quip.

[plinehan]

This domain is used to host customer applications on individual subdomains. We would like to prevent these applications from storing cookies both within their own subdomain and on the root domain.

[plinehan]

Please find that our DNS records have been updated:
dig TXT _psl.quipelements.com

[weppos]

@plinehan can you provide some examples of domains? According to what you said, you probably misinterpreted the rule.

You should probably have quipelements.com, not *.quipelements.com

[plinehan]

Absolutely, thanks for the followup!

For content served from this domain:

element-a.quipelements.com

We would like to prevent cookies being set on both of these domains:

quipelements.com
element-a.quipelements.com

This follows for any like-named domains, e.g. element-b.quipelements.com.

No content will ever be served directly from quipelements.com or from deeper subdomains, e.g. foo.element-a.quipelements.com. Our SSL cert doesn't even apply to these domain names.

Based on my original reading of the spec I thought I wanted two rules:

quipelements.com
*.quipelements.com

but make test reported that as a redundant error.

Thanks for any help you can offer!

[plinehan]

Hi @weppos if what I'm asking for is impossible, I'd much rather block cookies on the root domain, quipelements.com, than on the subdomains, e.g. element-a.quipelements.com.

[sleevi]

Can you explain why you want to block cookies for element-a.quipelements.com given that you will never be serving content from foo.element-a.quipelements.com ? As @weppos mentioned, typically the *.example syntax is used to indicate that there's a foo.bar.example domain and baz.bar.example domain, and both foo and baz are independent.

Blocking cookies for quipelements.com from being set by element-a and element-b is possible by just removing the wildcard.

[plinehan]

Yes, our use-case is rather unusual.

We want to block element-a.quipelements.com from setting cookies on quipelements.com for the obvious reasons... element-a and element-b are independent and unrelated.

However, we also don't want content served from element-a.quipelements.com to be able to set cookies for its own domain, element-a.quipelements.com. Content from this location is only served from within a very strictly sandboxed iframe, and, for security reasons, we don't even want cookies from one instance of this iframe leaking into other instances of this iframe. We already pragmatically block the JavaScript APIs for setting cookies within these iframes, but we'd like the additional security layer of having the browser enforce it for us, as well.

If I have to make the choice between blocking cookies on the subdomains or just on quipelements.com, I'd gladly choose the latter, but ideally I could do both. Thanks again for your help.

[sleevi]

Thanks for clarifying. Using the wildcard approach is the best compatibility with existing user agents. There's been a long discussion about whether a PSL entry of *.foo.bar.baz implies that foo.bar.baz is or is not a public suffix. Implementations vary, hence the current rules preventing both. In the future, it may be necessary to add quipelements.com as well to the list.

@gerv @weppos I couldn't find the discussion on GitHub (the closest is #145 ). The previous discussion was captured in https://wiki.mozilla.org/Public_Suffix_List/platform.sh_Problem

[plinehan]

Thank you so much for all your help!