I am fortunate to live in a country where the latter is extraordinarily unlikely to be immediately actionable by law enforcement and my action is protected by well-established law.
Moreover, a path-based identity is better for marketing. Put the company name first so people know “Oh, right, Example, that social media platform,” and not “SomethingIdontreallycarethatmuchabout on Example.”
Given that this user is also providing each subdomain a certificate, you could enumerate the entire userbase by looking at the CT Logs with a tool like crt.sh
Given that this user is also providing each subdomain a certificate, you could enumerate the entire userbase by looking at the CT Logs with a tool like crt.sh
I’m definitely not an expert, just a curious observer. But if everyone used DNS over HTTPS, would this no longer be an issue? DoH does have some problems though (centralization, can be blocked, SNI leaks, etc), and I’m not sure how widespread it is.
Even with DNS over HTTPS you’d still be leaking the domain name to a third party, so it is less private than putting the same info in the path. Obviously for many use cases that is fine.
The “why” is not really explained. What, for example, do subdomains have to do with giving users control over their own HTML/CSS? Why is it necessary to have custom subdomains as a stepping stone to custom domains? Isn’t that already a solved problem? Without answers to those questions, we’re left with getting rid of “noise” in the URLs.
The “how,” which has more depth, also seems incomplete. Session cookies and CORS headers are inherently specific down to the subdomain. Does this assume that centralized authentication and resources are not needed?
What, for example, do subdomains have to do with giving users control over their own HTML/CSS?
This specific example comes from the way that browsers handle requests for resources within a domain versus ones between domains since a subdomain is considered a separate silo. Malicious (or unwanted) payloads are harder to deliver across domains.
That was the impression that I got when I read it. In addition to the “branding” of a subdomain it also isolates users’ content from the rest of the domains on the server.
I also prefer that subdomain scheme but I’m not sure it’s a good solution for everything, but sometimes it is:
Take twitter as an example. They had to ‘claim’ all their own urls from the start or have to delete users at random if their head of product suddenly wants to have a promo at /awesome. That’s planning 15 years into the future or don’t have the possibility to do that.
For some totally subjective reason having a subdomain feels more like I own it to me. Of course it would be all the same to wordpress.com whether they yank my foo.wp.com over my wp.com/foo - but maybe because I come from a time where you actually typed out your urls instead of googling for parts of them. And when people actually used www. ;)
That said, I’ve never even seen a framework that supports hostname-based routing out of the box but I’ve written my own several times, and supporting custom domains (without iframes or forwards) is a big one to me. Then again I have my own soup/tumblr clone running and actually separate topics by hostname, so of course I am biased.
I never thought about the identity leak thing, and it’s a good argument to have, but for the content I host on the web it doesn’t matter and I absolutely prefer the thing that looks better to me.
Use of subdomains is an aesthetic thing…personally, I find it a cutesy and silly trick that conflates identity and service
<identity>.provider.com is cool but then what about cdn.provider.com or www.provider.com or support.provider.com? Usually I’ve seen this done with a blacklist for subdomain/identity names, but who am I to gaslight a user who chooses to identity as a mail exchange or wiki or support system?
That’s just me–I know other people like them for whatever reason.
I do have one plea, though, for people implementing this.
Please develop your web apps normally, and then do the subdomain nonsense at the ops level using nginx or caddy or whatever by rewriting URLs and setting custom headers which your app then picks up on.
As a developer on multiple products which decided to be cute with subdomains, not doing it this way has caused way more annoyance than reward. Being unable to run the app locally without lvh.me or some placeholder domain or whatever is just miserable developer experience. Just staaaahp.
I see multiple problems with that. Besides DNS leaking information on the kind of request, it also does not scale well (very large zone-files) and more or less requires a wildcard-certificate unless you are motivated to manage thousands of individual certificates. It also makes it nearly impossible to host it as a Tor hidden service, given Tor does not support subdomains in onion URLs (which I support!).
Especially the latter reason completely reformed how I approach this. Whenever possible, I use example.org/subtopic instead of subtopic.example.org, unless there’s a true topical distinction or different servers at play.
Granted, DoH reduces the risk of leakage, but most people still have unencrypted DNS. For this reason alone, one should probably reduce the number of DNS-requests as much as possible, and delegate more to the URI-scheme.
Subdomains as identity leaks information about the requested path via DNS.
https://example.com/saysbadthingsaboutbadpeopleinpower - DNS request is for example.com, TLS connection prevents request information from leaking
https://saysbadthingsaboutbadpeopleinpower.example.com - DNS gets the requested user
I am fortunate to live in a country where the latter is extraordinarily unlikely to be immediately actionable by law enforcement and my action is protected by well-established law.
Moreover, a path-based identity is better for marketing. Put the company name first so people know “Oh, right, Example, that social media platform,” and not “SomethingIdontreallycarethatmuchabout on Example.”
Given that this user is also providing each subdomain a certificate, you could enumerate the entire userbase by looking at the CT Logs with a tool like crt.sh
Even if they use wildcard certs?
Obviously that will not work in such case.
Oh wow that’s a big one
I’m definitely not an expert, just a curious observer. But if everyone used DNS over HTTPS, would this no longer be an issue? DoH does have some problems though (centralization, can be blocked, SNI leaks, etc), and I’m not sure how widespread it is.
Even with DNS over HTTPS you’d still be leaking the domain name to a third party, so it is less private than putting the same info in the path. Obviously for many use cases that is fine.
DoH to a third-party would help but then there’s a SPOF for resolution.
Or DoT or DNS over Tor or any other privacy solution.
Breaking websites is not the solution.
The “why” is not really explained. What, for example, do subdomains have to do with giving users control over their own HTML/CSS? Why is it necessary to have custom subdomains as a stepping stone to custom domains? Isn’t that already a solved problem? Without answers to those questions, we’re left with getting rid of “noise” in the URLs.
The “how,” which has more depth, also seems incomplete. Session cookies and CORS headers are inherently specific down to the subdomain. Does this assume that centralized authentication and resources are not needed?
This specific example comes from the way that browsers handle requests for resources within a domain versus ones between domains since a subdomain is considered a separate silo. Malicious (or unwanted) payloads are harder to deliver across domains.
So the purpose is to enforce an architecture of isolated sandboxes for each user? That’s what the author means by “control”?
That was the impression that I got when I read it. In addition to the “branding” of a subdomain it also isolates users’ content from the rest of the domains on the server.
I also prefer that subdomain scheme but I’m not sure it’s a good solution for everything, but sometimes it is:
Take twitter as an example. They had to ‘claim’ all their own urls from the start or have to delete users at random if their head of product suddenly wants to have a promo at
/awesome. That’s planning 15 years into the future or don’t have the possibility to do that.For some totally subjective reason having a subdomain feels more like I own it to me. Of course it would be all the same to wordpress.com whether they yank my foo.wp.com over my wp.com/foo - but maybe because I come from a time where you actually typed out your urls instead of googling for parts of them. And when people actually used
www.;)That said, I’ve never even seen a framework that supports hostname-based routing out of the box but I’ve written my own several times, and supporting custom domains (without iframes or forwards) is a big one to me. Then again I have my own soup/tumblr clone running and actually separate topics by hostname, so of course I am biased.
I never thought about the identity leak thing, and it’s a good argument to have, but for the content I host on the web it doesn’t matter and I absolutely prefer the thing that looks better to me.
Use of subdomains is an aesthetic thing…personally, I find it a cutesy and silly trick that conflates identity and service
<identity>.provider.comis cool but then what aboutcdn.provider.comorwww.provider.comorsupport.provider.com? Usually I’ve seen this done with a blacklist for subdomain/identity names, but who am I to gaslight a user who chooses to identity as a mail exchange or wiki or support system?That’s just me–I know other people like them for whatever reason.
I do have one plea, though, for people implementing this.
Please develop your web apps normally, and then do the subdomain nonsense at the ops level using nginx or caddy or whatever by rewriting URLs and setting custom headers which your app then picks up on.
As a developer on multiple products which decided to be cute with subdomains, not doing it this way has caused way more annoyance than reward. Being unable to run the app locally without
lvh.meor some placeholder domain or whatever is just miserable developer experience. Just staaaahp.I did this at my last big company job.
I did it for scalability reasons.
Yep - if you are sharding anyways, it really makes sense.
I see multiple problems with that. Besides DNS leaking information on the kind of request, it also does not scale well (very large zone-files) and more or less requires a wildcard-certificate unless you are motivated to manage thousands of individual certificates. It also makes it nearly impossible to host it as a Tor hidden service, given Tor does not support subdomains in onion URLs (which I support!).
Especially the latter reason completely reformed how I approach this. Whenever possible, I use example.org/subtopic instead of subtopic.example.org, unless there’s a true topical distinction or different servers at play.
Granted, DoH reduces the risk of leakage, but most people still have unencrypted DNS. For this reason alone, one should probably reduce the number of DNS-requests as much as possible, and delegate more to the URI-scheme.