code4lib conf website should set a good example by using HTTPS

[eshellman]

after all https://code4lib.github.io/2016.code4lib.org/ serves just fine.

using a custom url is nice. but so is privacy and security

[bibliotechy]

Looks like it IS possible to do SSL on github pages with a custom domain, but would require pointing the 2016.code4.org domain to a third party (cloudflare). Not sure how that is going to go down with the maintainers of the code4lib DNS.

[sdellis]

Thank you for pointing this out @eshellman. This is actually an issue for Code4Lib.org in general, and would be a problem even if we went with the old wiki-approach to conference website hosting. However, since there is no issue queue for code4lib.org, we can leave this open here. I agree that we should be using HTTPS, particularly on the Drupal and Wiki sites for which login info is transmitted. Even though there is no encryption (yet), the new website is actually a step forward being that no personally sensitive data is transmitted through the conference site, and future user-generated nominations will happen over SSL (Google Forms) without requiring an insecure login.

Anyway, it is certainly an issue and I will gladly update the site if the DNS maintainers (@wickr ?) can get SSL set up for the domain. @eshellman would you be willing to be a point person, should they have any questions or need advice?

[eshellman]

Sure, having raised the issue, I'll do what I can to help it along.

Surprised if Github can't support certificates on github.io. I have contacts at Girhub if we want to escalate.

Sent from Eric Hellman's iPhone
1-862-596-0116

On Sep 14, 2015, at 8:44 PM, Shaun Ellis [email protected] wrote:

Thank you for pointing this out @eshellman. This is actually an issue for Code4Lib.org in general, and would be a problem even if we went with the old wiki-approach to conference website hosting. However, since there is no issue queue for code4lib.org, we can leave this open here. I agree that we should be using HTTPS, particularly on the Drupal and Wiki sites for which login info is transmitted. Even though there is no encryption (yet) the new website is actually a step forward being that no personally sensitive data is transmitted through the conference site, and future user-generated nominations will happen over SSL (Google Forms) without requiring an insecure login.

Anyway, it is certainly an issue and I will gladly update the site if the DNS maintainers (@wickr ?) can get SSL set up for the domain. @eshellman would you be willing to be a point person, should they have any questions or need advice?

—
Reply to this email directly or view it on GitHub.

[eshellman]

I think the cloudflare route would be good to try, if for no other reason than it gives us experience that libraries may want to learn from.