These groups usually get access through a bastion that anonymizes data and logs access. I remember that as a SWE at Google, I could run aggregated & anonymized statistics across query logs, but some info (eg. IPs, user logins) had been scrubbed before any of my code could get access to it, and for things that were more personal (eg. your GMail login) you could only get access to your own account.
There's nothing you can do about SREs who have root access on the box or the SWEs who need to implement & maintain the bastion servers, but that's presumably a more restricted, vetted, and trusted group.
I think this may be something that is unique to a certain size tech company that simply isn't the case at 99.99% of companies with user data in their possession.
Of course many of the changes around that time were in response to the breach by the Chinese government, not only in response to embarrassing privacy incidents. Later improvements came about because of things Snowden published.
https://www.washingtonpost.com/world/national-security/nsa-i...
I suspect that at some stage this might come for some FANG employees
I would say it is much more likely that Google will accidentally lose the organizational ability to become root-in-prod, than it is that a person has done this thing without being noticed.
In short, insider risk cannot be mitigated with hiring practices. You need robust technical measures against insider risk.
There was a video with some of the datacenter security measures, e.g. iris scanning (just to get yours in the DB required approvals from senior people). On the actual floor, to which very few have actual access, you need to badge both on your way in and out, individually. If you badge out without having badged in, the door won't open and an alarm will go off.
https://www.businessinsider.com/google-engineer-stalked-teen...
Snowden's revelations (2013) were a major watershed. There'd been several measures taken since, based on what I heard on the outside, largely through discussions, mostly public, a few direct, with Google staff via G+.
Starting on, of all days, November 9th, 2016, I began regularly posting an image of Jewish shop windows shattered during Krystallnacht, asking whether Google were thinking of brownshirt-proofing their data. That generated responses including from G+'s architect (then in a role with user data safety & privicy), and the data security lead.
It wasn't until some time later that I realised I'd entirely accidentally picked the anniversary of the event for the post. Though the coincidence was useful.
My understanding was that numerous protections were in place by that time. I continue to have concerns.
This is so incredibly cringey. You're actively building the panopticon and yet you think of yourselves as righteous warriors for justice.
I don't mean this to be a personal attack, but yours is such a revealing comment about the mindset of people inside these surveillance behemoths.
(See also: this "pledge" http://neveragain.tech/ to not build registries for targeting citizens...signed by a bunch of people who work at companies whose entire business is targeting citizens with ads)
OK, Google.
Sounds like you'd be surprised at what storage, and backup engineers have access to.
/s
I think much like anti-hacking and anti-fraud efforts, publishing information about how they vet candidates would just make it easier for attackers to figure out how to game the system.
Why wouldn’t the information be public? It’s the same concept as crypto algos being published and peer-reviewed.
This is absolutely not true. This number can and should be reduced to an absolute minimum number of people.
As in, define "tech companies" (name specific companies that do this and why you think that can be generalized to the entire industry) and define "careless" (it's a relative term so please say if it's less or more careless of other examples of organizations that manage similarly large amounts of data but that aren't "tech companies").
Because to me the opposite seems true. It's the non-tech companies (if you equate that to FAANG) that manage large amounts of data that tend to have a lot more data leaks (internal or external) than the tech companies.
Why?
I've worked for a few large tech companies that handled very sensitive customer data, and they didn't allow unsanitized access to it by a significant number of people. Typically (on the dev side, anyway), there was a small designated team (less than 10 people) who were the only ones who had such access. Any dev work that absolutely required access to that data -- which was very rare -- was performed by that team.
I worked at one place that had the development network permanently VPN'd into prod. One day, a developer accidentally configured his local environment to connect to a production queue and database. It was like this for over a week.
A previous company didn't bother with the VPN. They had an AWS environment that predated VPC, so SSH and many other service ports were open to the office IP addresses. And several people's homes, for remote work.
It depends on the company (as with large ones, apparently). I currently work for a small company, and it is no less diligent about this stuff than the major companies I've worked for.
Backups generally have "god mode" access (best description) as they need to backup and restore not just filesystem data, but the audit log data as well.
Most (corp) places I worked, the developers and SysAdmin's working on production servers gave little thought to the backup component apart from making sure the software is installs and runs. ;)
Even if you follow best practices with access control, in the end you're always going to have a group of people who you need to trust with access to folks' personal data. Maybe the solution is better audit logging and even tighter access, but I'm not sure leaks of this nature are preventable.