I'm not sure why GitHub doesn't offer TLS over custom domains. They may have some limimtation in how the Pages system is built that means reworking it to introduce this function might be prohibitively costly at the moment.
The answer to the second question is "I guess it depends".
In one way I think it's more about perception - https should be https and https should be secure. Not https sort of halfway along the connection, then clear and unsecure for the rest over the public internet.
That's what a lot of people have trouble with over Cloudflare's particular popularisation of this 'broken' https model.
Also, all the data hoovered up by NSA et al puts a picture together, maybe about a person, their habits, what sites and content they read etc etc. Thanks to SNI https will likely leak the domain, but other than that it'll secure the rest of the info.
And what if (like I do on my site) I share a PGP key fingerprint? What if that's midified over the insecure portion of the connection? Now any communication by that route might be compromised.
I get that it can be seen as pedantic, but all steps in the connection as a whole need to be secure if https is to remain trusted.
I suppose overall the push is (and should be) towards default encryption and privacy for the visitor. That's something I'd support at least.
The answer to the second question is "I guess it depends".
In one way I think it's more about perception - https should be https and https should be secure. Not https sort of halfway along the connection, then clear and unsecure for the rest over the public internet.
That's what a lot of people have trouble with over Cloudflare's particular popularisation of this 'broken' https model.
Also, all the data hoovered up by NSA et al puts a picture together, maybe about a person, their habits, what sites and content they read etc etc. Thanks to SNI https will likely leak the domain, but other than that it'll secure the rest of the info.
And what if (like I do on my site) I share a PGP key fingerprint? What if that's midified over the insecure portion of the connection? Now any communication by that route might be compromised.
I get that it can be seen as pedantic, but all steps in the connection as a whole need to be secure if https is to remain trusted.
I suppose overall the push is (and should be) towards default encryption and privacy for the visitor. That's something I'd support at least.