Brave Submissions to the Public Suffix List - Q4 2023

[thypon]

Public Suffix List (PSL) Pull Request (PR) Template

Each PSL PR needs to have a description, rationale, indication of DNS validation and syntax checking, as well as a number of acknowledgements from the submitter. This template must be included with each PR, and the submitting party MUST provide responses to all of the elements in order to be considered.

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• This request was not submitted with the objective of working around other third-party limits

• The Guidelines were carefully read and understood, and this request conforms
• The submission follows the guidelines on formatting and sorting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

---

Description of Organization

Organization Website: https://brave.com
Submitter: Andrea Brancaleoni
Role: Security Engineer at Brave Software

Brave Software is a technology company that focuses on enhancing the privacy and security of web users. Brave's primary product is the Brave browser: https://brave.com. Besides the browser, Brave also includes an independent Search engine available at https://search.brave.com.

I manage security and operations, ensuring our organizational practices align with our core mission of providing enhanced online privacy and security.

Reason for PSL Inclusion

Number of users this request is being made to serve: 10-100 Million of users.

We believe that the inclusion of our domain(s) in the PSL is of utmost importance for several significant reasons:

1. Cookie Security: Having our domain(s) on the PSL will ensure that each subdomain is treated separately, minimizing potential security risks. We plan, in particular, to store any user-generated content in his eTLD+1 (img-proxies - e.g. img-proxy.search.s.brave.io, s3 proxied buckets- e.g. userimages.creators.s.brave.io)
2. Third-party Integrations: Our platform frequently integrates with various services, proxying services to preserve users' privacy. Inclusion in the PSL would simplify the process while maintaining a high standard of transparency when hosted on brave domains.

All our private section domain names adhere to a long-term registration policy, with current registration terms extending beyond 2 years. We pledge to maintain a registration term of more than one year at all times to ensure our continued presence on the PSL.

We have not made any attempts to work around third-party limits and fully understand the significance of genuine interactions and compliance with all guidelines. We have not previously submitted any issues or PRs related to this particular request.

DNS Verification via dig

$ dig +short TXT _psl.s.brave.io
"https://github.com/publicsuffix/list/pull/1872"

Results of Syntax Checker (make test)

[simon-friedberger]

Hi @thypon,

am I understanding correctly that you want to have cookie separation for img-proxy.search.s.brave.com and userimages.creators.s.brave.com? I don't see how there are actually separate entities here. If, instead, those are supposed to be the base you have to actually add those to the PSL.

You don't seem to have the required remaining two years of validity on brave.com.

[thypon]

Hi @simon-friedberger

am I understanding correctly that you want to have cookie separation for img-proxy.search.s.brave.com and userimages.creators.s.brave.com? I don't see how there are actually separate entities here. If, instead, those are supposed to be the base you have to actually add those to the PSL.

Indeed, I think it's correct!

The idea here is that a product in Brave, such as search/creators/VPN/..., might have multiple external services (CDN, proxy), which we serve behind a distinct eTLD+1.

So if $product.s.brave.com is the eTLD, I would like to have the CDN to be hosted at $cdn.$product.s.brave.com.

The final objective is to have $product.brave.com cookie separated from $cdn.$product.s.brave.com

You don't seem to have the required remaining two years of validity on brave.com.

Sorted! It should now have >5 years of validity.

Expires on 2029-09-17

[simon-friedberger]

@thypon And you want to prevent cookie usage on brave.com and separate cookies for foo.brave.com from bar.brave.com?

[simon-friedberger]

The final objective is to have $product.brave.com cookie separated from $cdn.$product.s.brave.com

You understand that you won't be able to set cookies on $product.brave.com if it becomes a public suffix?

[thypon]

@thypon And you want to prevent cookie usage on brave.com and separate cookies for foo.brave.com from bar.brave.com?

Nope - while it's not the case - we might use the main eTLD+1 (brave.com) domain to share cookies.

You understand that you won't be able to set cookies on $product.brave.com if it becomes a public suffix?

If $cdn.$product.s.brave.com is eTLD+1, do $product.s.brave.com (eTLD) and s.brave.com (??) and brave.com (??) become public suffix recursively?

To be more clear. I would like to have *.s.brave.com as a public suffix (eTLD), but not s.brave.com or brave.com, or anything else under brave.com (e.g. search.brave.com).

