Comment by Smerity | Hacker News Reader

Comment by Smerity | Hacker News Reader

Parent Full thread

I really appreciated this story. It's so hard to make people care about "small" data leaks when they have no idea what many "small" data leaks can lead to. The bug the journalists discovered that revealed Skype's contact list is the perfect example -- the programmer just did something completely "reasonable" (grabbing avatars) that ended up leaking a vital set of information. Imagine if surveillance was your full time job and you did more than just grab the low hanging fruit.

I was also quite surprised by Google's HTTP Maps flaw in HTTPS search. I'd have previously imagined this would be a standard security pentest that Google products would need to go through. Given how pervasive and important Google is to the digital ecosystem, even small flaws can have a profound impact.

I'll again state that this is why I feel so strongly that Google Analytics should be updated to be HTTPS by default[1]. If you hit a non-HTTP site, you're leaking all the information you would send to Google Analytics to anyone that's listening -- it goes across the wire unencrypted. Considering Google Analytics is on 60+% of the top 100,000 domains, this is a lot of information leakage. Referrers, time on page, browser details, operating system details, everything that Google shows a webmaster in Google Analytics also ends up in the hands of the passive observer.

[1]: http://smerity.com/articles/2013/google_analytics_and_nsa.ht...

This was a wake-up call for me. On my desktop browser, I can use SSL, NoScript, etc. to control what's exposed.

But on my phone I'm powerless. How do I know what each app is capturing and transmitting in the clear? If even Google searches don't use SSL, what hope is there for other apps?

In your mobile browser at least Firefox Nightly supports extensions - I have adblock, ghostery, etc. Aside from the privacy benefits it also makes a significant performance difference on my kindle.

https://nightly.mozilla.org/

You can use the stable version too, at least ABP, Ghostery and Self Destructing Cookies works fine on it.

If only it were even just the apps. Check out this blog post by the Tor project and look at what it takes simply securing the OS:

https://blog.torproject.org/blog/mission-impossible-hardenin...

Of particular interest to me was how the captive portal detection reports back to Google everywhere you connect even if everything else is disabled.

I haven't done this personally but you can minimize the risk of interception without really changing anything by going through a VPN. This way all unencrypted traffic is strictly on wired networks.

The VPN secures my data up to the VPN, but it's unencrypted from the VPN to the host.

That might help with the casual Wi-Fi snoop in the coffeeshop, but it's still hoovered up once it leaves the VPN.

Yes, that's true. That's what the situation in the article was, a hostile WiFi access point. I'd say that running a modern platform countermeasures are only useful up to the point that you trust your OS maker and telco. So if you can get your data encrypted until it reaches a major telco's network, then you are almost as safe as if it were all encrypted.

> That's what the situation in the article was, a hostile WiFi access point.

The point of the article was not the hostile AP, but to simulate a pervasive threat:

  we would create a pint-sized version of the Internet
  surveillance infrastructure used by the National
  Security Agency... Porcello would become our one-man
  equivalent of the NSA’s Special Source Operations
  department

Which misses the point of NSA surveillance. Ars knew who they were looking at, and could have multiple people look at that one person's history for whatever they wanted.

The broad surveillance of any practical intelligence apparatus only bothers to do that to target actual subjects of interest, and don't have infinite leeway to not produce results while doing it - i.e. if the NSA produces no useful intelligence on Al Qaeda for a few months, they're looking at budget cuts.

Or to put it another way: how many man hours did they expend on this effort, and how many people do they actually think work for the NSA? It's certainly not "millions".

The NSA does this full-time, with a large staff. They have very elaborate systems designed to automatically pull all this information and organise it into databases for easy lookup.

These guys were manually viewing wireshark dumps. Obviously they're going to spend a lot more time to get the same info when working at such a low level, with no access to any of the automation tools the NSA uses.

You can put on an firewall to block certain apps (requires rooting) but it's true that the measure won't help with "mostly respectable" ones that aren't using https.

On Android, iptables packet filter can be used to control what network connections apps are allowed to make. It is, however, an increased maintenance burden. Recent versions of CyanogenMod also have Privacy Guard pre-installed, which can be used to set granular permissions for apps, such as restricting access to geolocation data.

If you have root then install https://play.google.com/store/apps/details?id=com.googlecode... - at least that way only apps you allow can communicate online.

> I'll again state that this is why I feel so strongly that Google Analytics should be updated to be HTTPS by default[1]. If you hit a non-HTTP site, you're leaking all the information you would send to Google Analytics to anyone that's listening

