Hacker News new | ask | show | jobs
by marksomnian 1064 days ago
There's some background at https://phabricator.wikimedia.org/T337586 - a wikimedia.org subdomain was out of the question due to security concerns (it'd involve giving a third party a SSL certificate for wikimedia.org) [1], and wikimediafoundation.org was ruled out because it could cause confusion about volunteers' relationship to the Foundation [2]

[1]: https://phabricator.wikimedia.org/T337586#8932905 [2]: https://phabricator.wikimedia.org/T337586#8936483

2 comments

From your first link, it seems the decision to use a different new domain stems from difficulties getting the server's HSTS policy right, and it even seems they had a similar issue in the past with having the store as a subdomain [1].

If that's true, for a use case as functionally basic as having a store and a social instance in their respective subdomains, it looks to me like a complete failure of HSTS, a case of technology causing problems that shouldn't exist to begin with.

[1]: https://phabricator.wikimedia.org/T337586#8920625

It's not linked there (or on any Wikitech pages I can find), but I can imagine there's a secondary concern of *.wikimedia.org cookies getting sent to third parties - e.g. Stack Overflow has separate second-level domains (stackoverflow.email/stackoverflow.blog) for their 3rd-party-hosted email service and blog for exactly this reason (cf. https://nickcraver.com/blog/2017/05/22/https-on-stack-overfl...)
Seems the real issue is that Mastodon is too hard to self host if not even Wikimedia wants to do it.

> it'd involve giving a third party a SSL certificate for wikimedia.org

You can have certificates for subdomains. With Let's Encrypt you still need to control the root domain to generate them so they'd have to setup something for that. But that's more a can't-be-bothered concern than an actual security concern. Teaching the public to trust random domains being authentic is a much much bigger security concern anyway.