[cfors]

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.

[BigBubbleButt]

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.

[LanceH]

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."

[Arainach]

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.

[_jal]

> 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.

[cycomanic]

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.

[LanceH]

If you don't need access, you shouldn't have it.

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.

[Arainach]

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.

[BoiledCabbage]

> 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.

Yes and banks shouldn't lock their vaults or safe deposit boxes because and just trust that all of their employees just want to do their jobs.

[cfors]

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.

[BoiledCabbage]

> 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.

[cfors]

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.