HTTPS as a ranking signal
googleonlinesecurity.blogspot.com
googleonlinesecurity.blogspot.com
Some webmasters say they have "just a content site", like a blog, and that doesn't need to be secured. That misses out two immediate benefits you get as a site owner:
1. Data integrity: only by serving securely can you guarantee that someone is not altering how your content is received by your users. How many times have you accessed a site on an open network or from a hotel and got unexpected ads? This is a very visible manifestation of the issue, but it can be much more subtle.
2. Authentication: How can users trust that the site is really the one it says it is? Imagine you're a content site that gives financial or medical advice. If I operated such a site, I'd really want to tell my readers that the advice they're reading is genuinely mine and not someone else pretending to be me.
On top of these, your users get obvious (and not-so-obvious) benefits. Myself and fellow Googler and HNer Ilya Grigorik did a talk at Google I/O a few weeks ago that talks about these and a lot more in great detail:
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
StartSSL charge you for revoking that exposed certificate, so your choices are you pay for the revocation, or wait until the certificate expires.
Now if there had been a problem with their signing certificates then I would have expected them to revoke anything affected for free and offer replacements similarly at no cost.
OK, they could have done that anyway (or perhaps offered a discount on the revoke charge) as an good will gesture, but they didn't, so what.
All they claim is to provide free certificates for non-commercial use, and that they do provide. If people read something else into that it isn't because they were deliberately led to.
Though many people picking up a cert without really knowing the infrastructure won't know about revocation infrastructure and such so might have mislead themselves by having not read the Ts&Csm.
Cheap certificates are available, however, they are still not for free. And hosting more than one domain with SSL is a problem too with most hosting providers if you do not want to book additional hostings.
StartSSL is free, and as long as you correctly bundle the intermediate cert (something you have to do with many, many other CA's anyway) your SSL will look no different than a $100+/year one from an A-list provider.
SSL does not come cheap. Certificates have become cheap but you need your own IP, i.e., shared hosting is a problem and hosting becomes more expensive. Certificate sellers, hosters etc. on the other hand are certainly happy about these new business opportunities – although we all know that SSL is inherently broken.
OK, probably still better than nothing! :)
Not anymore, unless you need to support antiquities like IE7 on Windows XP or some ancient Java-based software. SNI works just fine in other cases.
http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers...
It is documented, and all you have to do is install additional packages to enable it, but still, that's not automatic.
SSL is still more expensive, though. For most small content websites (< 500-1000 visitors a day), a shared hosting is sufficient with costs of maybe around 100 USD/year. For SSL, you usually need a more expensive hosting, you have to buy a certificate (OK, available for less than 10 USD if you don't care about it's quality but need mainly browser support without an ugly warning window) and most hosters allow SSL only for one domain in a hosting.
Example:
Shared hosting with 4 WordPress blogs, SSL is active but only to access the control panel since the hoster allows SSL only for one domain. Costs incl. a cheap SSL certificate: 110 USD/year.
All 4 WordPress blogs with SSL, i.e., 4 shared hostings plus 4 cheap SSL certificates: 440 USD/year.
(And caching with a Wordpress plugin is probably no longer possible …)
$29.88/year.
"Base certificate costs $165.00 for three domains"
"After the third domain, each additional domain costs just $45.00"
The multidomain cert supports up to 100 domains, but the cost is $29.88/year for the first 3 included, plus an additional $12.88/year for each additional domain.
Under this price structure, you could have 100 domains covered with one certificate, but it would cost you $1,279.24 per year for that single certificate.
Nobody said otherwise.
3 domains at $30/year is $10/year/domain which is no different than buying individual certs.
The problem was that shared hosting plans didn't support multiple certs, forcing people with a few sites to purchase a plan for each. The multidomain cert solves this problem.
https://www.startssl.com/?app=1
You also don't need "expensive" hosting, it just needs to support SSL which is free from a technical perspective. You no longer need a dedicated IP either.
A cert with a larger key is better than one with a smaller key, but other than that, what's the "quality" of a SSL certificate?
Galopping gargoyles, where do you host that shared costs you $100? A small VPS costs half.
SNI works fine, but when it doesn't it fails horribly. Apache defaults to the first vhost on an IP which can result in non-SNI clients being redirected to the wrong site.
As for XP/IE7 usage, I have a client in an aerospace related industry with most of their customers still on XP/IE7.
Together, they are a quite neat combo and we wouldn't have to pay for certificates anymore.
Lot of critical information is still transmitted through emails.
Quick question. Is the type of certificate also a signal? i.e. self-signed vs plain vs EV?
Once again, self-signed SSL raises the cost of an attack from "basically free" passive monitoring to a much more expensive[1] MitM attack. It's a travesty that apache doesn't simply auto-create a self-signed certificate if it doesn't have one so plain HTTP can be retired forever.
Note: this is about transport security, and the UI presented should not suggest any kind of authentication has been achieved. In firefox, this means not showing the "locked padlock" and other changes usually associated with SSL.
So please, stop undermining the security of the web. We could have been all-HTTPS a long time ago if this nonsense wasn't brought up each time.
[1] and hard to use against everybody simultaneously
But I got one very valid concern. Most websites running some kind of affiliate links and banners. Most of the affiliate links and banners is not on the https platform. This will cause mixed content error message by the browser. First, is using protocol relative urls solve this mixed content error issue? Second, can the non-https affiliate links and banners work correctly(tracking etc) on https website?
I am sure this is the one big hurdle need to be addressed or else more than 50% of the websites in existence will have difficulty to migrate.
Google Analytics is on 50.8% of the top million domains on the Internet, and on 26.96% of a randomly selected 48.5 million domains[1]. Of the 42 billion links analyzed in my research, over 48% of them had Google Analytics on either the start or the end. That's a lot of information leakage.
Anyone who is eavesdropping on HTTP connections to the Google Analytics endpoints can observe a web user's traffic history trivially. This enables simple mass surveillance by specifically looking for these connections and recording them. HTTPS would prevent that.
I should note, whilst there is an option to specifically force SSL in the new Google Analytics[2], it must be enabled by default in order to have a positive impact. We can't rely on the owners of millions of domains to upgrade to ensure an end user's privacy.
[1]: http://smerity.com/articles/2013/google_analytics_and_nsa.ht...
[2]: https://developers.google.com/analytics/devguides/collection...
with firefox adding in mixed-content-complaining not too long ago [1], along with IE having it for a while, and apparantly chrome having it too, its best to match protocol to minimize issues for the user
[1]: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...
To reiterate on the issue with HTTP default, the issue is that Google Analytics being HTTP on all HTTP sites results in a far easier man-in-the-middle target. An attacker only needs to eavesdrop on messages being sent to the Google Analytics endpoints, a far smaller and simpler task than observing and parsing all HTTP traffic.
As such, a default of HTTP even if the website itself uses HTTP is something I'd term a major issue. An ISP or government agency could track the web traffic of an enormous number of users without having to perform any real processing of their own. Admittedly, they'd only see a subset of what Google sees, but that's still a lot.
e.g. in IE9, see point 7 on http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...
Google treat the http and https versions of a domain as SEPARATE PROPERTIES. This means that even if you 301 every http page to https when you transition, all of your current rankings and pagerank will be irrelevant.
You can verify this behaviour for yourself in webmaster tools.
I suppose this is because it's possible to serve up different content on http/s, but really, who does that?!
In short, don't do this until google rethink their stance on what counts as a property. I'm currently nursing a client with a 30% revenue hole as a result of this.
Until they clear up that ambiguity it seems risky to go TLS only for exactly the reason you cite.
Imagine instead they had added "lack of https" as a ranking factor worth -3. The rankings on the page would have changed exactly the same way.
"not having an inbound link" can be thought of as a negative without changing rankings. In the example above, if getting an inbound link from apple.com would move you up 4 points, then if B got a link from apple that would put them at 22 to A's 20. If instead "not having a link from apple" was worth -4 points, then A would be at 16 and B at 18.
That's not quite accurate. It's on a per-URL basis, not properties. Webmaster Tools asks you to verify the different _sites_ (HTTP/HTTPS, www/non-www) separately because they can be very different. And yes I've personally seen a few cases - one somewhat strange example bluntly chides their users when they visit the HTTP site and tells them to visit the site again as HTTPS.
> This means that even if you 301 every http page to https when you transition, all of your current rankings and pagerank will be irrelevant.
That's not true. If you correctly redirect and do other details correctly (no mixed content, no inconsistent rel=canonical links, and everything else mentioned in the I/O video I referenced), then our algos will consolidate the indexing properties onto the HTTPS URLs. This is just another example of correctly setting up canonicalization.
By the way, if you're moving to HTTPS, following our site moves guidelines:
https://support.google.com/webmasters/topic/6033102?hl=en&re...
specifically, the site moves with URL changes:
https://support.google.com/webmasters/answer/6033049?hl=en&r...
But you did say you have a client with an issue. I suspect they either implemented the move to HTTPS incorrectly or something else is going on. Please ask for more help at our forums:
https://productforums.google.com/forum/#!categories/webmaste...
Oh, and you can't do a change of address from http://www.whatever.com to https://www.whatever.com - you don't allow it!
This kind of policy needs to be discussed openly in a suitable forum, e.g. the IETF, not handed down to us by a single company who think they have a right to dictate how the Internet works - and have provably done a horrible job of it in the past (websocket over SPDY, anyone? Yeah, I'm not even sure which version combination of SPDY and websocket I'm talking about either - pick one of the hundred)
There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content. At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
Additionally, discussing things in a forum usually doesn't get things moving. It's coming out with actual advancements like the original Chrome beta with V8 that drives innovation.
I think that the solution to harmful dictatorship should be good alternatives, not more laws to shackle progress to humongous councils.
If your livelihood depends on getting traffic from Google - and a lot of sites do - then even a minor boost may equal a lot of money. Plus the fact that you can never know quite how much, so to be safe you must assume it's worthwhile.
The problem I have with this move is that to me it appears as Google are furthering their own political agenda. They want the web to be https, so they penalise sites that are not. It would be different if the argument was that sites on https tend to hold more quality content than non-https sites, but that doesn't seem to be the reasoning.
I agree that it's dangerous for one entity to have so much power over the web, but I don't see how is this particular signal any different from any other they already use, including those which define the quality of the content.
I don't see how is this any different from any other signal that Google uses to prioritize sites. Forcing small businesses to buy certificates doesn't seem any different than forcing them to have faster websites, for example.
There's an argument for more diversity in search engines, but I don't see how is that specific to this signal.
There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content.
How does it prevent decentralization?
At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
How many people could exploit Heartbleed before it was publicly announced compared to how could sniff traffic on open networks, as countless tutorials explain how to do?
Heartbleed was bad, and OpenSSL is a mess, but let's pretend that unencrypted logins are somehow less bad.
> How does it prevent decentralization? Because only a handful of companies can issue certificates.
How is it screwing up? How are they supposed to run a search engine without prioritizing? "Here's 30000 results, we've randomly sorted them for you"?
Because only a handful of companies can issue certificates.
Fair enough.
The principles behind PageRank are based on unbiased reputation, and provide for a good ranking system (spammers aside). Whatever's thrown on top needs to be carefully considered not to enforce biases towards any group in particular.
Maybe quality of content? If the best info gets buried because they can't afford a cert or don't have a need for one then this hurts the Internet.
I think that's what hnha meant.
they don't just own the signals and sites... the own access to data about your digital life and their algorithms process it as another signal in mining your life.
Google said "don't be evil":
http://www.reuters.com/article/2014/04/25/us-apple-google-la...
Damned if you do, damned if you don't. If the announcement from Google had been that they wouldn't want to use their considerable clout to promote SSL, they'd been criticized for putting their profits over improving the general long term health of the internet.
> have provably done a horrible job of it in the past
That's a single example of a new technology that didn't work out well. How about pioneering certificate pinning for a counter example? Nobody's perfect, if you never break anything it means you never try anything new. Also, websockets and SPDY isn't even close to "dictating" anything, it's a new technology that you can use or not use as you want to.
HTTPS is also used to upgrade connections to stuff like HTTP2 and SPDY which give a substantial improvement to speed, which in turns improves satisfaction. So it makes sense to priotise https sites.
We need to "reset the net", encrypt everything possible, and Google's help is more then welcome.
OpenSSL is not the only SSL stack you know. I run one of my websites on Tomcat so I can benefit from the pure-Java TLS stack it uses (the default one actually). Something like heartbleed is impossible for such a stack.
Right now enabling https is not a one-time investment, since a new certificate has to be requested and installed each time the old one expires.
Computers are supposed to bring down cost and automate tedious tasks, for https the opposite is the case.
It’s worth mentioning that https://www.startssl.com/ does offer free certificates. But without a paid account they last only a year and cannot be issued to wildcard domains, so you quickly end up with a lot of certificates that has to be manually renewed each year.
An effective social network for website trust, combining cryptographic assurances with trust networks that already exist, is my dream.
(Edit: Clarify that the SSL CA model is flawed for the Internet at large, but has many useful applications elsewhere.)
If someone were able to do this and pull the rug out from under the SSL cartel overnight, that would be awesome.
The problem is that it's not only about money. You need to follow certain procedures or browsers and OSs won't include your root certificate.
Shall the transition come and we'd all perceive HTTPS as a default, it's very likely registrars would also offer certificate signing.
I don't know how representative this is, but it looks like StatCounter Global Stats [1] says that slightly over 10% of recorded visitors are still using Windows XP, and many of these users won't have SNI support.
Small websites without strict security requirements often use shared hosting, where SNI is the only practical way to implement HTTPS. Alienating something like 10% of visitors with a security warning is probably not desirable. I imagine this could be a not insignificant roadblock to widespread SSL adoption on small websites, but would like to see more detailed stats.
So far.
Bonus points if they allow a single bad site to tarnish the reputation of all sites under a milti domain cert.
We could have had this from the start if domain names weren't essentially free via domain tasting. But hey, better late than never.
Also even if it was used as a fairly strong ranking signal, if Google still approach their rankings like they do now, spammers might still have sufficient ranking 'weight' to overcome a lack of SSL certificate.
Let's say I am a freelancer, I make website for small restaurant. Until now I could make a website with frontpage, menu and gallery put it on a server and be done with it and collect a monthly fee.
Now, you have to manage the cert, that is say every year re-issue a new cert and invalidate the old. It adds costs. Without much if any benefits for some class of websites.
I host all their sites on a few VPS servers. Some of my contracts require support for IE 7 or IE 8 on Windows XP, and those browsers don't support SNI. So in addition to what you've mentioned - maintaining certificates and losing more of what little money I make on hosting (I basically charge a small % of the VPS cost plus a few hours' worth of work), I now will need to figure out another solution. It seems like a waste to spin up a new VPS for each site that requires XP support.
Clients look at the <10% of visitors coming from Safari and IE7+8 on XP and say "those are potential customers." It's difficult to argue with that.
For now though, I'm going to do nothing new. All indications are that HTTPS is going to be maybe 1% of the ranking, and I know my market well enough that the sites rank highly for local searches - which is the important part. They're responsive and they've all got social media presences, so until SSL is more important for PageRank, I'll wait it out.
But that is to be kept in mind : "But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web."
NameCheap provrides a wide range of certs. I'm sure this is true of other SSL-cert offerings.
Are they all at least adequate for Google's SEO purposes?
It prevents ISPs etc. from being able to profile your traffic, but not Google's, since you're probably visiting a site with Adsense or Analytics running on it anyway.
Through HTTPS, Google is the only one with a profile of your traffic, and your ISP is no longer a competitor to them.
If you're searching for something and roughly the same content is available at safedomain.com vs. notoriouslysketchy.ru, I'd think you'd prefer to be shown the former above the latter. I don't see how this is much different.
If only webmasters had an option to change http:// to https://, the entire move would have been slightly easier as "fetch as googlebot" returns "redirect" since we direct http:// to https://.
Apart from that, we've had no ranking loss for their keywords.
Which was basically my original point, which is that if you want your site to be generally accessible by just typing in the domain name, you still can't just turn off port 80...
Which I guess is why google.com itself is still reachable on port 80.
* Certificates are expensive (to buy _and_ to manage)
* Crypto is hard and there will be a lot of screw up with inadequate certs in the wild for a long time. Just having a certificate does not mean much if it weak or broken.
* Can't help the feeling it's an indirect push for cloud business hence possibly eating the margin of freelancers / ISV
* Security Theatre : a lot of critical information for business still transit by email. Will Google force encrypted emails for the greater good ? I don't think so.
The points you mention are in fact indicators that someone has put care and resources to make their site work more securely, which says a good thing about the site, which google rewards with some points in their algorithm. Makes perfect sense to me that this will somewhat improve the quality of their results. Would you also complain about google using fast response times as a signal because that "forces" people to pay for better servers?
About your security point, google can not do that without loosing 50% of its customers, I really don't understand what that has to do with the rewarding HTTPS being good or bad. Looks like a red herring.
You are just proving my point. Google rewards the richest, those who have the resources as you say. As for care, I would be clad if people were not going to do it for the wrong incentives. Will Google just check if HTTPS is available and reward or will it also check for broken cipher and penalize ?
I am not against HTTPS. Just saying that rewarding HTTPS is not enough. It's worst actually, some will set it up quickly and badly just for the extra ranking points and not the actual security it should be providing.
To me the red herring here is pretending doing it for security. What is the point of HTTPS if I receive my password by mail ? To me email is more important to secure first. Google could perfectly incentive security practices in Gmail without loosing a single customer. I would even settle for just signing instead of encrypting mails.
As for enforcing, HTTP2 (that is SPDY) IS enforcing HTTPS.
IMO, Good HTTPS where it matters is more important then Crappy HTTPS everywhere just is ridiculous and could even be dangerous thanks to a false sense of security.
Oh come on.. if multiplying your ranking by 0.01 (now) means that much to you, then probably you're making enough money you can afford a cert - or you probably have one in place.
Google doesn't care who is it rewarding, google cares about the users that search, they've said that multiple times. And yes, people with better resources build on average better things than people without them.
> I am not against HTTPS. Just saying that rewarding HTTPS is not enough. It's worst actually, some will set it up quickly and badly just for the extra ranking points and not the actual security it should be providing.
Even then, still 10 times better than plain text HTTP so my whole office can see what I'm browsing with a simple console command.
> What is the point of HTTPS if I receive my password by mail ?
Your email inbox should be accessed via TLS, it's something up to you. And while you don't control the origin (nobody can without breaking compatibility) intercepting a message in transit like that if not exactly something most people I know can do. While getting that password over HTTP is almost trivial for anyone sitting around me.
> As for enforcing, HTTP2 (that is SPDY) IS enforcing HTTPS.
The day you can only see a website via SPDY then I would call that enforcing it. Yes if you want to carrot (performance) you have to pass through the hop (security), nobody forces you to eat the carrot.
> IMO, Good HTTPS where it matters is more important then Crappy HTTPS everywhere just is ridiculous and could even be dangerous thanks to a false sense of security.
I really can not get which scenario you are picturing here. Setting it up is not rocket science.
Hum, well I've grown wary of what Google say. Like puting comercial mail in a separated inbox is to help the user. It also happens to indirectly help Adsense.
> And yes, people with better resources build on average better things than people without them.
Does that mean content created by association without a dime for instance is on average inferior ?
I happen to like cooking. I often find websites with great content by word of mouth. They are generally badly ranked because they look like they were done on Frontpage and from Geocities ages. Yet the content is very good and even sometime quite unique. They rank badly because they are not speedy and in beautiful html5. That's elitism. Maybe they should by Adwords.
> Even then, still 10 times better than plain text HTTP so my whole office can see what I'm browsing with a simple console command.
That is one of the few good arguments for HTTPS everywhere : privacy.
> And while you don't control the origin (nobody can without breaking compatibility)
You can encrypt or even just sign emails without breaking compatibility. Put commercial email in a separated inbox is OK but put unencrypted and/or unsigned email in a separated inbox is not ?
> While getting that password over HTTP is almost trivial for anyone sitting around me. > I really can not get which scenario you are picturing here. Setting it up is not rocket science.
Is it better to have open WiFi or WiFi with WEP ? It's the same because WEP is nowadays easily broken by script kiddies with simple tools.
That the scenario I'm picturing here. A web full of weak/broken certs to comply for ranking, people feeling safe (it's encrypted right ?) and script kiddies with trival tools to break the WEP equivalent of weak/broken HTTPS certs.
Granted, maybe I'm over-pessimistic here but the trend annoy me. i don't take Google at face value anymore. You know they excel at long play.
On the bright side, maybe people will use their certs for more than HTTPS ... say mail server for instance :)
Hopefully this will take into account the supported TLS versions and ciphersuites as well. It's sad to see sites that only supports TLS 1.0 and prefers a CBC ciphersuite.
I hope a solution materializes eventually.
We have CDN backed HTTPS for custom sites on BitBalloon (https://www.bitballoon.com) if you're interested in a Github pages alternative that supports SSL.
TL;DR: 2048bit is for the RSA keys, 128/256bit is the the key used in the SSL connection.
During the TLS handshake, your browser and the server do public-key crypto to authenticate each other and share private information without a previously-known shared secret. Because public-key crypto is really, really slow, they then share a small secret (say, 128 or 256 bits), and use that secret as the key for a traditional symmetric encryption algorithm like AES. That's the number you're seeing.
Take a look at https://en.wikipedia.org/wiki/Transport_Layer_Security
so, then really, they are just using their dominance in search to effect change. now, you may agree with the change (they did something similar by announcing pageload time as a signal), but it makes me a little uneasy for google to leverage their dominance in this way even if i happen to agree with the goal.
I've been wanting to switch to HTTPS but have been avoiding it due to significant accumulation of Facebook likes and some +1's. Last I checked, you had to do some big hacks to maintain your Facebook like count. Has anybody found a good way to handle this or do you just have to start over?
Never used them before, but they're just a Comodo reseller, and they take Paypal, so there seemed little that could go wrong.
Has so far gone smoothly, certificate installed, passes the SSL test google mention, https://www.ssllabs.com/ssltest/ so it all seems good
We need something new and better, not to push HTTPs on everything as an imagined stop gap...
That being said though, I do understand that if this was pushed to wider adoption, it would create a higher cost to perform such attacks, for ISP's and three letters?
Quick question though. There was no mention of the type of certs used. Will plain certs be worth less than EV certs?
Hopefully Matt or any other Google search representative here can comment.
Unfortunately, Google is pretty much a monopoly when it comes to online advertising and search that few companies will have a choice in this matter. Google unilaterally forcing them to buy stuff doesn't sit well with me.
(See http://www.quora.com/Is-there-any-way-to-use-HTTPS-on-Heroku... for one possibility.)
They are so far off this side of "sane" it's really not funny.
Security isn't the priority here. Selling cloud is.
Edit: IMHO, same goes for SPDY/HTTP2 by the way
I hope google takes it one step further and updates chrome to show an insecure warning when it detects a password field on the page and it is sent plain over http.
Privacy is always valuable.
I run a site that provides counter information for League of Legends (http://www.championcounter.com/) and I doubt very much my users will benefit at all from me moving over to HTTPS.
Encrypt.
Also some isps have been caught injecting ads into plain text web sites [1]. Do you want more ads on your site that you didn't put there?
[1] http://zmhenkel.blogspot.com/2013/03/isp-advertisement-injec...
Protecting against code injection is actually a fair point though.
Let's see it the other way: any sane webserver allows you to easily activate TLS, and generating a certificate is both free and easy. What's the point of going back to HTTP at this point ?
downside: HTTPS negotiation time overhead (slower website) (as long as we use HTTP 1.1), costs (certificate, technical migration)
all in all i think it's a great move by google, thx
For example there is Comodo "FREE" certificate and the one that costs 64.95 Euros.
What is the catch with the free one?
IPv6 is disturbingly uncommon still...
a lot of my traffic is repeat, so we'll probably do a good campaign to push users off IE8 this fall and officially declare it unsupported in Nov/Dec.
But I agree, it has dwindled rapidly. :-)
Not true. Only devices with regular Google Play store access get shown in those statistics.
The 20% are users with at least regular Wi-Fi access.
I currently use http://xkcd.com for this purpose.
-- Says Google site that forces HTTP.
Wow Seriously? You don't say.
Seems the irony escaped you: announcement was made on a Google site that forces (i.e redirects from HTTPS) you to read it over HTTP.
If you read closely enough it refers to all of Google, not just "the search engine team" or (Google - Blogspot).
Btw, I agree with you, and I think this phenomenon is dumb.
Oh no, I commented on it directly. By the way I noticed you comment on Hacker News, you should probably stop using table-based layouts on your websites.