Journal Articles

CVu Journal Vol 27, #6 - January 2016 + Programming Topics
Browse in : All > Journals > CVu > 276 (7)
All > Topics > Programming (877)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: "HTTPS Everywhere" considered harmful

Author: Martin Moene

Date: 03 January 2016 21:18:43 +00:00 or Sun, 03 January 2016 21:18:43 +00:00

Summary: Silas S. Brown considers an unintended cost of security.

Body: 

You’re not rich enough to look at the Internet. Google has banned you. That's an exaggeration (well I had to catch your attention somehow, didn't I?) but it may reflect what some feel as they cope with the collateral damage caused by Google’s ‘HTTPS everywhere’ drive.

With the overheads of certificate validation, loading a Web page over ‘secure’ HTTPS can cost the best part of a megabyte in data transfers, even if the underlying page size is only a few dozen kilobytes. Extra data transfers slow things down, and if your Internet connection is in any way ‘wobbly’ (such as if you’re using mobile data, especially if it’s 2G-only which runs at a lower priority than voice traffic, or if you’re stuck with a particularly poor-quality ADSL service) then it might make the difference between being able to load the site and not being able to load the site. (With HTTPS you can’t continue where you left off when your link comes back up.) Add to this the cost considerations if you have a limited data plan, not to mention the battery life and environmental considerations associated with the extra processing needed, and you can see why it makes sense not to use HTTPS except for pages that really need to be ‘secure’, such as a logged-in session after a user has provided a password or other credentials.

I agree it is a mistake to use HTTPS for the login itself but then issue an insecure cookie to identify the user to HTTP pages, as this can be stolen by anyone sharing the same IP address, as demonstrated by FireCrack and other ‘profile-grabbing’ attacks over shared WiFi. HTTPS should be used for the whole session after login. But that doesn’t automatically mean HTTPS should be used for normal public web pages that you don’t even log in to see.

You might have noticed an increasing number of websites such as news sites using HTTPS only. Before I realised the more likely explanation, I thought they were merely echoing WikiMedia’s decision to go all-HTTPS in the light of Edward Snowden’s publicity about NSA data monitoring, so that it’s harder for authorities to determine which of their pages are being accessed (which in practice might mean an authority bans an entire site rather than specific pages of it, but I won’t go into that). However, it did strike me as a bit odd that an average news site would go out of their way to protect their readers’ choice of articles from being monitored, particularly given the added costs to them of running HTTPS servers.

And then I saw Google’s 2014 announcement [1] that the use of HTTPS is now going to be used as a ranking signal. Because Google engineers like the idea of having HTTPS everywhere, they are ‘encouraging’ other websites to move to it by rewarding them with higher rankings in Google search results. Ah, so that’s why everyone seems to be jumping on the bandwagon.

Some have tried to make business decisions like ‘the extra cost of hosting HTTPS is worth a 1% increase in ranking’. But how can you be so sure? What exactly is a 1% increase anyway? Few people understand the exact relationship between a given amount of change in one component of the ranking algorithm and the actual effect on one’s listing position, let alone on how much resulting traffic one gets. And let’s not even try to go into considerations of how much of that traffic is actually profitable to a business, or how much of it is from people who are interested enough to stay and read what you have to say instead of deciding within seconds that they’ve been misdirected by the search engine and surfing off somewhere else.

As the situation is so ill-understood, it seems to me that people are jumping to the whims of Google engineers in at best a semi-rational fear due to Google’s vague threats of reprisals. (It’s even more vague when they say the weight of the HTTPS ranking signal might be increased by an unspecified amount at an unspecified time in the future.) That reminds me of the way things are supposed to work in certain countries of this world whom I daren’t name here or they might ban ACCU in retaliation. (Perhaps we’d better not make the full text of this article visible to Google: they might find a way to down-rank us for saying something negative about them. See the similarity?)

HTTPS when you have to log in might be good, and even for public pages it might be arguably a good thing to offer the user a chance of accessing the site over either HTTPS or HTTP according to their wishes, but forcing users to use HTTPS everywhere for public read-only pages (without even giving them an HTTP fall-back option) just slows things down for everybody, consumes more resources, and might lose visitors (like me when I’m on my mobile in a patchy-signal area).

If Google rewards HTTPS too much then they will essentially be giving a boost to corporate sites that are well-heeled enough to afford it, at the expense of academic and non-profit organisations that often aren’t, not to mention hobbyists and staff who do not have their own domains but are at the mercy of whatever server their user pages are stored on. While a reward of HTTPS might help to down-rank some (but not all) ‘spammy’ search results, it’s almost certainly a case of ‘throwing the baby out with the bath-water’, since a lot of good-quality online information is not provided by well-heeled corporations.

If Google really does end up boosting HTTPS so much that sites which don’t have it end up being seriously down-ranked for no good reason, even though they have better information, then I hope that causes the population at large to realise that Google search is not as good as it used to be and to try some other search company instead. That’s what Google would arguably deserve if they tweak this knob too much. So I wouldn’t be too worried about this in the long term: if Google goes crazy then it will no longer be cause for concern.

Meanwhile, perhaps the best way to make Google engineers realise the error of their ways is for as many people as possible who have good worthwhile information online to stand firm with the HTTP protocol and do not kowtow to Google’s whim of having it on HTTPS. We might be able to make it obvious to them that too much of a boost to HTTPS would down-rank good stuff. Since Google’s engineers are particularly interested in technical material, I would highly recommend anyone who has good technical material online to stand firm for HTTP so as to show Google they can’t get away with writing that off too much. Each of our sites may be small, but if enough of us do it then they might see us. That is, as long as Google engineers don’t end up ignoring all information that’s not on the likes of Stack Overflow.

As for me, I have tweaked my Web Adjuster [2] so it can proxy HTTPS onto plain HTTP. With suitably frightening ‘you do realise this trashes your security’ warnings, this could be a ‘lifesaver’ in some mobile situations when a site is using HTTPS unnecessarily. And if anybody ends up not finding my code just because I don’t have an HTTPS site, I refuse to make that my problem: they should be better at finding things. I’m not giving in to vague threats about HTTPS just yet!

References

[1] https://googleonlinesecurity.blogspot.co.uk/2014/08/https-as-ranking-signal_6.html

[2] http://people.ds.cam.ac.uk/ssb22/adjuster

Notes: 

More fields may be available via dynamicdata ..