If I understand correctly, with my rule:

• cdn.product.s.brave.com will be eTLD+1, where cdn is the +1, and product.s.brave.com will be my eTLD
• product.brave.com will be eTLD+2, where cdn.brave is the +2, and com is my eTLD
• brave.com will be eTLD+1, where brave is the +1, and com is my eTLD

The idea is: the products are "trusted" to share the same eTLD+1 (brave.com), so they might cookie share between them (e.g. to allow
easy login flows). Every $product might have a sandbox PSL domain $product.s.brave.com (eTLD), with untrusted sub components (e.g. proxies, or cdns) $cdn.$product.s.brave.com (eTLD+1).

If the answer to the following question below is NO and s.brave.com will still be an eTLD+2 and brave.com an eTLD+1, the rest is intended:

If $cdn.$product.s.brave.com is eTLD+1, do $product.s.brave.com (eTLD) and s.brave.com (??) and brave.com (??) become public suffix recursively?

[simon-friedberger]

I hope this answers your question: https://github.com/publicsuffix/list/wiki/Format#example

If it does not, please let me know what we need to add there.

[simon-friedberger]

Afaiu the needs this is good to go.

• The tests pass.

[thypon]

Converting to draft, while I perform the last sanity checks

[thypon]

Before

After

[thypon]

Ready! Thanks @simon-friedberger for the review

[fmarier]

I hope this answers your question: https://github.com/publicsuffix/list/wiki/Format#example

If it does not, please let me know what we need to add there.

@simon-friedberger Here's a suggestion to make it clear that entries at a higher level don't impact lower levels. Add the following just below 1. com:

*.foo.com

and then add these bullet points just below Cookies may be set for foo.com.:

• Cookies may not be set for bar.foo.com.
• Cookies may be set for example.bar.foo.com.

[simon-friedberger]

Hi @fmarier !

Isn't this exactly what we have?

*.hokkaido.jp

Cookies may be set for foo.bar.hokkaido.jp.
Cookies may not be set for bar.hokkaido.jp.

[fmarier]

Isn't this exactly what we have?

The hokkaido.jp example is very similar but different in one important way: *.jp is also on the PSL and so the minimum level that you can set a .jp cookie at is 3.

My suggestion was building on the fact that we can set cookies at the foo.com level (level 2) and that we can therefore continue to do so even after adding *.foo.com to the PSL.

[simon-friedberger]

Oh, I see. I was thinking of the example as being self contained and independent of the actual PSL. Thanks for clarifying!

[fmarier]

Ah sorry for the confusion. It was definitely a "diff" on the existing example on the wiki :)

[thypon]

We might have a bug in the chromium PSL parser I'm investigating

[thypon]

Given the following concerns we decided to move forward with brave.io instead of the main brave.com.

Concerns

Bug in handling wildcards in major libraries

I went over all the FOSS implementations in https://publicsuffix.org/learn/ , and I found 3 of them behave funny for wildcard domains. In particular:

• regdom-libs
• publicsuffix2
• publicsuffixlist.js

Seems to all mislabel eTLD-n x [eTLD minus n] (with n from 0 to infinite), as an eTLD, if another eTLD y is defined as a subdomain of that x eTLD-n.

As an example publicsuffix2 behaviour with the following patch:

 // Linode : https://linode.com
 // Submitted by <security@linode.com>
 members.linode.com
-nodebalancer.linode.com
+*.nodebalancer.linode.com
+*.linodeobjects.com
+ip.linodeusercontent.com

Strict eTLD handling in Safari

Additionally, I was not able to test the PSL implementation for Safari which seems to strictly adhere to rfc6265#5.3, unlike any other browser.

If ... the [cookie] domain-attribute is a public suffix ... ignore the
cookie entirely

[simon-friedberger]

@thypon You might want to create some issues on those projects.

[dnsguru]

I have observed that there can be variance on how this text file catalog of strings is used by implementors.

Outside of the algorithm, the PSL is non-prescriptive on how implementors integrate or use the PSL.

Nor is there much influence or sway to do things.

There are still implementations using stale snapshots from almost a decade ago out in the wild causing fractured UX.

Simon's suggestion is the right approach. And good luck.

[thypon]

Is there any other showstopper to proceed with brave.io?

[dnsguru]

#1872 (comment)