I fully agree with you but one small little issue here, wouldn't that violate the 'everything over https or nothing over https' rule for what's displayed on a page? In other words, wouldn't your browser balk at this if it were implemented?

Mixed http/https is frowned upon, and rightly so!

Browsers tend to only complain if doing so breaks security, such as using Javascript from a HTTP source on a HTTPS page: the JS could be swapped out by a man-in-the-middle. If you use or communicate using HTTPS on a HTTP page, there's no real issues.

You can actually force Google Analytics to use HTTPS on a HTTP page[1] with _gaq.push(['_gat._forceSSL']) but it's not the default. If it's not the default, it's not going to be used heavily across the hundreds of thousands of pages using Google Analytics. Privacy death by a thousand cuts.

[1]: https://developers.google.com/analytics/devguides/collection...

That's something that might be fixable with a user-script or a browser plug-in?

Maybe something for the likes of ghostery or adblock to implement?

Generally, however, the problem is concern over leaking sensitive data to insecure connections (e.g. load an HTTPS URL but your HTTP referer header on all your insecure HTTP requests tells people your URL).

I don't see any issue with loading an HTTP site and then making an HTTPS request to Google Analytics. It's better to secure part of an insecure page than to leak part of a secure one.

mixed content warnings only appear if http content is included on an https page

Ah ok neat, I got bitten by that once in the past, did not realize that the other way around is fine. Now that I think about it that's kind of logical because you can't really give more away than you are suggesting to the user, only less. Thank you.

> If you hit a non-HTTP site, you're leaking all the information you would send to Google Analytics to anyone that's listening

This is why I'm a fan of RequestPolicy.

> I'll again state that this is why I feel so strongly that Google Analytics should be updated to be HTTPS by default

That's an incredible waste of bandwidth for no improvement in privacy whatsoever. If HTTPS pages were including GA over HTTP, then yes, this would be an issue, but you're already requesting the page over HTTP, if you're getting GA over HTTP. There's simply no advantage whatsoever -- for privacy, security, or anything else -- to using HTTPS for this script. It doesn't make any attack harder in any way, shape, or form -- it just makes pages slower and more expensive to load.

The only significant overhead that TLS imposes is in the initial (public-key) handshake, and even then the overhead is primarily for high-traffic servers. Once a TLS (HTTPS) session has been established, it's essentially free to continue using it. Given that Google Analytics is basically everywhere on the web (and thus you can imagine your session would be fairly persistent as you're surfing around) and that Google can afford the server overhead of establishing TLS connections, I think your objections are unfounded.

Of course, you may still be right in that it adds no privacy, but I wouldn't call it an "incredible waste" (particularly not of bandwidth), since the cost is really quite low.

The cost is quite low for a single connection, but given that Google Analytics is on a huge portion of sites, that adds up really, really quickly. In addition, the additional roundtrips required for the TLS handshake is killer on a high-latency connection, seriously slowing things down for mobile devices.

Given that there really is no privacy benefit, I can't imagine why you would take on that overhead; Google clearly agrees, or they would've turned on HTTPS by default.

There is a major improvement to privacy in the larger scale: the Google Analytics servers are a funnel for a substantial percentage of all web traffic. Read the write-up I linked to, specifically "How does that help the NSA?".

Usage of unencrypted Google Analytics + Google cookies[1] means that you don't need to eavesdrop on individual connections, just one small set: the endpoints to the Google Analytics servers.

Hence, the NSA or other large entities have an economical way to tap a large portion of web traffic.

[1]: http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10...

> Usage of unencrypted Google Analytics + Google cookies means that you don't need to eavesdrop on individual connections, just one small set: the endpoints to the Google Analytics servers.

Admittedly, it is a smaller number of endpoints than monitoring every site in the world (that much is obvious), but it's not one or two -- they're all over the place.

But even ignoring that, it really comes down to one thing: Google Analytics can't possibly make an HTTP site any less secure or less private -- you're sending a postcard with your personal details on it a million times a second! It may in some situations make it slightly (very slightly) easier for someone to snoop on a tiny bit of info about your traffic, but the fix for this isn't to make that harder, it's to make it harder to snoop on your traffic entirely. We already have a solution for this: ubiquitous TLS.

IMO, this is slapping a band-aid where your arm used to be; trying to increase the privacy of HTTP sites is a fool's errand and a complete and utter waste of time.

Using HTTPS be default may encourage more people to adopt it.

Reply on news.ycombinator.com