Ensure links do not downgrade security or break continuity (use path-only or https://)

[mzeinstra]

Problem

CC should want to protect its users when possible, HTTPS is a means to do that. Even though the website that links to already redirect http to https, it is good stewardship.

Description

Some links in the repo refer to external websites using http, this needs to change to https where possible.

Alternatives

We could also make these links protocol agnostic.

Implementation

• create branch
• Search repo on 'http://'
• replace with 'https://' , after check if external site has https
• create Pull request
• ????
• profit

@TimidRobot indicated that they wanted to leave links to / within RDF alone. Could you elaborate @TimidRobot?

[Enigma04]

is this still an issue? if so, I'd be happy to work on it.

[TimidRobot]

HTML

In order from greatest breadth / strongest preference to most specific / least preference:

1. path-only (/, no protocol nor domain)
   • any URLs that are not informative (that are not displayed to users) should be path-only.
   • This will allow the site to be served from other locations (ex. for development, for staging, on GitHub Pages) without compromising functionality
2. TLS/SSL (https://)
   • any creativecommons.org links that informative should use https://creativecommons.org instead of http://creativecommons.org (links without a protocol should remain that way, ex. creativecommons.org)
   • any links to other websites should be evaluated for TLS/SSL support and use https:// wherever possible
   • CC Canonical URLs and HTML Canonical Links
     • They are not used for navigation, so using the full URL won't break development and staging environment navigation
     • Although development and staging environments should be configured to disallow robots, having the full URL will provide another layer of direction and indicate the true location of the legal tools
     • related: [Bug] improve HTML Canonical Link behavior · Issue #241 · creativecommons/cc-legal-tools-app
3. protocol agnostic (//)
   • Better to use TLS/SSL or resolve any environment issues that require HTTP
4. insecure (http://)
   • Bad (not good)

RDF (XML)

• The protocol should not be updated for existing RDF links as http:// is considered canonical. For more information, see:
  • License URIs use http uri scheme, not https · Issue #7 · creativecommons/cc.licenserdf
  • clarify CC canonical URLs · Issue #1874 · IIIF/api

[TimidRobot]

is this still an issue? if so, I'd be happy to work on it.

I will work on this as it involves updating the translations and requires access to Transifex.

[TimidRobot]

The only non-RDF http:// that I see remaining are:

templates/includes/notice_deprecated.html
5-  {{ tool.deprecated_on|date:'Y-m-d' }}: {% blocktrans trimmed %}
6-    Creative Commons has
7:    <a href="http://creativecommons.org/retiredlicenses">retired this legal

templates/includes/deed_body_licenses.html
70:      {% blocktrans %}You must give <a href="#" id="appropriate_credit_popup" class="helpLink">appropriate credit</a></span>, provide a link to the license, and <span rel="cc:requires" resource="http://creativecommons.org/ns#Notice"><a href="#" id="indicate_changes_popup" class="helpLink">indicate if changes were made</a></span>. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.{% endblocktrans %}

Both of these occurrences appear in translated strings. This means that updating them requires updating all relevent translations in both the repository and on Transifex (marking this issue 🔒 staff only)