search

code4lib / 2016.code4lib.org

Code4Lib 2016 Philly
11 stars 22 forks source link

code4lib conf website should set a good example by using HTTPS #94

Open eshellman opened 8 years ago

eshellman commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 commented 8 years ago

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.