6

Stack Exchange loads Javascript required for full site functionality from both local domains as well as third-party domains. Examples of domains from which Javascript is loaded are stackexchange.com, cdn.sstatic.net, cdn.mathjax.org (as well as a few others not necessary for the functioning of the sites), and notably ajax.googleapis.com (for jQuery, which is used for a number of different purposes and without which the sites are nearly unusable for anything but read-only access, with an emphasis on read).

In a perfect world, all client-side dynamically executed content (primarily Javascript) would be loaded over HTTPS to make in-transit tampering with the executable code more difficult. (Granted, in a perfect world, nobody would have second thoughts about everything being encrypted, but let's at least pretend to be pragmatic for a moment.) Since we don't live in a perfect world, and HTTPS support on Stack Exchange remains sketchy, I propose that at least all Javascript loaded from Google's servers is loaded over HTTPS, regardless of the protocol over which the rendered request was made.

While it is true that HTTPS does not come for free in terms of performance, if a single-core PC can do on the order of 100-150 RSA-2048 operations per second, I don't see client-side performance being greatly impacted by loading one specific file over HTTPS. Caching could potentially be an issue, but Google is already serving the jQuery Javascript source code file with a Cache-Control: public response header, which tells a conformant client that the response may optionally be cached. Also, not only is the URL itself versioned (so it is determinable without making a HTTP request whether the file exists in the cache or not), the cache-control directive also includes a max-age specifier and there is an Age header. All this means that browsers have all the information they need to do proper, efficient caching even before establishing the TCP connection to, let alone the TLS session with, Google's servers, once the file has been downloaded even just once.

  • 3
    It might be a better thing to reduce the dependency on any third party sites, especially for active content like script. This content is included with full rights to modify the page at will or to extract any data the user has for the site. Just as a reminder for recent problems with "trustworthy" sites: jquery.com got hacked, Doubleclick/Zedo did malvertising for a full month etc. – Steffen Ullrich Sep 26 '14 at 18:19
  • @SteffenUllrich I see what you mean, and in the longer term, I agree that reducing dependencies to third-party domains is a good thing (it would also make it much easier to use plugins such as NoScript in a sensible way). However, this would appear to be a step in the right direction, and one which I feel can be taken here and now with no serious ill effects on anything. – a CVn Sep 26 '14 at 18:45
  • @SteffenUllrich In all honesty, your proposal would probably make a good separate [feature-request]. – a CVn Sep 26 '14 at 18:51
  • @SteffenUllrich I'd certainly like to see such a request proceed. There's considerable reason to be suspicious of google's mass colelction of user activities on the net, and this is one more mechanism enabling that to happen, which really is quite avoidable in this case. – mc0e Feb 6 '15 at 7:32

You must log in to answer this question.

Browse other questions tagged .