Given recent developments on the web and the fact that the HTTPS protocol hasn’t been rolled out as quickly as some (such as Google) would have liked – because the transition to full HTTPS can be long, complex and costly, particular for small sites – we have decided not to make HTTPS obligatory on Hypotheses for the time being.
At present an obligatory shift to HTTPS would cause various technical problems for blogs using content hosted on sites that do not use the HTTPS protocol.
However, it is possible that in the medium term the HTTPS protocol will become the only protocol in use on the web. We are not ruling out this option, and the advantage is that we now have the technical tools needed to shift Hypotheses to HTTPS when that becomes necessary. This is an ideal situation both for the time being and for the future, guaranteeing a user-friendly experience for our users as well as the security and stability of the platform. It should also be noted that the HTTP and HTTPS protocols currently coexist on Hypotheses. If you have a user account on one or several of the platform’s blogs, you are automatically browsing the platform using the HTTPS protocol, regardless of which Hypotheses blog you are on.
When you are browsing the Internet, different protocols enable your browser (Mozilla Firefox, Google Chrome, etc.) to communicate with the server that hosts the websites you wish to consult. Most of the time, this is an HTTP protocol.
However, this protocol does not guarantee optimal security in terms of the confidentiality of the data that you receive and send when you are browsing the Internet. To remedy this, the HTTP Secure (HTTPS) protocol is now the preferred protocol. Increasingly widespread, the HTTPS protocol is becoming the standard protocol on the Internet, and it is becoming increasingly urgent and important to adopt it. In addition, the main browsers now interpret HTTPS and give it priority wherever possible. But the browser is only one side of the story. In order to benefit from the security offered by the HTTPS protocol and ensure seamless communication between your browser and websites, it is also necessary for those websites to adopt this much-vaunted HTTPS protocol.
For this reason, and as part of a general drive to maintain the security and stability of platform, we have decided to follow this development by exclusively offering the HTTPS protocol on Hypotheses. This improvement will make using Hypotheses a safer experience for both you and your readers.
Nevertheless, this development will be accompanied by some collateral effects, which we are aware of and will strive to minimize, but which may have an impact on some of you.
For one thing, the exclusive use of the HTTPS protocol will mean that external content that uses the HTTP protocol and is included on your posts will no longer be supported by Hypotheses. The explanation for this is as follows: when a website using the HTTPS protocol includes external elements taken from a site using the HTTP protocol, this is known as mixed content. For example, this will be the case if you publish on your Hypotheses blog (which will now be using the HTTPS protocol) a video hosted on a platform that responds only to the HTTP protocol. The increasingly systematic use of the HTTPS protocol by web browsers means that mixed content is blocked in order to guarantee the security of your browsing experience and data. What this means, in concrete terms, is that in the above example your Hypotheses research blog will remain accessible, but your readers will not be able to consult the video you have integrated onto the blog. The same is also true for your posts, pages and widgets, regardless of the type of external content you wish to integrate (videos, audio recordings, images, exportable PDF or digitized text readers, etc.).
You may notice that various methods exist to allow you to circumvent the block applied by your browser and thus display some content using the HTTP protocol, even on an HTTPS page. However, please bear in mind that we strongly advise against using this option, because the HTTP protocol is not secure. What’s more, removing the block applied by your browser does not necessarily mean that you will be able to view the unsecure content, because this depends on the browser you are using as well as the version, the type of mixed content and the website on which it is hosted. Lastly, the HTTPS protocol is on course to become the standard protocol and will replace the HTTP protocol in the not-too-distant future. It is not worth using every possible means to continue to use content that will soon be obsolete unless it also evolves with the times.
As a consequence, if you notice that content is no longer being displayed on your blog, you will need to do the following:
First, check that the problem definitely stems from the use of the HTTP protocol, by looking at the code of the element you have integrated onto your blog. For example, the following code corresponds to the integration of a video using the HTTP protocol, which therefore will not be displayed on your blog:
<iframe src=”http://www.canal-u.tv/video/ehess/embed.1/la_fonction_critique.19056?width=100%&height=100%” width=”550″ height=”306″ frameborder=”0″ scrolling=”no”></iframe>
Some content responds to both the HTTP protocol and the HTTPS protocol. You can therefore try to manually replace HTTP with HTTPS in your code. In our example, this would give:
<iframe src=”https://www.canal-u.tv/video/ehess/embed.1/la_fonction_critique.19056?width=100%&height=100%” width=”550″ height=”306″ frameborder=”0″ scrolling=”no”></iframe>
In the above example, this solution works and is all that is needed to ensure that the video will be displayed on your blog.
If you are confronted with this situation, please contact us at hypotheses[at]openedition.org and indicate the address of the content in question. We will then strive to ensure that the users of your blog can automatically use the resource via the HTTPS protocol, which will save them from having to manually change HTTP to HTTPS each time they wish to use that source.
In other cases, when the HTTPS protocol is not supported by the website that hosts the content you are trying to integrate onto your blog, the operation outlined above will not work.
Unfortunately, the only solution in these cases is to choose a different source, one that uses the HTTPS protocol. If the content in question is essential to your blog, you will need to contact the people responsible for hosting it to ask if they are planning to switch to the HTTPS protocol. You can also contact us, indicating the resource in question, and we will relay your request to the relevant hosts.
At all events, and although we can do no more than ask these hosts to cooperate, it should be borne in mind that the switch to HTTPS is a general trend and an important development of the Web. For this reason, all trustworthy hosts will decide to opt for this protocol sooner or later, depending on their technical constraints and capacities.
What’s more, this type of case should be relatively rare given that the most well-known and frequently used hosts (YouTube, Dailymotion, Archive, ISSUU, OpenStreetMap, etc.) already use the HTTPS protocol.
In the future, so as to avoid any inconvenience, we recommend that you integrate external content onto your blog only if it uses the HTTPS protocol. This applies to videos and audio recordings, as well as to flickable books integrated onto your blogs via exportable readers, and to images used to illustrate your posts that are stored on external platforms which use the HTTP protocol exclusively. As for images, wherever possible it is a good idea to get into the habit of transferring them to the media library on your blog, so that you can access them easily and securely to illustrate your posts. This will also ensure that you have permanent access to these files (which will be stored on our servers), which is often not the case when you use an external provider. If you proceed like this, just be sure you own the legal rights to use these images.
Also, when you want to illustrate a post, we strongly recommend you not to use the “Add media > Insert from URL” option, because it will create a link to an image located on a server which you’re not sure it will last for a long time or support the HTTPS protocol.