4 ms·

It is probably possible to design systems to avoid access, but they will get more complex. Engineering has to debug bugs. For example, suppose there is bug wher

by gersh 9y ago

It is probably possible to design systems to avoid access, but they will get more complex. Engineering has to debug bugs. For example, suppose there is bug where the rate calculations aren't working for certain types of routes. The engineers will want to look up those routes to understand what is causing it. If you are designing an algorithm to detect to fraud, you are going to want to look at cases of fraud to understand how to design the algorithm. Further, if you want to do usability testing you are going to need to test with. You might want to check the different types of names used in the system to make sure they display properly. You may also want to sample the list of customers to user-test with live data or survey customers.

mynameisvlad 9y ago
For debugging, you generally can access things like server logs, which would already have a lot of the data you might need. It'd be behind a session ID or some other type of anonymizer, but the customer can provide that and other debugging information so you can look up their entry. It might be a bit harder for mobile apps, but there's plenty of telemetry products that provide crash dumps (with many of them supporting the stripping of PII). You definitely don't need always-on access to all customer's data to do this role, or even access to their PII data for the purposes of debugging. Rate calculations 100% do not need specific data access. All you need to do that job is to have a generalized set of data based on the routes in question. You don't need to see that Joe Smith in SF took a route from A to B and what went wrong with it, you just need to see what all routes/rates from A to B were, and then from there look for anomalies. Fraud is a bit more tricky, but if you already know what you're looking for, then you don't need the specific customer data set, you just need to know what deviations from the norm a general fraud request had. Usability testing should be done with completely fake data, preferably created by someone with knowledge on how to do that specific job. This one is by far the easiest one to argue against needing access to real customer data since most places already have this type of fake data created specifically for this purpose. Overall, none of your examples really need data access. Sure, it'd be nice to have access to it for some of these points, but it'd also be nice to have a million dollars. It doesn't mean you can't do your job if you didn't have it.
vageli 9y ago
> For example, suppose there is bug where the rate calculations aren't working for certain types of routes. The engineers will want to look up those routes to understand what is causing it. Then show routes without names. > If you are designing an algorithm to detect to fraud, you are going to want to look at cases of fraud to understand how to design the algorithm. Then show names without routes. > Further, if you want to do usability testing you are going to need to test with. You might want to check the different types of names used in the system to make sure they display properly. You may also want to sample the list of customers to user-test with live data or survey customers. Use a library that can generate realistic but fake data. I feel there is no excuse to not compartmentalize. If data security is not important to the business...well it only takes one bad article like this to cast doubt on the whole company.
- djsumdog 9y ago
  The trouble is, if you're at this level of engineering, you're probably going to be writing the isolation layer. So you already have access to the raw data and you're just going to either make things harder for yourself or only be designing for downstream security. You can and should restrict customer service reps (only allow them to access routes/users/drivers who they have active tickets on), but at some point you're going to need to trust your developers since they can usually just query the database directly.
  - mattmanser 9y ago
    As I said in another comment, there's absolutely no need for an engineer to have access to live data in normal circumstances. Learning how to recreate bugs without trace stacks or live data is a debugging skill you can learn. Often it's as simple as following the steps described in the ticket, something some developers seem to not realize, or their reading comprehension is bad. For really complex bugs, you might need some sort of access to see the specific conditions, but it should be attempted with an anonymized version of the db that you had to request and get signed off on. If you then really need to put in tracing, if should be temporary, the data access should be heavily restricted and it should be deleted/removed once the bug is fixed.

by gersh 9y ago

mynameisvlad 9y ago

For debugging, you generally can access things like server logs, which would already have a lot of the data you might need. It'd be behind a session ID or some other type of anonymizer, but the customer can provide that and other debugging information so you can look up their entry. It might be a bit harder for mobile apps, but there's plenty of telemetry products that provide crash dumps (with many of them supporting the stripping of PII). You definitely don't need always-on access to all customer's data to do this role, or even access to their PII data for the purposes of debugging. Rate calculations 100% do not need specific data access. All you need to do that job is to have a generalized set of data based on the routes in question. You don't need to see that Joe Smith in SF took a route from A to B and what went wrong with it, you just need to see what all routes/rates from A to B were, and then from there look for anomalies. Fraud is a bit more tricky, but if you already know what you're looking for, then you don't need the specific customer data set, you just need to know what deviations from the norm a general fraud request had. Usability testing should be done with completely fake data, preferably created by someone with knowledge on how to do that specific job. This one is by far the easiest one to argue against needing access to real customer data since most places already have this type of fake data created specifically for this purpose. Overall, none of your examples really need data access. Sure, it'd be nice to have access to it for some of these points, but it'd also be nice to have a million dollars. It doesn't mean you can't do your job if you didn't have it.

vageli 9y ago

> For example, suppose there is bug where the rate calculations aren't working for certain types of routes. The engineers will want to look up those routes to understand what is causing it. Then show routes without names. > If you are designing an algorithm to detect to fraud, you are going to want to look at cases of fraud to understand how to design the algorithm. Then show names without routes. > Further, if you want to do usability testing you are going to need to test with. You might want to check the different types of names used in the system to make sure they display properly. You may also want to sample the list of customers to user-test with live data or survey customers. Use a library that can generate realistic but fake data. I feel there is no excuse to not compartmentalize. If data security is not important to the business...well it only takes one bad article like this to cast doubt on the whole company.

djsumdog 9y ago
The trouble is, if you're at this level of engineering, you're probably going to be writing the isolation layer. So you already have access to the raw data and you're just going to either make things harder for yourself or only be designing for downstream security. You can and should restrict customer service reps (only allow them to access routes/users/drivers who they have active tickets on), but at some point you're going to need to trust your developers since they can usually just query the database directly.
- mattmanser 9y ago
  As I said in another comment, there's absolutely no need for an engineer to have access to live data in normal circumstances. Learning how to recreate bugs without trace stacks or live data is a debugging skill you can learn. Often it's as simple as following the steps described in the ticket, something some developers seem to not realize, or their reading comprehension is bad. For really complex bugs, you might need some sort of access to see the specific conditions, but it should be attempted with an anonymized version of the db that you had to request and get signed off on. If you then really need to put in tracing, if should be temporary, the data access should be heavily restricted and it should be deleted/removed once the bug is fixed.