Comment by godelski | Hacker News Reader

Comment by godelski | Hacker News Reader

Parent Full thread

> Cell phone tower data has been used for a decade now in pretty much the same way.

I was mad then. I'm more mad now. Stop these arguments because it isn't like one implies the other. And who the fuck cares if someone wasn't but is now. What's the argument, that you're a hipster? That's not solving problems. I don't want to gatekeep people from joining the movement to protect rights. I don't care if they joined as a tin foil hat or just yesterday after having literally been complacent in these atrocities. If you're here now, that's what matters.

> Privacy has been dead for a long time. The worst part is people don’t care.

Bull, and bull.

There are plenty of people fighting back. I'm pretty sure me getting ads in languages I don't speaks is at least some good sign. Maybe I can't beat the NSA, sure, but can I beat mass surveillance? Can I beat 10%? 50%? 80%? 1% is better than 0% and privacy will die when we decide everything is binary.

People care. People are tired. People feel defeated. These are different things. If people didn't care Apple (and even Google) wouldn't advertise themselves as privacy conscious. Signal wouldn't exist and wouldn't have 50 million users. It's not time to lay down and give up.

> mingus88 36 minutes ago | parent | context | flag | on: Google Ordered to Identify Who Watched Certain You...

Cell phone tower data has been used for a decade now in pretty much the same way.

Did you happen to pass by a cell tower in a major city around the time a crime was committed? We all have.

Well, your IEMI was included in a cell tower dump. Probably dozens of times.

Did you happen to drive your car over any bridge in the Bay Area lately? Did a municipal vehicle pass you and catch your license plate with their ALPR camera?

Guess what? Your name went through a database of an LEO search if they wanted to find a perp for that time/location.

Privacy has been dead for a long time. The worst part is people don’t care.

> The Snowden files changed nothing.

They didn't change enough, but that isn't nothing.

> > The Snowden files changed nothing. >They didn't change enough, but that isn't nothing.

The biggest change IMHO was the entire industry got off their collective assets to finally move to HTTPS.

I wonder who's going to have to end up hiding out in a US-hostile part of the world for us to read this part of the cloudflare FAQ: https://developers.cloudflare.com/ssl/troubleshooting/faq/#w...

The world’s largest MITM

Lol, I'm a bit slow ... some USA TLA runs Cloudflare, right?

tin foil hat time, but who do you think the MITM is for?

Tech bros love it. And tailscale. And saas as a whole. Data sovereignty means you can’t be kind by the adtech industry so it’s not cool.

Calling out tailscale here is odd considering it's peer-to-peer and encrypted.

With keys controlled by a central entity

do you have a source for that?

Tailscale [0] says the private keys never leave the device.

“Security

Tailscale and WireGuard offer identical point-to-point traffic encryption.

Using Tailscale introduces a dependency on Tailscale’s security. Using WireGuard directly does not. It is important to note that a device’s private key never leaves the device and thus Tailscale cannot decrypt network traffic. Our client code is open source, so you can confirm that yourself.”

0. https://tailscale.com/compare/wireguard

That is true as far as it goes, but how does your node learn the public keys of the other nodes in your tailnet? My understanding is that they are provided by the coordination server, so you have to trust that the public key the coordination server gives you is actually the one for your peer device.

Tailnet lock helps mitigate this by requiring that node public keys are signed by a trusted signing node, but it isn't bulletproof.

Public key cryptography doesn’t work like that. If you were given wrong public keys you wouldn’t be able to connect to start with.

> Public key cryptography doesn’t work like that

Like what? I'm saying both sides of the connection would be given the wrong public keys by the coordination server. The private keys of which would be held by a MITM.

To add to that, they also provides Tailnet lock [0], which protects from the only way the coordination server can mess with the tailnets, by connecting unauthorized nodes.

[0] https://tailscale.com/kb/1226/tailnet-lock

Not sure what the issue is with Tailscale, especially since you can self-host Headscale server locally to get the same effect.

Headscale is fine. With tailscale they control the deployment of public keys to devices, and can thus deploy anything they want to.

Good to know.

Have they ever deployed anything they want to devices?

The direction you're heading in sounds very similar to the arguments that may have been made pre-Snowden about mass-surveillance.

See https://github.com/justjanne/stickers/blob/main/designs/ssl%...

a single encryption is for the stone age.

if [pecadillo] must remain secret when your nieghbour is investigated for [crime?] then encrypt at least twice, and obfusicate the original message

> The biggest change IMHO was the entire industry got off their collective assets to finally move to HTTPS.

