An HTTPS-Censored Future
The Good News
One of the good news from the past weeks is that GitHub Pages finally supports HTTPS for custom domains. The feature that people waited forever eventually arrived. Although this is not too late, we have to admit, moving items out of “backlog” and “roadmap” and implement them can be a lengthy process.
Before this, regular people like me probably need to add an extra layer which supports HTTPS for your custom domain, such as Cloudflare or Netlify, to host their static content on GitHub/GitHub Pages. Cloudflare is professional at security while Netlify is mastering build and deploy especially if you use the JAMstack.
In reality, for various reasons, these solutions are not 100% perfect, regarding security, simplicity, or efficiency. Still, I should say they are worth trying (esp. Netlify) if you want to know more possibilities out there, beyond directly serving static websites.
The Bad News
HTTPS could also be a double-edged sword, in many ways. To establish a secure communication channel, the server and the client have to trust a centralized, third-party certificate authority (CA) who issues the certificates. The first issue is, some of the CAs themselves are not exactly playing by the book: backdating the certificates, misissuing certificates, to name a few. An even more pressing issue is, the universal application of HTTPS might bring up the possibility of a new type of censorship. One of the very recent examples could be Sci-Hub’s TLS certificate incident. If you connect it to its domain name takedowns ,  which happened quite a while ago, it could be quite alarming.
Reimagine the System
After 30 years when the Internet was first created, it might be the time to rethink some of its design, for example, the CA system and the domain system. Ideally, we want to be both secure and decentralized. At the end of the day, what Pied Piper is building in HBO’s Silicon Valley might not sound that crazy anymore.