2
$\begingroup$

Many people here recognize something similar to the Google Chrome warning: "This page includes script from unauthenticated sources."

If you look at the code behind the website, you see there are many references to specific protocols, such as http or https. For example:

<script src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML-full"></script>

This should be replaced by a protocol relative URL:

<script src="//cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML-full"></script>

In that case people can happily proceed

Note that this is not just Chrome, also in Internet Explorer. You will recognize it happening to you, if you suddenly get a popup to fill in a CAPTCHA. Or if you create a question and you don't see the buttons on top and the preview below your post.

$\endgroup$
4
$\begingroup$

SSL is not officially supported yet by Stack Exchange. There are proper certificates available now, but there are still parts of the sites that won't work with SSL enabled.

It's also not as simple as simply making the URLs protocol-agnostic, not all the stuff that is included in an SE site supports SSL like that. MathJax for example doesn't support SSL at the same URL as the non-SSL version.

For some more details on how complicated the move to HTTPS can be see this older (4/2013) blog post by Nick Craver:

So, what’s needed to move our network to SSL? Let’s make a quick list:

Third party content must support SSL:

  • Ads
  • Avatars
  • Facebook
  • Google Analytics
  • Inline Images & Videos
  • MathJax
  • Quantcast

Our side has to support SSL:

  • Our CDN
  • Our load balancers
  • The sites themselves
  • Websockets
  • Certificates (this one gets interesting)

Ok, so that doesn’t look so hard, what’s the big deal? Let’s look at third party content first. Note that with all of these items, they’re totally outside our control. All we can do is ask for them to support SSL but luckily we work with awesome people that are they’re helping us out.

  • Ads: We’re working with Adzerk to support SSL, this had to be done on their side and it’s ready for testing now.
  • Avatars: Gravatars and Imgur can support SSL – Gravatar is ready but i.stack.imgur.com where our images are hosted is not yet (we’re working on this).
  • Facebook: done.
  • Google Analytics: done.
  • Inline Images: we can’t include insecure content on the page…so that means turning our images to SSL when i.stack.imgur.com is ready. For other domains images are embedded from we have to turn them into links, or solve via another approach.
  • MathJax: we currently use MathJax’s CDN for that content, but they don’t currently support SSL so we may have to host this on our CDN.
  • Quantcast: done – under another domain.
$\endgroup$
  • $\begingroup$ Okay I understand it's more complicated! :-) However, regarding MathJax. Why not defaulting on https for MathJax? They state explicitly that the c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js address is stable and is perfect to use. Or if you really want to serve http for location.protocol add a small javascript if statement? $\endgroup$ – Anne van Rossum Mar 11 '14 at 13:05
  • $\begingroup$ Gravatar seems by the way used through https, not a protocol relative URL. $\endgroup$ – Anne van Rossum Mar 11 '14 at 13:11
  • $\begingroup$ @AnnevanRossum There is not much point in enabling MathJax if the rest doesn't work yet. I expect SE to switch a lot of stuff at once when they solved all the issues. $\endgroup$ – Mad Scientist Mar 11 '14 at 13:37
3
$\begingroup$

To answer the question you asked about switching to protocol relative URLs:

It simply won't work. (At this time).

The MathJax secure CDN has a different host name from the standard cdn.mathjax.org. This is not simply a problem of MathJax but of their upstream provider. Hence just changing to protocol relative url //cdn.mathjax.org will not solve the problem at all.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .