3 ms·
When 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 a
by lokar 3y ago
When 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.
- lokar 3y agoNothing is laying around. Everything is remote API calls authenticated as the engineer running the code.