4 ms·
It’s a bit sad that he doesn’t even attempt introspection on employees having any access to customer data whatsoever. I fully understand this is a normal situat
by mlhpdx 3y ago
It’s a bit sad that he doesn’t even attempt introspection on employees having any access to customer data whatsoever. I fully understand this is a normal situation, and that every function will puke all over the suggestion that they can do their jobs without access to customer data. But they can. It’s more difficult, yes. But it’s possible (I know, I’ve run this way in the past). Particularly in Carta’s business this should be on the table — zero internal access to the data. Period.
- jeffbee 3y agoAlmost everyone in every line of business believes that having policies against accessing customer data, but no technical controls over it, is good enough. The number of firms that have systematically removed there own access to customer data is extremely small.
- tobinfricke 3y agoGoogle is a stellar example of a company where there are strong technical safeguards against employees accessing customer data without a business purpose.
- lokar 3y agoMeta is good as well
- ffgvq 3y ago[flagged]
- dataflow 3y agoEr, are you sure? [1] If so, how recent is this? > Facebook employees were granted user data access in order to "cut away the red tape that slowed down engineers," the book said. "There was nothing but the goodwill of the employees themselves to stop them from abusing their access to users' private information." > In a presentation to Zuckerberg and the company's top executives, [CSO] Stamos said engineers had abused the access "nearly every month," the book said. At the time, more than 16,000 employees had access to users' private data, the book said. > Stamos suggested tightening access to fewer than 5,000 employees and fewer than 100 for particularly sensitive information such as passwords. He proposed requiring employees to submit formal requests for access to private data but received pushback from executives. Zuckerberg said changes on the matter were "a top priority" and tasked Stamos with finding a solution and giving an update in a year, the book said. [1] https://www.businessinsider.com/facebook-fired-dozens-abusing-access-user-data-an-ugly-truth-2021-7 https://www.businessinsider.com/facebook-fired-dozens-abusin...
- lokar 3y agoWhen I was there to work on the main front end (hack/js) you ran a copy as you made changes to it. It had full access to real data. But if you tampered with access control logic in it or otherwise read other users (vs your own or a test user) it would get flagged and you get fired. Happen fairly often.
- dataflow 3y agoYeah that's not "strong technical safeguards". Or good enough.
- lokar 3y agoThey seemed pretty good at catching people
- dataflow 3y agoI hope you never have control over people's data. Being good at catching people after the fact is not the same as being good about securing the data in the first place. Seriously, if you had important information that was leaked, it's kind of irrelevant whether the person who leaked it got fired. You still face the consequences either way.
- Terretta 3y ago> Being good at catching people after the fact is not the same as being good about securing the data in the first place. True, only one of these is future proof, and maybe not the one you think.
- jeffbee 3y agoYeah that is not even remotely good enough. Processes running under the authority of individual engineers cannot have access to user data. Processes with access to user data can only run reviewed and committed code with verified production builds. There can't be user data just laying around on hosts were unix superuser permissions can be used to access it.
- xyzzy_plugh 3y agojeffbee worked at Google.
- macintux 3y agoI work in an environment where we're trying to troubleshoot production data problems...without access to the data. It's a royal pain, but a necessary one.
- bertil 3y agoIt's not that hard to suggest access monitoring, isolate routine aggregate metrics and occasional needs, and have a process around other reasons why you'd need to run some more detailed analysis. You don't need the separation to be absolute on day 1, just known, discussed, and gradually limited to need-to-know.