Hacker News Reader

Comment by floitsch | Hacker News Reader

Disclaimer: I work at Google.

I'm working on the client-side (Chrome) and my knowledge in the server area is therefore limited, but from my understanding this would be really hard.

1. Googlers have access to almost all source code. It would be difficult to hide code that just sends data to an outside entity.

2. Google continually monitors its (internal) bandwidth. This is done to optimize traffic, and detect intruders. A rogue Googler would trigger the same traps that are exist for potential hackers.

3. Google's infrastructure changes. You can't just install a gateway to the NSA and expect it to continue working for a long time. It's not as if user-data was stored in simple text-files.

View on HN

> 3. Google's infrastructure changes. You can't just install a gateway to the NSA and expect it to continue working for a long time. It's not as if user-data was stored in simple text-files.

I think this was the biggest bullshit signal for me (also a Googler, although a recent addition). The high rate of change of Google's infrastructure is astounding when you consider the scale it operates at. The notion of trying to maintain a functional API in secret of the scope they're talking about is laughable without a pretty sizable team.

Impossible? No, probably not, but really ridiculously unlikely.

Google's own apps keep up with the infrastructure changes. Why would an NSA backdoor be any different to just another Google app?

That was sort of my point: those apps require sizable teams and a huge amount of cooperation from dependencies.

If you're operating in secret, cooperation is going to be a hard commodity to come by. I also feel like a sizable team of the sort of people who work at Google would inevitably have leaked something about this before now.

1. What if the source code that does this isn't checked in? You would need to verify that the runtime matches the source code. What if it's not spread across Google's entire codebase, and is just in one of the pieces of infrastructure that almost all of the data hits? (eg. map-reduce clusters)

2. The link out to the NSA would need to be massive as well. Would be very difficult to keep that secret. A 4G modem is not going to cut it.

3. Sure, but I imagine the NSA would be happy to put in the maintenance effort required. The data would have high ROI from their perspective.

>1. Googlers have access to almost all source code.

So what. The world has access to the Linux source code. If I told you there was code in there that sent every byte written to disk to some external entity could you find it? Even if it was clear enough for you to find it, you'd have to be looking for it.

Further, you said yourself that googlers have access to almost all source code. How do you know something else isn't injected in before deployment. Honestly, the vast majority of googlers would have no idea and no way to have any idea if something like this were going on. Especially if people's jobs/freedom depending on no one knowing.

I see a big potential benefit for the NSA to have a spy within google who simply manually pulls and relays info on people at th nsa's request... It doesn't have to be a full Api

Access to sensitive data is strictly controlled, logged and audited, often on a per-case basis ("I need read access to log X for 60 minutes to investigate bug Y"). Even if your hypothetical spy did manage to worm their way into the very, very select ranks of people who can access (say) Gmail data, he'd be busted as soon as the auditors spotted him accessing the files of people he has no reason to access.

Extracting and sending it manually seems incompatible with the idea that they're doing this on a really massive scale.

Also, forwarding all of everybody's gmail would be a lot of data transiting the network. Unexpected traffic equal to all of gmail's normal traffic could be noticed.

Reply on news.ycombinator.com