Comment by Smerity | Hacker News Reader

Comment by Smerity | Hacker News Reader

Considering the importance of HTTPS to, in Google's words, "[making the] Internet safer more broadly", this seems like a good time to again suggest that Google enable HTTPS for Google Analytics by default[1].

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...

Friendly reminder - there's a free, pro-privacy and open-source solution available:

http://piwik.org/

Sorry to jump in with a tangential reply, but BEWARE of the following!

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.

The Google blog says that TLS is a (presumably positive) ranking signal, they do not state whether leaving the site available unencrypted is a negative signal.

Until they clear up that ambiguity it seems risky to go TLS only for exactly the reason you cite.

If X is a positive signal, then not-X is a negative signal.

That does not follow logically. not-X is typically zero, just like not having an inbound link from a high pagerank page is not a negative. Besides, there are three situation: no-https, both http/https and http-only, which makes your claim that the middle one is negative seem less likely.

Say there are five sites that would normally be returned for a query and they have scores A:20 B:18 C:10 D:8 E:4. The results will look like "A, B, C, D, E". Say none of them support https, and then the search engine adds https as a positive ranking factor worth +3. Site C turns on https, the order still is "A, B, C, D, E". Now site B turns on https, the order is now "B, A, C, D, E".

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.

There is no doubt that https adds a positive value, and not having it would put you at a disadvantage. But that is not what is being discussed here, the question is whether having BOTH https and http is a negative.

> Google treat the http and https versions of a domain as SEPARATE PROPERTIES.

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...

Nope, we followed the instructions to the tee. Straight 301 redirects from http to https, appropriate canonicals on all pages referencing https, and their SEO has seemingly started from scratch - used to be in position 1 for a variety of important keywords and searches, now they're beyond page 10.

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 suggests something else is going on. Please post in the forums with the site details.

Done. Thanks.

The IO talk covers this. There's a few steps involved beyond just sending a 301 such as putting a rel=canonical on the https site.

Yeah, did everything that's possible within the document - although a few steps (Change Of Address) are actually impossible - GWT disallows it within the same domain. Still, SEO in the can.

the default noted there seems fine? if HTTPS, then GA uses HTTPS, if HTTP, GA uses HTTP

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...

It doesn't show up if you have an HTTPS script on an HTTP page.

Browsers only complain if you go from HTTPS=>HTTP, not the other way around, so there is no mixed content warning. The article itself, hosted on Blogger, demonstrates this if you check the source code -- whilst the website is HTTP, it uses JS hosted on HTTPS, with no mixed content issue.

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.

If only..... there are numerous browser bugs out there where HTTP=>HTTPS ends with warnings or failures.

e.g. in IE9, see point 7 on http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...

Reply on news.ycombinator.com