The issue is that the Chagos islanders were evicted by the British so that Diego Garcia could be handed over to the USA for a military base. The Chagossians were not compensated in any way. Using a .io domain name (unwittingly) shows disregard for colonial land theft and ethnic cleansing.
Whereas Saint Helena and Ascention island (.ac, ICB again) were uninhabited before european colonization, so their domain names are not associated with that kind of appalling evil. There are legit reasons for disliking ICB’s involvement and the misappropriation of the domain registration money, enough reasons to boycott them, but it is in no way exactly the same as what happened to the Chagossians.
Does anything get better for Chagos Islanders by not using .io domains? If not, what’s the difference between this and all the other horrid shit which goes into the products we all use every day?
Probably not. But we shouldn’t let the existence of great wrongs overwhelm our ability to address lesser wrongs. That’s just paralysis, or compassion fatigue.
I treat the use of a .io domain as a medium-scale negative signal. It doesn’t mean the people involved are definitely racists, but it indicates that they don’t care enough to do a little research. There are plenty of gTLDs to choose from.
easier said than done when my email is hosted on that domain as well & everyone polling my RSS feed would need redirection 😥 plus, all my historical links would break. i would like to move but it’s a lot of work and churn for a site that i’ve built up for years.
I hosted my website, RSS feeds, and email on a .in domain for 16 years. Then I decided to move everything to a .net domain. Since my entire setup is version controlled, it took only a few commits to move my website and email from the old .in domain to the new .net domain:
The migration went well without any issue. There has been no loss of RSS feed subscribers. The web server access logs show that all the RSS clients and aggregators were successfully redirected to the new domain.
I agree with you that it’s not hard to switch domains (I’ve also done it myself), but, because I used my old domain for email, I’m essentially forced to keep paying for it. Otherwise, someone could just buy up my old domain and start receiving my emails. I’ve gone through the process of updating my email for just about every service I know, but even after four years I still get the occasional email sent to my old domain. Maybe if I can go five years without receiving any emails for my old domain I’d feel more comfortable giving it up, bit even then it still feels like a security risk.
Switching domains for ethical reasons seems moot if you still have to keep paying for it.
It would be good in general if people were more aware of the political considerations of choosing a TLD and the dangers they might pose to a registration.
I’ve seen people using .dev and .app a lot, it’s worth considering these are Google-controlled TLDs. What really rubbed me the wrong way about these TLDs is Google’s decision to make HSTS mandatory for the entire TLD, forcing HTTPS for any website using them. I’m sure some people will consider this a feature but for Google to arbitrarily impose this policy on an entire TLD felt off to me. No telling what they’ll do in the future.
.app and .dev aren’t comparable to ccTLDs like .sh and .up, however. gTLDs like .app and .dev have to stick to ICANN policies; ccTLDs don’t, and you’re at the mercy of the registry and national law for the country in question.
I was actually just discussing this fact with someone, but interestingly, we were discussing it as a positive, not a negative.
All of the newTLDs are under ICANN’s dominion, and have to play by ICANN’s rules, so they don’t provide independence from ICANN’s influence. Whereas the CCTLDs are essentially unconditional handouts which ICANN can’t exert influence over. So there’s a tradeoff here depending on whom you distrust more: ICANN, or the specific country whose TLD you’ve chosen.
HSTS preload for the entire TLD is brilliant idea, and I think every TLD going forward should have it.
Defaulting to insecure HTTP URLs is a legacy problem that creates a hole in web’s security (it doesn’t matter whats on insecure-HTTP sites, their mere existence is an entry point for MITM attacks against browser traffic). TOFU HSTS is only a partial band-aid, and per-domain preload list is not scalable.
The Trust-On-First-Use aspect is that HSTS is remembered by the browser only after the browser has loaded the site once; this leaves first-time visitors willing to connect over unencrypted HTTP.
(Well, except for the per-domain preload list mentioned by kornel.)
Sure, but HSTS is strictly a hint that HTTPS is supported, and browsers should use that instead, right? There is no actual trust there, because the TLS certificate is still authenticated as normal.
Compare this to SSH, which actually is TOFU in most cases.
Not quite - HSTS prevents connection over plaintext HTTP and prevents users from creating exceptions to ignore invalid certificates. It does more than be a hint, it changes how the browser works for that domain going forward. The TOFU part is that it won’t apply to a user’s first connection - they could still connect over plaintext HTTP, which means that a suitably positioned attacker could respond on the server’s behalf with messages that don’t include the HSTS header (if the attacker is fast enough). This works even if the site itself isn’t serving anything over HTTP or redirects immediately to HTTPS.
Calling it TOFU is admittedly a bit of a semantic stretch as I’m not sure what the specific act of trust is (arguably HSTS tells your browser to be less trustful), but the security properties are similar in that it only has the desired effect if the initial connection is trustworthy.
Okay, I see the point about first-time connections, but that wouldn’t change regardless of the presence or absence of HSTS. So why single that header out? It seems to me that having HSTS is strictly better than not having one.
The discussion was about HSTS preload which avoids the first connection problem just explained by pre-populating HSTS enforcement settings for specific domains directly in the browser distribution, so there is no risk of that first connection hijack scenario because the browser acts as if it had already received the header even if it had never actually connected before.
Normally this is something you would opt-in to and request for your own domain after you registered it, if desired… but Google preloaded HSTS for the entire TLDs in question, so you don’t have the option to make the decision yourself. If you register a domain under that TLD then Chrome will effectively refuse to ever connect via http to anything under that domain (and to my knowledge every other major browser uses the preload list from Chrome.)
It’s this lack of choice that has some people upset, though it seems somewhat overblown, as Google was always very upfront that this was a requirement, so it shouldn’t have been a surprise to anyone. There is also some real concern that there’s a conflict of interest in Google’s being effectively in total control of both the TLDs and the preload list for all browsers.
The discussion was about HSTS preload which avoids the first connection problem just explained by pre-populating HSTS enforcement settings for specific domains directly in the browser distribution, so there is no risk of that first connection hijack scenario because the browser acts as if it had already received the header even if it had never actually connected before
Ahh, THIS is the context I was missing here. In which case, @kornel’s original comment about this being a non-scalable bandaid solution is correct IMO. It’s a useful mitigation, but probably only Google could realistically do it like this.
I think the more annoying thing about .dev is that a bunch of local development dns systems like puma-dev and pow used .dev and then Google took it away and made us all change our dev environments.
I think the more annoying thing about .dev is that a bunch of local development dns systems like puma-dev and pow used .dev and then Google took it away and made us all change our dev environments.
That seems unfortunate, but a not terribly surprising consequence of ignoring the names that were specifically reserved for this purpose and making up their own thing instead.
I mean user typing “site.example.com” URL in their browser’s address bar. If the URL isn’t in the HSTS preload list, then it is assumed to be HTTP URL and HTTPS upgrade is like TOFU (the first use is vulnerable to HTTPS-stripping). There are also plenty of http:// links on the web that haven’t been changed to https://, because HTTP->HTTPS redirects keep them working seamlessly, but they’re also a weak link if not HSTS-ed.
I have no idea where to even start to research this stuff. I use .dev in my websites but I didn’t know it was controlled by Google. I legitimately thought these all are controlled by some central entity.
If you are going to rent a property (domain names) for your www home and if you are going to let your content live in that home for many years it pays off to research this stuff about where you are renting the property from.
Seems like an awful lot of angst for something people pay about $30 a year for! Maybe repurpose that to look into the ethics of your bank, telco, credit card company, ISP, grocery store, or something else you put hundreds of times as much money into?
(Also, lobste.rs’ TLD, .rs, is Russia. Not to get all political but I hear Russia’s done some bad things over the years?)
.rs is Serbia (Republika Srbija), Russia would be .ru. Going back to the 90’s Serbia was also doing bad things, but currently to my knowledge the state Serbia only has some small conflicts with Kosovo from time to time.
I agree with the general comment though, that also Lobsters is using a ccTLD from a completely different state.
Does anyone know of any registry operators that aren’t awful greedy monsters? As far as I can see a bunch of the ccTLD operators are cooperatives or not-for-profits (.de’s DENIC, .uk’s Nominet, .eu’s EURid, .scot’s dotScot, etc.) but that’s it.
Even then, Nominet has been full of issues the last decade, and I haven’t been able to find anything to back up dotScot’s not-for-profit status.
fundació.cat is a non-profit as well, which exists to promote Catalan language and culture via the .cat domain. This isn’t a ccTLD, but an sTLD, but .scot is also not a ccTLD, so I thought it was worth a mention in response to your question.
I unfortunately chose .io a number of years ago before I knew better, and because I could actually get a decent name there.
These days it seems like there are a billion TLDs and most aren’t very recognizable by the average user, other than really obscure or long domain names, and many still have similar baggage to .io. Does anyone here have a recommendation on where to look for good domain names? Sometimes it seems like all of them are already taken.
i’m on .me (vgel.me), Montenegro’s cctld run by doMEn which I assume is a single purpose company, and haven’t had any complaints. i mean i’m sure they’re eating babies in the corporate offices or something, but the email delivery seems alright, i was able to get a 4-letter domain without dropping $200k, and they’re not overtly horrid as far as i know.
In a former life, I used to work for a registrar and built their domain management platform. That meant I dealt with the .me registry - the staff there were all lovely to deal with!
For non-email use, I honestly just look at whatever namecheap has on sale at the moment. I’ve had good luck with .fyi, .site and .us for a few PoC-y things lately.
Are you allowed to have anonymous whois on a .us domain? Back when I had one, you needed to provide your real name and address to the record for “anti-terrorism” reasons or something silly like that. I even wrote to my (then) Senator about it because I thought it was dumb… I ended up moving my personal domain from .us to .net over it.
No. And that just bit me once again. For the stuff I use it for (tech demos, etc.) I don’t really care. But I’m so used to my registrar’s generous private whois service that I didn’t notice the absence of that checkbox when I bought my most recent one.
Then my phone started ringing with “scam risk” numbers wanting to sell me offshore site development services. I’ve set up a free google voice number with screening just to list in whois, now.
None of them seem to bother with direct mail because it’s too costly.
Oooof, I knew there was general-British-colonialism involved, but did not know the story of the Chagos Islanders and Diego Garcia specifically before this post. Thank you for sharing.
Well. .io domains became popular in part because the cost was non-zero. This meant far less squatting.
ICANN will never bother anyone, let alone put $1/year/domain into a random charity to kill domain squatting.
This particular one associates some political baggage. I think @j3s had the correct comment about knowing that the .sh domain also has some shady past. Truly, you picked .sh because it sounded fine and was not squatted to death?
.sh domains considered harmful… for the exact same reasons. It’s also owned by ICB.
The issue is that the Chagos islanders were evicted by the British so that Diego Garcia could be handed over to the USA for a military base. The Chagossians were not compensated in any way. Using a
.iodomain name (unwittingly) shows disregard for colonial land theft and ethnic cleansing.Whereas Saint Helena and Ascention island (
.ac, ICB again) were uninhabited before european colonization, so their domain names are not associated with that kind of appalling evil. There are legit reasons for disliking ICB’s involvement and the misappropriation of the domain registration money, enough reasons to boycott them, but it is in no way exactly the same as what happened to the Chagossians.Does anything get better for Chagos Islanders by not using .io domains? If not, what’s the difference between this and all the other horrid shit which goes into the products we all use every day?
Probably not. But we shouldn’t let the existence of great wrongs overwhelm our ability to address lesser wrongs. That’s just paralysis, or compassion fatigue.
Ah, my bad. I can’t edit the original comment… stop upvoting me, this is off-topic anyway! :P
AIUI Chagos Islands were also uninhabited before European (French) colonisation.
I treat the use of a
.iodomain as a medium-scale negative signal. It doesn’t mean the people involved are definitely racists, but it indicates that they don’t care enough to do a little research. There are plenty of gTLDs to choose from.Pretty ironic to see this post hosted on a
.shdomain name. Yes,.iodomains are harmful but so are.shdomains!true!! I wish someone had informed me before I hitched my life to a .sh domain. i hope my post helps someone avoid similar regrets.
Well the web isn’t (yet) hotel california, domains can move hinthint
easier said than done when my email is hosted on that domain as well & everyone polling my RSS feed would need redirection 😥 plus, all my historical links would break. i would like to move but it’s a lot of work and churn for a site that i’ve built up for years.
I hosted my website, RSS feeds, and email on a
.indomain for 16 years. Then I decided to move everything to a.netdomain. Since my entire setup is version controlled, it took only a few commits to move my website and email from the old.indomain to the new.netdomain:The migration went well without any issue. There has been no loss of RSS feed subscribers. The web server access logs show that all the RSS clients and aggregators were successfully redirected to the new domain.
I agree with you that it’s not hard to switch domains (I’ve also done it myself), but, because I used my old domain for email, I’m essentially forced to keep paying for it. Otherwise, someone could just buy up my old domain and start receiving my emails. I’ve gone through the process of updating my email for just about every service I know, but even after four years I still get the occasional email sent to my old domain. Maybe if I can go five years without receiving any emails for my old domain I’d feel more comfortable giving it up, bit even then it still feels like a security risk.
Switching domains for ethical reasons seems moot if you still have to keep paying for it.
It would be good in general if people were more aware of the political considerations of choosing a TLD and the dangers they might pose to a registration.
I’ve seen people using .dev and .app a lot, it’s worth considering these are Google-controlled TLDs. What really rubbed me the wrong way about these TLDs is Google’s decision to make HSTS mandatory for the entire TLD, forcing HTTPS for any website using them. I’m sure some people will consider this a feature but for Google to arbitrarily impose this policy on an entire TLD felt off to me. No telling what they’ll do in the future.
.app and .dev aren’t comparable to ccTLDs like .sh and .up, however. gTLDs like .app and .dev have to stick to ICANN policies; ccTLDs don’t, and you’re at the mercy of the registry and national law for the country in question.
I was actually just discussing this fact with someone, but interestingly, we were discussing it as a positive, not a negative.
All of the newTLDs are under ICANN’s dominion, and have to play by ICANN’s rules, so they don’t provide independence from ICANN’s influence. Whereas the CCTLDs are essentially unconditional handouts which ICANN can’t exert influence over. So there’s a tradeoff here depending on whom you distrust more: ICANN, or the specific country whose TLD you’ve chosen.
HSTS preload for the entire TLD is brilliant idea, and I think every TLD going forward should have it.
Defaulting to insecure HTTP URLs is a legacy problem that creates a hole in web’s security (it doesn’t matter whats on insecure-HTTP sites, their mere existence is an entry point for MITM attacks against browser traffic). TOFU HSTS is only a partial band-aid, and per-domain preload list is not scalable.
Does HTTPS really count as TOFU? Every cert is ultimately checked against a known list of CAs.
The Trust-On-First-Use aspect is that HSTS is remembered by the browser only after the browser has loaded the site once; this leaves first-time visitors willing to connect over unencrypted HTTP.
(Well, except for the per-domain preload list mentioned by kornel.)
Sure, but HSTS is strictly a hint that HTTPS is supported, and browsers should use that instead, right? There is no actual trust there, because the TLS certificate is still authenticated as normal.
Compare this to SSH, which actually is TOFU in most cases.
Not quite - HSTS prevents connection over plaintext HTTP and prevents users from creating exceptions to ignore invalid certificates. It does more than be a hint, it changes how the browser works for that domain going forward. The TOFU part is that it won’t apply to a user’s first connection - they could still connect over plaintext HTTP, which means that a suitably positioned attacker could respond on the server’s behalf with messages that don’t include the HSTS header (if the attacker is fast enough). This works even if the site itself isn’t serving anything over HTTP or redirects immediately to HTTPS.
Calling it TOFU is admittedly a bit of a semantic stretch as I’m not sure what the specific act of trust is (arguably HSTS tells your browser to be less trustful), but the security properties are similar in that it only has the desired effect if the initial connection is trustworthy.
Okay, I see the point about first-time connections, but that wouldn’t change regardless of the presence or absence of HSTS. So why single that header out? It seems to me that having HSTS is strictly better than not having one.
The discussion was about HSTS preload which avoids the first connection problem just explained by pre-populating HSTS enforcement settings for specific domains directly in the browser distribution, so there is no risk of that first connection hijack scenario because the browser acts as if it had already received the header even if it had never actually connected before.
Normally this is something you would opt-in to and request for your own domain after you registered it, if desired… but Google preloaded HSTS for the entire TLDs in question, so you don’t have the option to make the decision yourself. If you register a domain under that TLD then Chrome will effectively refuse to ever connect via http to anything under that domain (and to my knowledge every other major browser uses the preload list from Chrome.)
It’s this lack of choice that has some people upset, though it seems somewhat overblown, as Google was always very upfront that this was a requirement, so it shouldn’t have been a surprise to anyone. There is also some real concern that there’s a conflict of interest in Google’s being effectively in total control of both the TLDs and the preload list for all browsers.
Ahh, THIS is the context I was missing here. In which case, @kornel’s original comment about this being a non-scalable bandaid solution is correct IMO. It’s a useful mitigation, but probably only Google could realistically do it like this.
I think the more annoying thing about .dev is that a bunch of local development dns systems like
puma-devandpowused.devand then Google took it away and made us all change our dev environments.That seems unfortunate, but a not terribly surprising consequence of ignoring the names that were specifically reserved for this purpose and making up their own thing instead.
I mean user typing “site.example.com” URL in their browser’s address bar. If the URL isn’t in the HSTS preload list, then it is assumed to be HTTP URL and HTTPS upgrade is like TOFU (the first use is vulnerable to HTTPS-stripping). There are also plenty of
http://links on the web that haven’t been changed tohttps://, because HTTP->HTTPS redirects keep them working seamlessly, but they’re also a weak link if not HSTS-ed.uh! I chose .app (unaware, stupid me) for a software project that discarded the Go toolchain for this very reason. Have to reconsider, thx!
I have no idea where to even start to research this stuff. I use .dev in my websites but I didn’t know it was controlled by Google. I legitimately thought these all are controlled by some central entity.
It is not really that hard. You can start with https://en.wikipedia.org/wiki/.dev
If you are going to rent a property (domain names) for your www home and if you are going to let your content live in that home for many years it pays off to research this stuff about where you are renting the property from.
.test is untainted.
Huh? There’s no registrar for .test, it’s just for private test/debug domains.
Seems like an awful lot of angst for something people pay about $30 a year for! Maybe repurpose that to look into the ethics of your bank, telco, credit card company, ISP, grocery store, or something else you put hundreds of times as much money into?
(Also, lobste.rs’ TLD, .rs, is Russia. Not to get all political but I hear Russia’s done some bad things over the years?)
.rsis Serbia (Republika Srbija), Russia would be.ru. Going back to the 90’s Serbia was also doing bad things, but currently to my knowledge the state Serbia only has some small conflicts with Kosovo from time to time.I agree with the general comment though, that also Lobsters is using a ccTLD from a completely different state.
Damn, you’re right of course. Somehow I got them mixed up.
All of those things are much harder to avoid than .io domains are
Does anyone know of any registry operators that aren’t awful greedy monsters? As far as I can see a bunch of the ccTLD operators are cooperatives or not-for-profits (.de’s DENIC, .uk’s Nominet, .eu’s EURid, .scot’s dotScot, etc.) but that’s it.
Even then, Nominet has been full of issues the last decade, and I haven’t been able to find anything to back up dotScot’s not-for-profit status.
The Dutch (.nl) registry operator SIDN is a nonprofit foundation as well.
fundació.cat is a non-profit as well, which exists to promote Catalan language and culture via the .cat domain. This isn’t a ccTLD, but an sTLD, but .scot is also not a ccTLD, so I thought it was worth a mention in response to your question.
SWITCH (ccTLD for Switzerland) is a non-profit foundation too.
.io isn’t going anywhere any time soon. .su still exists, as do practically all of the other ccTLDs that got any use.
I’d love the Chagossians to get all the money they’re rightfully owed.
How is Factorio Silicon Valley, it’s made in Prague.
OTOH factor.io is in SF
I unfortunately chose .io a number of years ago before I knew better, and because I could actually get a decent name there.
These days it seems like there are a billion TLDs and most aren’t very recognizable by the average user, other than really obscure or long domain names, and many still have similar baggage to
.io. Does anyone here have a recommendation on where to look for good domain names? Sometimes it seems like all of them are already taken.Well if there would be a good recommendation, they’d already be squatted.
i’m on .me (vgel.me), Montenegro’s cctld run by doMEn which I assume is a single purpose company, and haven’t had any complaints. i mean i’m sure they’re eating babies in the corporate offices or something, but the email delivery seems alright, i was able to get a 4-letter domain without dropping $200k, and they’re not overtly horrid as far as i know.
In a former life, I used to work for a registrar and built their domain management platform. That meant I dealt with the .me registry - the staff there were all lovely to deal with!
For non-email use, I honestly just look at whatever namecheap has on sale at the moment. I’ve had good luck with .fyi, .site and .us for a few PoC-y things lately.
Are you allowed to have anonymous whois on a
.usdomain? Back when I had one, you needed to provide your real name and address to the record for “anti-terrorism” reasons or something silly like that. I even wrote to my (then) Senator about it because I thought it was dumb… I ended up moving my personal domain from.usto.netover it.No. And that just bit me once again. For the stuff I use it for (tech demos, etc.) I don’t really care. But I’m so used to my registrar’s generous private whois service that I didn’t notice the absence of that checkbox when I bought my most recent one.
Then my phone started ringing with “scam risk” numbers wanting to sell me offshore site development services. I’ve set up a free google voice number with screening just to list in whois, now.
None of them seem to bother with direct mail because it’s too costly.
The whole text is a piece of art. Nice use of ASCII, indentation, funny comments, no sequiturs. Brilliant
Oooof, I knew there was general-British-colonialism involved, but did not know the story of the Chagos Islanders and Diego Garcia specifically before this post. Thank you for sharing.
Well. .io domains became popular in part because the cost was non-zero. This meant far less squatting.
ICANN will never bother anyone, let alone put $1/year/domain into a random charity to kill domain squatting.
This particular one associates some political baggage. I think @j3s had the correct comment about knowing that the .sh domain also has some shady past. Truly, you picked .sh because it sounded fine and was not squatted to death?