How to Determine If Two Domains Have the Same Owner?

When browsing the web, we often distinguish different services by subdomain, for example:

• music.youtube.com/ → goes to YouTube Music
• youtube.com → https://www.youtube.com/ → goes to YouTube

Obviously, since the domain name is youtube.com, we can quickly tell that both domains are owned by YouTube. Therefore, we can trust the content and browse with peace of mind. So how should we determine whether two domains belong to the same owner? By checking whether the URL contains the string youtube.com?

Obviously, this is not an effective method. For example:

• youtube.kalan.dev
• youtube.com.kalan.dev

Although both of these subdomains contain the string “youtube”, we can quickly tell that they are not owned by YouTube.

Therefore, the way to identify subdomains should be parsed from right to left, rather than from left to right. Identifying subdomains is trivial for software engineers, but for people unfamiliar with domain mechanics, phishing via subdomains can easily lure them into traps.

Here comes the second question: how many parts should we look for from right to left? Taking blog.kalan.dev as an example, the domain name is kalan.dev. We could write the code like this:

const host = 'blog.kalan.dev'.split('.').reverse().slice(0, 2).reverse().join('.')

However, this isn’t quite the right approach. For example:

• ebay: www.ebay.co.uk
• google: www.google.co.uk

If we look at it using the previous code, then co.uk would be the domain name, and www.ebay and www.google would be subdomains. Does that mean both websites belong to .co.uk? Clearly, this distinction is incorrect. eBay is eBay; Google is Google—the two domains belong to entirely different companies. The reason is that country code top-level domains paired with second-level domains are also treated as standalone domain names. Therefore, the correct parsing method here is to treat google.co.uk and ebay.co.uk as two separate hosts with completely different owners.

TLD (Top-Level Domain)

It’s time to talk about top-level domains. Suffixes like .io, .dev¹, and .org are managed by ICANN. Anyone can register their own domain—for instance, my kalan.dev is a domain formed with the .dev suffix.

ccTLD (Country Code Top-Level Domain)

There are also corresponding top-level domains based on geographic regions, such as .tw or .jp. Note that when some country codes are combined with other second-level domains, they can also form a domain namespace together, such as:

• www.momoshop.com.tw
• www.books.com.tw

Across these two websites, momoshop.com.tw and books.com.tw are the domain names, while www.momoshop.com.tw and www.books.com.tw are their subdomains.

eTLD (Effective Top-Level Domains)

From the examples above, we see that some top-level domains can pair with a second-level domain to form a domain name (like kalan.dev), while others combine two domain levels to act as a top-level domain (.com.tw). How does a browser know how to parse this? Behind the scenes, this is achieved by maintaining a massive Public Suffix List (PSL). The domain names listed there are called effective top-level domains (eTLD). The list can be found here.

Another common term is eTLD+1, which means an effective top-level domain plus one label forms a registrable domain. In this example, .com.tw is the effective top-level domain, and momoshop is the second-level domain.

What SameSite Means for Front-End Applications

The greatest significance of domain mechanisms for the front end lies in determining SameSite². We want to know whether two websites are SameSite because under SameSite conditions, website cookies can be shared (provided no special headers prevent it).

So, given two website URLs, kalan.hacker.com and jack.hacker.com, are these two URLs SameSite? At first glance, both URLs look like subdomains of hacker.com. But after the examples and explanations above, we should first check whether hacker.com is in the Public Suffix List before making a judgment.

If you’re interested in discussions around cookies and SameSite, feel free to check out my previous article: Rethinking Cookies and CORS.

An Example with GitHub

On GitHub, you can generate a free xxx.github.io domain through repository settings, such as my old blog: kjj6198.github.io/blog. In this scenario, we definitely don’t want cookies across different xxx.github.io sites to be accessible by one another. For these types of applications, we want each xxx.github.io to be an independent domain rather than a shared subdomain of .github.io. eTLD solves this problem effectively, and checking the Public Suffix List confirms that .github.io is indeed listed there.

Who Can Apply to the Public Suffix List?

According to the official documentation on publicsuffix, you just need to submit a pull request following their guidelines. However, the whole process seems to take some time, and looking at past PRs, reviews are handled manually.

A Look at Browser Address Bars

The image above shows how my blog.kalan.dev is displayed in the address bars of Firefox and Edge—Firefox on top, Edge on the bottom.

Did you spot the difference? In Edge, the text blog is the same color as kalan.dev, but in Firefox, the text blog is slightly lighter. Firefox’s address bar only highlights the registrable domain name, whereas Edge and Chrome highlight the entire domain part (including subdomains). In this case, Firefox’s address bar lets me quickly know that blog is a subdomain of kalan.dev.

Although this difference is subtle, Firefox’s address bar behavior becomes very useful when a domain contains an eTLD. For example, with kjj6198.github.io, because .github.io is an eTLD, the entire kjj6198.github.io is treated as the registrable domain.

The next time someone asks you whether two domains are SameSite, the best trick is to open Firefox, enter the URLs, and check whether the highlighted parts match. If they do, you can say with high confidence that they are SameSite!