You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported by elliott94 on 2015-07-13 07:28
Lots of websites are now modifying their web server config to serve an encrypted version of a website by default. This has two major advantages; search engines including Google have previously explained that sites secured using HTTPS will be displayed before those that don't, which in theory could offer further exposure to the project as a whole. Furthermore, when a user enters their username/password to login to Trac this information is currently sent unencrypted, which presents the possibility of interception (on an unsecured 802.11 network, for example). Is this something that you would consider adding to the website?
The text was updated successfully, but these errors were encountered:
Comment 1 by jteh on 2015-07-13 07:35
If we stay with Trac, we might consider doing it for authenticated users (or at least for the authentication process). However, there's no good reason to do this for unauthenticated users, since there's nothing to secure, so the only thing we'd gain is increased server load. The search engine prioritisation thing isn't sufficient IMO; I didn't even know about this before now. Regardless, this is not likely to happen in the near-term.
It's worth noting that we're considering moving everything to GitHub or similar, which would make this irrelevant.
Reported by elliott94 on 2015-07-13 07:28
Lots of websites are now modifying their web server config to serve an encrypted version of a website by default. This has two major advantages; search engines including Google have previously explained that sites secured using HTTPS will be displayed before those that don't, which in theory could offer further exposure to the project as a whole. Furthermore, when a user enters their username/password to login to Trac this information is currently sent unencrypted, which presents the possibility of interception (on an unsecured 802.11 network, for example). Is this something that you would consider adding to the website?
The text was updated successfully, but these errors were encountered: