I worked at Facebook for most of 2017 and 2018. In the first week, they made it clear that you would be fired instantly for any improper access of user data.
They further said that if you need to access any sensitive personal data, or if you need to log in as a user in order to debug a problem, you need to have approval from your manager _before_ the access, not after.
Also, you are not allowed to access the data of anyone you know personally for any reason whatsoever. You have to find someone else to do that if it needs to be done.
Finally, they really do audit every single access of personal data. I had every reason to believe that if I accessed any data improperly, I would be fired within the week if not the day.
I don’t know how much abuse still exists despite all of the above, but I don’t think this article does a good job of explaining how seriously Facebook takes this.
>They further said that if you need to access any sensitive personal data, or if you need to log in as a user in order to debug a problem, you need to have approval from your manager _before_ the access, not after.
But were you still able to just look at the data or login as the user without the permission? I think that's the key question.
Talk is cheap. As a user it's not good enough for me that people are being told internally not to abuse their access. Just remove the permissions from the employees and make them request the permissions for each individual case instead of trusting the employees to follow the rules.
You could at the time start trying to log in as a user and MULTIPLE red warnings came up that proceeding further would automatically notify your manager and skip of access and a reminder of data policies. Now at that point I did not go further but I did know that content moderation and security teams had special access so I imagine they did both, heavily warn avg FB eng AND restrict access.
I am close with some people who worked there until recently. All data access is audited; production access is limited via ACLs in both the main data storage system as well as all the others like the warehouse, realtime ingestion, etc.
FB appears to take this extremely seriously. I just pinged my friends and they said the only way people get fired is for sexual harassment or improper data access. And the second is the one that gets audited and monitored every day.
I imagine at Facebook's scale that nobody has direct access to individual database or application instances; and that if someone actually needed to run queries of any kind in production, it'd be as stringent as deploying a code change.
I am not sure I agree with this framing.
Equivalent framing: separate the genders since rape is possible, even if rape is punishable by death.
This is not just talk - FB does have capital punishment for abuse of access, which creates REALLY strong incentives. Of course, this isn’t fool proof.
> Also, you are not allowed to access the data of anyone you know personally for any reason whatsoever.
Which explicitly also includes yourself, because looking yourself up would e.g. let you see who has you blocked.
You're also fairly unlikely to access personal data by accident. You have to explictly go look for it in the internal tooling, which has pretty good signage around interfaces that could potentially expose you to personal data by accident so you know to be careful (I did a couple of tickets for the abuse team and testing that stuff was riddled with interstitials asking if I was sure I wanted to access personal data). "Oops I didn't notice" just doesn't fly.
They're also fairly good at removing the semi-legitimate reasons you'd have for accessing personal data. If you have friends or family that are having some sort of issue, they have a separate priority queue you can submit requests to so they'll look into those issues for you, for example. If you need test data, there's great tools to generate test users with all sorts of weird configurations (so you don't have to rely on finding a live one that meets your criteria)
I'm surprised that this stuff is audit only. At my company, at least in the past five years or so, this type of access has been forbidden to almost all employees. You need to request access to these types of systems and provide justification for why you should have it. Access is controlled on a per-system basis -- it's not blanket access. Many of the most sensitive systems have auto-expiring access for humans.
Nowadays we are seeing many systems switch to a regime where you have to get another engineer to sign off on any access to production, and your access is limited to at most 24h. This isn't merely a policy -- it is enforced by technical controls that forbid ordinary human-user access to production. I literally cannot even send an RPC to services I work with that handle private data without getting a colleague to sign off on it.
These days things are mostly working the way you describe - I need to request permission to view my own service’s logs, and I’m working in backend infra not going anywhere near user data (logs are like “did we hit any hardware errors when trying to install the OS on this host?”)
Great to hear. I think a lot of big internet companies are moving in this direction, although I don't know if it affects user trust all that much since it isn't publicized. I guess the one thing is that incidents like the one reported here will be avoided in the future, so in ten or twenty years there will have been less reputational damage than in an alternative universe where these controls don't exist.
How “sensitive” is facebook user data though? All content in a facebook account is already visible to an average of >100 people - their facebook friends.
(Messenger had stronger protections than OP is describing)
Extremely sensitive, by the lights of the organization I work for. The people to whom FB user data is visible are known to the user. Those people have been explicitly authorized by the user to view that data. FB is acting as the user's agent in conveying that data only to authorized recipients, who the user presumably trusts to some degree or another to not further propagate the data. The data is generally not publicly visible, and FB employees are generally not among the list of entities the user intends to convey the data to.
While sure I think it’s wise to stay weary of any company you give your data to, Mark said that when he was 19 and Facebook was limited to students. I think it’s disingenuous to use a quote from 2004 to represent his thinking today.
They had this rule at America Online when I worked there early 2000s. It was routinely violated by the managers, and was really only in place for the rank and file to cover their butts. I just assume bad management and executives of Facebook routinely violate peoples privacy by digging through their information, it’s there, and Facebook hasn’t exactly shown an interest in protecting privacy.
The big problem with a company as large as Facebook, is it's easy for the reality on the ground and the statements executives make to differ greatly: The company policy may be as stated, but there may be line employees and managers who have no issue with abuse of personal data, and even cover for each other.
The idea that people can just go in and access personal data at Facebook without some sort of actual pre-authorization is insane.
Those policies will only catch someone after the fact. Firing someone is the bare minimum, it prevents a single repeat offender, but they could already do damage.
Agreed, I was there at the same time, and was taken pretty seriously, and grew progessively more locked down as time went on.
A friend of mine worked at a large bank in customer service and this was also a big part of their training, and there was even a speech trainees were given before going to their desk at the end of training. He said, almost invariably, that at least one person from every class was fired within hours for looking up the accounts of someone they knew or a celebrity.
There's a certain trend in most companies that every bureaucratic rule can be traced back to a specific event where someone caused a problem by doing what the rule was written to forbid - so it's possible that you were indirectly told about four incidents.
If you know the right people, can you be taken off the audit list? I remember in the early days of Facebook, access to everyone’s account was seen as an unofficial perk of the job; the cynic in me would say that this perk still exists but is only given to people who can be trusted to never talk about it.
Just firing is not enough for the cases of personal data abuse. What I would like to see is those employees being reported by Facebook to the authorities to be further legally prosecuted.
We should not rely on the goodwill or internal guidelines of a single company in such a sensitive topic.
There’s a difference between having an audit trail and actually using it. I would be interested to know how often Facebook analyzes this data and actually fires people for improper usage.
I don’t have proof, but we were told that every access of sensitive data was actively audited. It’s very rare to need to do this for your job, so I don’t imagine it’s a huge volume of events to be audited.
These comment's are all relatively ignorant of the fact that implementing these sorts of privacy controls generally makes your product worse and your engineers miserable.
> Facebook employees were granted user data access in order to “cut away the red tape that slowed down engineers,” the book says.
If we can take a step back, this is a totally reasonable policy. Unfortunately Facebook is facing the reality of the law of large numbers in that once you have 1000+ people the chances of having a bad actor in your system is much higher than 10 people.
Maybe this is a hot take, but I for one prefer that my company trusts me to do the right thing rather than make it hard to do my job. I'm not saying that there isn't a solution for this, but behind the "facebook corporation" there is generally just a bunch of engineers that want to do a good job at work.
This is completely unethical and unreasonable. It's like arguing that police don't need more accountability because it makes it harder for them to do their jobs, and most of them aren't bad people, so who cares about a few bad apples?
Yeah it sucks, but it's part of the job. Start thinking about the people you're supposedly serving instead of yourself first. I'm pretty sure that the overwhelming majority of facebook users want to hear about tighter privacy protections at facebook, not fewer.
They are well audited already. Does every step possible need to be taken to ensure that no data can be leaked ever? No.
You can walk out your door right now and hop on a bus. That driver has a CDL, a good first step. But how do we know that the driver isn't drunk? Through threat of possible audit (breathalyzer) after any incident. We don't test them before handing them the keys every day.
We trust people all the time with things far more critical than a facebook user's data, and we audit them far more loosely, if at all.
"completely unethical and unreasonable" > This seems to be influenced by the belief that tech is some utopia where everything is solvable and the world will be a better place. There is room for good enough in trust.
There is a big difference between throwing guardrails up so people don't do wrong and beating them down with requests for permission over and over all day during their work, driving home the point they can't be trusted. Eight hours a day of being told you can't be trusted is about more than the worker's convenience -- it's about their morale at least and possibly their mental health. It also instills the attitude of "if I can do it, it's legal, because otherwise they would have stopped me from doing it."
This isn't beating anyone up. In any mature development environment, you should almost never have to touch production. When writing new features, you should be running against a test environment without real user data. When investigating and trying to repro bugs, you should be trying against a test environment. If the repro is tricky, the errors returned should have enough information to not need to access prod. And so on and so on.
I work at a competitor to Facebook in a user-facing service and have these kind of restrictions in place (must request access with justification, otherwise I literally don't have ACLs to see the data). It's a non-issue because I run into it at most 1-2 times a month, usually far less.
> Does every step possible need to be taken to ensure that no data can be leaked ever? No.
Which person you're replying to demanded perfect security?
> This seems to be influenced by the belief that tech is some utopia where everything is solvable and the world will be a better place.
I am not the person you're replying to, but the claim has nothing to do with utopianism. It has to do with the claim that reasonable safeguards and auditing when dealing with sensitive data is possible, so that users can have (some degree of) confidence in the operation while workers go about their authorized jobs. This is hardly rocket surgery. Or novel.
What some people seem to be taking issue with is that their company might not trust them as much as they think they should be trusted. My advice to them would be to stay in small companies - if you're below the Dunbar number, you can personally evaluate each other and develop trust that way. In larger orgs, you need policy and enforcement, it is just how people are wired.
If we take your argument further all engineers should be given the root password to all production servers and we should simply trust them (and keep logs) to not use the password?
Access control is something so central to IT systems that I'm frankly dumbstruck that someone would argue against them on HN.
If you do need it to do your job, you shouldn't have to run to your manager several times a day to make a request to do it. You should have root or whatever is necessary and it can be audited.
I'm not arguing against access control. I'm arguing for those with responsibility to work to be given the commensurate authority to do their work -- with auditing even.
Who are these hypothetical employees who need to access customer data multiple times per day? If there are more than 5 of them in your O(1000) organization you have serious issues.
For 99.9% of employees, accessing customer data should absolutely be a "talk to your manager" level of occurrence, and each time it happens the manager should ask why it was necessary and what logging you need to add such that you don't need to do it again.
Let me be clear here, I'm not advocating for ZERO access control or audit logs here!
Let's take that bank argument, I'm definitely not advocating for not locking vaults or safe deposit boxes. But somebody has access to those, and when they need access they have a process for getting to it. Frankly, it definitely can be abused and banks wouldn't know for the better until after the abuse when the employee would be terminated and taken to court.
That's because they have audit logs in place. And the reason why its part of your contract as an engineer not to abuse your access to customer data.
I think the larger point I'm trying to make here is that its really, really hard to build a system that prevents any type of abuse of data. Now I'm not saying that we shouldn't strive for systems that make it hard to abuse customers data, but bad actors have ways of beating these systems and I have some empathy for a policy that places trust in employees (who need access, by definition of their job!) to not abuse it.
Anyways, these are all good comments made in response to mine. I agree with them!
[EDIT] Okay - I see the incoming point about them not needing access to that data for their job, that's a fair point. But I think most of us have been at a point in our careers where knowing the piece of information about a user that might have gotten them into a certain state is occasionally a valuable debugging tool.
> a point in our careers where knowing the piece of information about a user that might have gotten them into a certain state is occasionally a valuable debugging tool.
Exactly - that's the problem with the mentality in tech right now. Just because something might make your life easier doesn't mean you get to have it. Trading user privacy is not ok because it's "occasionally a valuable debugging tool". That is exactly the problem.
Too many people in tech companies show no responsibility for the data they have privilege to - and treat privacy as absolutely minimal.
You're a parent, you wonder what's going on in your daughter's life and she isn't talking to you about it. You don't then get to break into her diary and read it all because it might give you a tip on being a better parent to her. Yes if she's for example suicidal and there is an urgent situation where reading it might help save her, then of course access it. But corporations don't get to toss aside privacy just because "it might occasionally be a valuable debugging tool".
Write a debug helper tool to clone all of a users state with lorem ipsum.
I don't need to know anything about user123 outside of the fact that they are located in Perth, Australia.
Nothing else matters to me for this, I don't have access to any PII data like email or device (look, I know user ID's can technically be considered PII depending on which infosec person you're talking too).
Is this still a problem?
I understand your metaphors but without knowing that user123, who created a ticket in our system, is in Perth Australia (which for some reason that locality in my own metaphorical example is having issues processing payments) how we're supposed to resolve this.
Maybe I'm just hopelessly optimistic that people aren't as awful as we want them to be, or naive.
It’s not zero. Hashed passwords are still passwords and should be treated as such. “Zero” implies that hashed passwords are not passwords, since otherwise you won’t get to zero.
Just because passwords are hashed doesn’t mean you can give access to them willy nilly and happily claim that “zero” people have password access.
> Hashed passwords are still passwords and should be treated as such.
Agreed.
> “Zero” implies that hashed passwords are not passwords, since otherwise you won’t get to zero.
You can get to zero:
- No humans in the serving path servers' ACLs.
- Diagnostic/recovery servers for humans which require the person submit a justification that links to a ticket/bug/outage, wait for a second person to approve, perform high-level operations that affects sensitive data ("restore user from backup at timestamp T") rather than exposing direct access ("read from backup", "write live user"), and keep an audit record for later.
Everything is about trade-offs. This approach takes more engineering time to set up and if not done well can really slow down common tasks. And there are certainly reasons there might be exceptions—eg allowing the primary on-call to have unilateral access can speed recovery over waiting for a second person to be available. But zero is possible, and stories like this remind us of its value.
A long time ago I managed FB's udb backups, the central MySQL schema around which all other services were strung. Even from the beginning FB never stored plaintext passwords. Can't say there weren't log excursions or the like, but when found these would have been critical bugs and fixed immediately.
They probably mean some access to production servers where it might be scanned in memory or otherwise grabbed using debug tooling. Making this possible for 0 people will be challenging and at the least add a lot of complexity.
Usually it's in the logs. So small number of SREs can sometimes access them (if there are logged). And even if they are not logged, they can always show up during tcpdump debugging of network issues and such.
Client side hashing could solve this, but almost no one does it.
> Client side hashing could solve this, but almost no one does it.
That is because it doesn't solve the problem. If you implement client-side hashing and then let your engineers see what arrives from the client, they will be just as able to log in as the snooped user; the client-side hash has added nothing.
What a client-side password hash does is to conceal the user's password from the user. There are a few types of password-related attacks:
1. If I learn your password, I can log in as you.
2. If I learn your password, I can log in as you, on other sites where you use the same password (and I can find your account, perhaps because you also use the same username or email address).
3. If I learn your hashed password, I can try to crack it.
4. If I dump the site's hashed password database, I can learn who else has the same password as you. (Because the hashes are the same.) Cracking one of them will crack everyone else's -- efficiency!
I might learn your password in a few different ways. Maybe it's "ncc1701d". Maybe I snooped your network traffic. Maybe I found the hash and cracked it.
So what are the solutions?
#1. There is no solution; this is working as intended. That said, HTTPS operates in this area, by making it more difficult for people to learn your passwords by snooping your network traffic.
#2. You, the user, would have to use different passwords for different accounts.
#3. I, the website operator, should process your password with a hashing function that is tuned to be slow.
#4. I, the website operator, should salt the passwords so that two identical passwords on two different accounts on my site produce different salted hashes.
Hashing the password on the client side and sending the hash over the wire does not address attacks 1, 3, or 4. They all work just as well regardless. It might show up if I try to perform attack #2.
This attack involves me (1) learning your password on one site, and then (2) using it to log in to your account on a second site. We will compare strategy (A) -- you enter your password, the site hashes it on your side, an intermediate hash is transmitted to the server, the server hashes it again, and finally the server stores the final hash in a database -- with strategy (B): you enter your password, the site transmits it in plain text to the server, the server hashes it, and finally the server stores the hash in a database.
In strategy (A), you have three passwords, plaintext, intermediate, and final; for purposes of parallelism, the same is true in strategy (B), except that your intermediate password is identical with your plaintext password.
In the case where I learn your final hashed password by dumping the site's database, there is no difference. In both cases, I will attempt to crack that password by guessing a likely password and running it through the hashing process.
In the case where I learn your plaintext password, there is also no difference. That's just attack #1.
In the case where I learn your intermediate password, perhaps by snooping network traffic or server logs, I can immediately perform attack #1 against your account on the particular site, because -- for purposes of that site only -- I have learned your plaintext password. I can also perform attack #3, cracking your hashed password, against your accounts on any and all other websites. But, in strategy (A), I cannot immediately perform attack #2 -- my attempt to crack your password would have to succeed first. If you have a weak password, it will. If you have a strong password, it probably won't.
This is very weak tea, which is why, working as a security consultant, we considered the defense you describe, "passing the hash", to be a red flag, and always recommended against it.
In the case being discussed here, where Facebook is explicitly worried about engineers viewing users' Facebook accounts, as opposed to their eBay accounts, client-side hashing has literally nothing to add.
IMO, it's likely that the article was confusing "passwords" with "hashes" here. No company the size of Facebook is going to be storing plain-text passwords in 2021.
"No company the size of Facebook is going to be storing plain-text passwords in 2021 on purpose."
We've seen stories where the servers were logging the plain text data it received where those logs persisted for some time, but the plain text was never "stored" in the database.
Related anecdote, when I was in university, I had changed my university IT services password to something "offensive" (had the F word in it) after getting frustrated trying to find one that met the novelty and entropy requirements. I was contacted later by IT to tell me that was an inappropriate password and to change it. I found it much more offensive to know that IT could see my password in plain text, than I would to read a swear word.
The password probably was not stored in plaintext (if you've been to University in the last thirty years), but IT staff might have periodically ran a password-cracking tool in order to find weak passwords (and swear words in various languages will certainly be in their dictionary). They alert the user and request the password to be changed (might disable the weak one) in order to safeguard their network.
This is an interesting point, and I did consider it as I was typing the comment. If I remember correctly, the password was fuckStateU+1 with my university name (abbreviation) subbed in (like I said, I was getting angry trying to meet the special character etc requirements). Do you think password cracking software they use would break suck a password any faster than brute force? I suppose its possible but I'd discounted it.
There are all kinds of places storing things that aren't explicitly stored. For example, a VM snapshot of a system that was processing a request including a password and had it in the memory at the time, any service (including something that does just network proxying) with a debug mode that logs full request data, etc.
Could it be possible they mean access to servers where authentication is handled? If you had root access to such a server you could look at memory or packets and work towards revealing a user's password.
In the case of a username/email + password login, the password is sent to Facebook. Code on their end uses a one-way encryption to turn it into a unique value that's compared against a value they stored in the database when you set your password. As long as the one-way encryption is done with the same values, the two passwords match, and FB knows that you've typed the correct password without them having to store your plain-text password in their database
Some insecure websites (not Facebook) may not do this, and instead store your credentials in a database without encryption. It's a terrible idea, and GP's comment seemed to be referring to this when they (correctly) suggested that no one should have access to a database of plain-text passwords.
The replies mostly refer to the fact that even if the password never hits FB's database, there is still code running on authentication servers that handles that password in plain text before it's been encrypted. Limiting engineer access to authentication servers is a good idea, but it'd be challenging to prevent ALL engineers from having access.
This is a pretty widespread issue I'd imagine, we just don't hear about it or people aren't caught.
I know they've been locked down since I've left, but some of the tools we were allowed to just freely access at Uber were a tad scary, to say the least.
I'm sure every company with a very large userbase, such as Facebook/Microsoft/Google/etc claim they have internal protections/checks but have even more holes like this.
Pretty inexcusable by 2015. FB was hardly a new company at that point.
Every Googler gets the message that you keep your mitts off private information in logs (or get terminated) drilled into them in their first week of training. Logs access is a) restricted b) audited c) tiered and d) enforced. That was the case in 2011 when I started and it's the case now.
Not saying Google is perfect, but it's not like companies like FB didn't have a template for privacy standards that they could have followed.
All that said, but back then I just personally assumed that this is how FB was operating :-( I am hoping they've improved since.
I know an engineer, a security engineer at Google who is pretty well-known, who went to work at Google specifically so he could get at peoples personal data. I don’t know if he actually does it, but he boasted quite openly for years that he wanted to be the “architect“ and see everything and know everyone’s secrets. He is now a highly placed Google security employee.
There are no “architect” roles at google. Most people outside anti-abuse roles have no access to user data, and even the abuse people use audited frontend tools that formalize the policy that the viewer must reference the ticket they are working on and the limited data they need to see.
People with direct access to production data streams mostly see encrypted data. There’s a big, annoying technical scheme in place to make sure private or sensitive data is elided whenever a message is printed in plain text to a log. It stretches from the protocol compiler all the way down to C++ stream operators.
I’m not saying nobody ever sees user data. Sometimes you need to find out why an email is crashing the mailer. But those accesses are limited in scope, auditable, and available to relatively few people.
In my opinion it isn’t really the Facebooks and Googles of the world you need to worry about, it’s the companies with massive collections of user data and without the technical chops to protect it. Like Dropbox.
In this case I suspect "The Architect" is a reference to the character in the Matrix films. The character who has visibility into every corner of the Matrix and full knowledge about everything going on inside it.
Could be wrong. Either way I very much doubt it is related to a specific role at Google.
If that was his plan, he picked the entirely wrong company to accomplish it. There are many layers of access control at Google that would make that impossible regardless of how highly placed he is. He'd be better off at a smaller company with less mature security tools.
In a sane world this would be a company-ending event, or at least seriously impact their stock and C level execs.
The idea that:
a) User data access is not just allowed but normal (or at least that it was at one point)
b) That it's allowed at all so widely
c) That (a) and (b) are true despite repeated abuse
is absolutely insane. "Nearly every month" is insane. It should be criminal, but it isn't.
Sadly, it's all too common for engineers to have way more access than is necessary, though this seems extreme. I see no reason why any engineer, outside of extreme circumstances that should set off alarm bells, should have access to sensitive user data like passwords. It should generally not be the case that direct access of data is needed at all.
Where I used to work, user activity/transactions data sent to us would be stored on a single giant nfs volume. If you were added to a Linux group you can full, unaudited access to everything. Whenever someone tried to build anything that would restrict and audit access there would be a ton of pushback from engineers and customer support who loved being able to ssh into a machine and have full access to everything.
Not uncommon in early-stage startups. I've learned to build these sorts of things with access control and auditing up-front, but certainly have built my share of attractive nuisances over time.
My advice is stub something out up front, before you go to production. You don't have time to do it right, but you do have time to establish the norm. Even if your audit trail is just a two-minute DB trigger that records that Worker Bob changed Customer Alice's password yesterday at 11, make it clear that there needs to be an articulable reason at hand for having used mechanisms that may violate users' trust.
A lot of the commenters here are rightly not surprised about this. A few years down the line this is going to be a similar thing with voice activated devices like Alexa. Employees, contractors, advertisers will all have access to the voice data of not just the person using these devices but of those who just happen to be in the vicinity. And no one will be surprised about it.
This is so common. Think of any start up you gave way too much info to. They have lots of lower paid employees who can look at that data. It happens a lot.
I was on vacation in Egypt, this year, with a guy who worked at Facebook, along with a fairly large group of us from the States. He would stalk people's Facebook profiles in our group to find out information on them and even confront them about it, if they made him upset enough. He even messaged them directly on Facebook to tell them off.
As a side note, he was mostly only interested in having hook ups and orgies with Ukrainian tourist women, while in Egypt, made even more bizarre when we found out he has a wife back in the United States, of which, worked at Apple.
He was not a well liked guy and he was very rude to the Egyptian natives, especially towards the Bedouins.
At this point, why not just make any of this social media information public? What’s the difference to more than 16 000 people knowing with whom you cheated vs. the whole world knowing?
By 6 degrees of Kevin Bacon there surely is a connection to one of these 16000 people in your bubble, hence the secrets are theoretically out, too. Why should they have the advantage over you and potentially blackmail you?
While Facebook has a massive pile of data, what about the other massive collectors of data out there?
Do similar processes and consequences apply in the worlds of the your banks, credit card company, Experian, Equifax, the NSA, FBI, and other groups, both government and commercial?
She should sue Facebook. This industry has no will to change. It must be coerced.
Ideally, your data should be encrypted and no one at Facebook should not have access to it. Only those people whom you have chosen to then share that data should have access to the degree given (crypto wise, maybe this means you decrypt and broadcast to those people like email). Any reason why a Proton-like model wouldn't work for technical reasons? Facebook could still make money off ads, but those ads would be less targeted. Good. We need less targeting.
I would not be surprised if this was common. I simply don't have enough faith in society today to believe that most people would understand how wrong this is.
Everyone here is unsurprised by this and at this point I expect the social networks to just abuse my user data anyway. They won't change and they will never stop this.
Who is to say that this is already happening with the other social networks that are scooping up our data but in 5 years time will only admit their actions afterwards.
Maybe they are all doing this as we type.
To Downvoters: So you think that these social media companies are NOT abusing our data? There's tons of evidence of this everywhere, including this confession.
There can only be one explanation of why I'm getting downvoted heavily of an undeniable known fact and it is likely that it is by those working at these companies because they know that I am right and the point still stands regardless of any downvotes (and censoring of the truth).
I don't think it actually matters much; your database is your core business and access to it should be restricted. Same as your machines. To the point where, if you have everything set up right (which is a big if, granted), NOBODY should need physical access to ANY machine or database. All access through the application's management interface, where access can be finely tuned and access logs can be used to hold people accountable.
They further said that if you need to access any sensitive personal data, or if you need to log in as a user in order to debug a problem, you need to have approval from your manager _before_ the access, not after.
Also, you are not allowed to access the data of anyone you know personally for any reason whatsoever. You have to find someone else to do that if it needs to be done.
Finally, they really do audit every single access of personal data. I had every reason to believe that if I accessed any data improperly, I would be fired within the week if not the day.
I don’t know how much abuse still exists despite all of the above, but I don’t think this article does a good job of explaining how seriously Facebook takes this.