And then promptly moved most things behind cloudflare, which is MITMing everything, undoing the benefit of HTTPS.

Remember "SSL added and removed here!"? Now it happens at cloudflare.

I thought this was driven by ISPs inserting their own ads in normal HTTP.

…no, it was definitely “HTTPS added/removed here”

Had nothing to do with Snowdon but with Google ranking algo changes. Google has a commercial interest of hindering competitors in the add brokering market from observing info on the wire.

It had everything to do with Snowden. Source: I was at Google at the time he started leaking.

Before Snowden encryption was something that was mostly seen as a way to protect login forms. People knew it'd be nice to use it for everything but there were difficult technical and capacity/budget problems in the way because SSL was slow.

After Snowden two things happened:

1. Encryption of everything became the companies top priority. Budget became unlimited, other projects were shelved, whole teams were staffed to solve the latency problems. Not only for Google's own public facing web servers but all internal traffic, and they began working explicitly on working out what it'd take to get the entire internet to be encrypted.

2. End-to-end encryption of messengers (a misnomer IMHO but that's what they call it) went from an obscure feature for privacy and crypto nerds to a top priority project for every consumer facing app that took itself seriously.

The result was a massive increase in the amount of traffic that was encrypted. Maybe that would have eventually happened anyway, but it would have been far, far slower without Edward.

You were at Google at the time, but your memory of the ordering of events is off. Google used HTTPS everywhere before Snowden.[1][2] HTTPS on just the login form protects the password to prevent a MITM from collecting it and using it on other websites, but it doesn't prevent someone from just taking the logged in cookie and reusing it on the same website. That was a known issue before Snowden, and Google had already addressed it. Many other websites, including Yahoo, didn't start using HTTPS everywhere until after Snowden.[3] I know because this was something I was interested in when using public WiFi points that were popping up at the time. I also remember when Facebook moved their homepage to HTTPS.[4] Previously, only the login form POSTed to an HTTPS endpoint, but that doesn't protect against the login form being modified by a MITM to have a different action for the MITM to get your password, rendering the whole thing useless.

What changed after Snowden was how Google encrypts traffic on its network, according to an article quoting you at the time.[5]

[1]https://gmail.googleblog.com/2010/01/default-https-access-fo...

[2]https://googleblog.blogspot.com/2011/10/making-search-more-s...

[3]https://www.zdnet.com/article/yahoo-finally-enables-https-en...

[4]https://techcrunch.com/2012/11/18/facebook-https/

[5]https://arstechnica.com/information-technology/2013/11/googl...

An important clarification is that the leaks about NSA snooping on Google motivated end-to-end encryption between all pairs of Google internal services. It was a technical marvel, every Stubby connection had mutual TLS without any extra code or configuration required. Non-Stubby traffic needed special security review because it had to reinvent much of the same.

People even got internal schwag shirts made of the iconic "SSL added and removed here" note [1]. It became part of the culture.

Over a decade later I still see most environments incur a lot of dev & ops overhead to get anywhere close to what Google got working completely transparently. The leak might have motivated the work, but the insight that it had to be automatic, foolproof, and universal is what made it so effective.

[1] https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-her...

A minor quibble; iirc it was only connections that crossed datacenters that were encrypted. RPC connections within a cluster didn't need it, as the fiber taps were all done on the long distance fibers or at telco switching centers.

But otherwise you're totally right. I suspect the NSA got a nasty shock when the internal RPCs started becoming encrypted nearly overnight, just weeks after the "added and removed here" presentation. The fact that Google could roll out a change of that magnitude and at that speed, across the entire organization, would have been quite astonishing to them. And to think... all that work reverse engineering the internal protocols, burned in a matter of weeks.

According to the reporting at the time, the NSA has shut down the email metadata collection program, which was the only leaked NSA program that parsed data on those taps, back in 2011; so the reverse engineering work was burned by an interagency review two years prior to Google's cross-datacenter encryption work.

They were tapping replication traffic on a database that included login IP addresses. I remember it well because it was a database my team had put there.

I missed that leak. Any chance you have a link for me to fill in my gap?

Slide 5 (Serendipity - New protocols) in this presentation:

https://github.com/iamcryptoki/snowden-archive/blob/master/d...

It's heavily redacted but the parts that are visible show they were targeting BigTable replication traffic (BTI_TabletServer RPCs) for "kansas-gaia" (Gaia is their account system), specifically the gaia_permission_whitelist table which was one of the tables used for the login risk analysis. You can see the string "last_logins" in the dump.

Note that the NSA didn't fully understand what they were looking at. They thought it was some sort of authentication or authorization RPC, but it wasn't.

In order to detect suspicious logins, e.g. from a new country or from an IP that's unlikely to be logging in to accounts, the datacenters processing logins needed to have a history of recent logins for every account. Before around 2011 they didn't have this - such data existed but only in logs processing clusters. To do real time analytics required the data to be replicated with low latency between clusters. The NSA were delighted by this because real-time IP address info tied to account names is exactly what they wanted. They didn't have it previously because a login was processed within a cluster, and user-to-cluster traffic was protected by SSL. After the authentication was done inter-cluster traffic related to a user was done using opaque IDs and tokens. I know all about this because I initiated and ran the anti-hijacking project there in about 2010.

The pie chart on slide 6 shows how valuable this traffic was to them. "Google Authorization, Security Question" and "gaia // permission_whitelist" (which are references to the same system) are their top target by far, followed by "no content" (presumably that means failed captures or something). The rest is some junk like indexing traffic that wouldn't have been useful to them.

Fortunately the BT replication traffic was easy to encrypt, as all the infrastructure was there already. It just needed a massive devops and capacity planning effort to get it turned on for everything.

The first two links are about Gmail and personalized results in web search specifically. Even as late as 2011 SSL being activated for a product was treated as unusual enough to write blog posts about, and it was up to individual projects whether or not to activate it and how to trade off the latency costs.

You're right that I might be mis-remembering the ordering of things, but I'm pretty sure by the time Snowden came around the vast majority of traffic was still unencrypted. Bearing in mind that lot of Google's traffic was stuff you wouldn't necessarily think of, like YouTube Thumbnails, map tiles and Omaha pings (for software update). Web search and Gmail by that point made up a relatively small amount of it, albeit valuable. Look at how the Chrome updater does update checks and you'll discover it uses some weird custom protocol which exists purely because at the time it was designed Google was in a massive LB CPU capacity crunch caused by turning on SSL for as many services as possible. Omaha controlled the client so had the flexibility to do cryptographic offload and was pushed to do so, to free up capacity for other services.

> What changed after Snowden was how Google encrypts traffic on its network, according to an article quoting you at the time.[5]

That also changed and did so at enormous speed, but I'm pretty sure by June 2013 most external traffic still didn't have TLS applied. It looks like Facebook started going all-SSL just 8 months before Snowden.

I had completely forgotten about YouTube. I think it switched to https video serving post-Snowden, but I can't find the announcement.

Edit: Here it is. Only 25% of YouTube's traffic was encrypted at the start of 2014. https://web.archive.org/web/20160802000052/https://youtube-e...

Right, I remember (as an outsider to google) the push for https coming after Firesheep [1] and the google research on the actual CPU cost of https [2], both in 2010. Snowden's revelations came in 2013.

[1] https://en.m.wikipedia.org/wiki/Firesheep [2] https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...

That's nice and all, but the "why" is more important than the "what".

Google was driven not out of some panicked rush to protect user privacy, but to protect Google's collection and storage of user data.

Google has 10+ years of my email. It doesn't treat that like Fort Knox because it gives a shit about my privacy; it treats it like Fort Knox because it wants to use that for itself and provide services to others based off it.

You do know that Google was heavily seed-funded by the NSA, right?

Google might just be the biggest advocate of https out there, certainly (from my recollection) post Snowden. There has been a lot of progress made over the years.

https://transparencyreport.google.com/https/overview

https://transparencyreport.google.com/safer-email/overview - transmitting email with some form of encryption is probably a bigger and completely unseen problem that is similar

There was literally a PowerPoint slide in the released docs implying they had backdoored Google's internal servers.

>Stop these arguments because it isn't like one implies the other. And who the fuck cares if someone wasn't but is now. What's the argument, that you're a hipster?

That we are nothing in the ocean of people who don't care. Someone upended their entire life to whistleblow on the government doing it as hard proof and no one cares (from a statistical POV, not a "literally 100% of the population" way).

They cared more about the boston bombing the month prior, which while tragic is a statistical molecule compared to the impact of what Snowden revealed.

>There are plenty of people fighting back.

This can be a game of numbers, but it isn't. This can be a game of power, but it isn't. Not enough people are fighting back and not enough powerful people are fighting back.

>People care. People are tired. People feel defeated. These are different things

well it sounds like they gave up. Different words, samae results

Reply on news.ycombinator.com