4 ms·

If you were an engineer working at Google on one of the services that handles, say, location data from phones, how difficult would it be for you to go into the

by 13of40 8y ago

If you were an engineer working at Google on one of the services that handles, say, location data from phones, how difficult would it be for you to go into the environment and find a specific person's location history? Also, what logging or other audit trail is there for that access?

AlexCoventry 8y ago
FWIW, the ex-googlers I've asked about this claim it would be very hard for an individual to do this surreptitiously. One even claimed that Larry Page would probably get caught if he tried.
anonuser123456 8y ago
From the Google people I've talked to, the easiest way to get fired at Google is to inappropriately gain access to user data. And yes there is anaudit trail on accessing that stuff.
arkem 8y ago
Google has amazing controls and audit capabilities around access to customer data. When I worked on the security team there the number of people who could access a specific person's data without an audit record and an alert being triggered was zero.
- 13of40 8y ago
  Is that for someone going through the user interface, or is it a fundamental feature of the database (or whatever)? In other words, is there no case where someone could log into a server and see some PII in a debugger or a direct query without being detected?
  - arkem 8y ago
    This is both for people using tools and people accessing servers and databases directly. Logging into production servers is audited and triggers alarms. There's basically no-one who has "root" level access to a large number of boxes (when I left in 2013 there were only a handful of people who could login to arbitrary boxes and systems were being built so that their access would no longer be necessary). Logging into a server that holds live data would be investigated and so would running a custom query against a production database. The goal was to have it basically impossible for an engineer or admin to directly access data on boxes to force people to use the tools. The tools themselves had a great permission system as well as a way for users to elevate their permissions in emergency (triggering an investigation). It worked well because it was also easy to create dummy databases to develop on (for example by requesting a database extract of your own location data). In my career to date I have yet to see a more privacy conscious / secure approach to handling customer data.
- shazow 8y ago
  +1 to what arkem said. If I had to trust a company with private data, there is no other company I would trust more to keep it safe from rogue employees and accidental leaks/hacks.
fouc 8y ago
I wonder about facebook also, in terms of access/audit trails.

by 13of40 8y ago

AlexCoventry 8y ago

FWIW, the ex-googlers I've asked about this claim it would be very hard for an individual to do this surreptitiously. One even claimed that Larry Page would probably get caught if he tried.

anonuser123456 8y ago

From the Google people I've talked to, the easiest way to get fired at Google is to inappropriately gain access to user data. And yes there is anaudit trail on accessing that stuff.

arkem 8y ago

Google has amazing controls and audit capabilities around access to customer data. When I worked on the security team there the number of people who could access a specific person's data without an audit record and an alert being triggered was zero.

13of40 8y ago
Is that for someone going through the user interface, or is it a fundamental feature of the database (or whatever)? In other words, is there no case where someone could log into a server and see some PII in a debugger or a direct query without being detected?
- arkem 8y ago
  This is both for people using tools and people accessing servers and databases directly. Logging into production servers is audited and triggers alarms. There's basically no-one who has "root" level access to a large number of boxes (when I left in 2013 there were only a handful of people who could login to arbitrary boxes and systems were being built so that their access would no longer be necessary). Logging into a server that holds live data would be investigated and so would running a custom query against a production database. The goal was to have it basically impossible for an engineer or admin to directly access data on boxes to force people to use the tools. The tools themselves had a great permission system as well as a way for users to elevate their permissions in emergency (triggering an investigation). It worked well because it was also easy to create dummy databases to develop on (for example by requesting a database extract of your own location data). In my career to date I have yet to see a more privacy conscious / secure approach to handling customer data.
shazow 8y ago
+1 to what arkem said. If I had to trust a company with private data, there is no other company I would trust more to keep it safe from rogue employees and accidental leaks/hacks.

fouc 8y ago

I wonder about facebook also, in terms of access/audit trails.