Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Former employees say Lyft staffers spied on passengers

techcrunch.com

Post reply on HN
Print view View original

201–210 of 253 posts

Re: Former employees say Lyft staffers spied on passengers

#201

Post by mattmanser »

djsumdog wrote: post #144
sargun wrote: post #92

Earlier quoted context omitted.

Have you tried to debug the same two problems when you do not have access to the infrastructure, versus when you do have infrastructure access? It's a radically different experience. In addition, even if no one needs access, a bad actor who writes the code can always put a backdoor in place and read whatever they want.

I agree with you. I worked at a BlueCross and when debugging front-end apps, and I'd often dig through the database to check to see what is in each table and what could be throwing an error. I'd often bright up a debugging tool called TeaLeaf that let me watch the entire web session (this was back in 2009; so the full DOM tracking we complain about now has been available for quite some time). Technically, we couldn't…

That you casually talk about breaking the law with incredibly sensitive data is shocking. And worse still, you built in a system that circumvented the official policy, simply because you weren't capable of doing your job.

You basically built in an illegal back door. If you were my employee I would fire you on the spot for gross negligence when I found that. Or maybe if you were a junior you'd be given a massive dressing down, put on notice, re-sent on all the mandatory company tutorials about sensitive security of data and an urgent fix put in to remove the backdoor.

This is just bad engineering, if you can't recreate bugs without having to constantly resort to live data, get someone in who can. It's not particularly hard, it's a learn-able skill of our profession.

And if you're really having a problem, and it does happen once in a blue moon, you should have the ability to create an anonymized version of the live db that strips out all the personally identifiable info. That you can still only get with a signed, approved request and a full justification of why you needed it.

For the record I have worked somewhere that had highly sensitive data. And they took it seriously, unlike you two. None of the engineering team had access to the live db, the live site or the passwords, apart from some senior team members.

Re: Former employees say Lyft staffers spied on passengers

#202

Post by zkomp »

tapland wrote: post #48
milofeynman wrote: post #47

Earlier quoted context omitted.

In hospitals in the U.S. the way it works in some is nurses can view a lot of the patients charts (including VIP). And then someone is supposed to audit who viewed those VIP patients (celebrity or what not) but every hospital is different and it's a mess.

Here in Sweden you can view any patients info, and there is supposed to be audits to check that a doctor only ever checked relevant patient journals. Always a few cases now and then of people getting caught checking friends, family and foes. Pretty sure that auditing is completely separate from the caregiver.

In Stockholm, there is one journal system everyone is mandated to use, written in APL (was called Take Care but could have changed name), and completely without access control.

I believe each institution get printed access logs sent to them, which is never looked at.

Re: Former employees say Lyft staffers spied on passengers

#203

Post by mattmanser »

djsumdog wrote: post #145
vageli wrote: post #134

Earlier quoted context omitted.

> 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 w…

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'…

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.

Re: Former employees say Lyft staffers spied on passengers

#204

Post by mattmanser »

tallanvor wrote: post #199
mynameisvlad wrote: post #69

Earlier quoted context omitted.

Can you actually refute the parent comment's argument? Because it seems more than reasonable to me. Analytics and Engineering definitely don't need this level of data access for any sort of day-to-day work. I work on analytics tools, and at best, anonymized and generalized data is needed, but never specific customer data. We specifically strip out any PII on data that might reach developers and need to request permis…

A balance has to be made. The parent remark does not show an understanding of the realities of working on a service on all levels. There are many times when developers need access to specific customer data. Pretty much every company has in their TOS verbiage to note that employees may have to access customer data without their specific consent. That said, companies can and should have multiple layers to help prevent…

But I do have understanding. Because I've actually worked in a company with these safeguards. It handled extremely sensitive data of tens of millions of Britons. Normal engineers had no access to live data, 2 senior managers were the only ones in the engineering team with access to live passwords, etc.

It is practical to put extremely heavy restrictions in place between engineers and the live data and they can still do their job. Our normal day-2-day was not impeded in any way.

I only worked there 3 months for other reasons, but regardless of my view on other parts of their operations, their dedication and practical solution to protecting customer data impressed me.

Re: Former employees say Lyft staffers spied on passengers

#205

Post by mattmanser »

ryanfreeborn wrote: post #192
mattmanser wrote: post #10

Lyft tells TechCrunch that staffers in several departments that might need access to this data for their job have the ability to look up this information See, that's a complete lie and that's the attitude that needs to sop. No-one needed access. Analytics definitely didn't. Engineers never did. Customer services should have to request permission from the customer before accessing sensitive data, with a valid reason.…

This is a pretty absolutist approach. >What's the need? How about plain old abuse? People using services to break the law, particularly crimes with victims? Safety risks? - An uber passenger sees their driver has a gun in the cup holder; they report it to uber. - A Square merchant is using Square to launder serious money and Square catches it. - A Dropbox user is uploading child pornography that indicates active chil…

Of course there are exceptional circumstances where access would be granted by a manager without customer approval or routinely by extremely specialised abuse teams.

What I'm talking about is general day to day access to customer data. The analytics, customer service, engineering, etc. teams. It's a different discussion you're trying to have.

Re: Former employees say Lyft staffers spied on passengers

#206

Post by mattmanser »

chaostheory wrote: post #70
mattmanser wrote: post #10

Lyft tells TechCrunch that staffers in several departments that might need access to this data for their job have the ability to look up this information See, that's a complete lie and that's the attitude that needs to sop. No-one needed access. Analytics definitely didn't. Engineers never did. Customer services should have to request permission from the customer before accessing sensitive data, with a valid reason.…

> What's the need? It isn't needed all the time but the one scenario I can think of is for debugging. Sometimes it's hard to dissect or even replicate a bug without the original data.

Discussed elsewhere in the thread, it's definitely not needed day to day.

The number of devs popping up in this thread who think routine access is needed to live data just to be able to debug is quite worrying.

In the rare instances it is, an anonymized version of the live db should be used to recreate the bug. If this doesn't work, then you might put in temporary logging accessible to only approved people, which is removed after the bug is fixed and the logs deleted.

To be a bit more explicit, I think small companies have a justifiable reason to be a bit more relaxed about live db access, but once you get to having larger teams of people, you're under a huge risk of a malicious actor. Which is easily mitigated by restricting access.

Re: Former employees say Lyft staffers spied on passengers

#207

Post by mattmanser »

azernik wrote: post #135
andrestan wrote: post #131

Earlier quoted context omitted.

Which news story about Uber makes invasion of privacy seem like a top-down policy?

Tracking a journalist: https://www.theverge.com/2014/11/19/7245447/uber-allegedly-t... About the company specifically designing and building an internal tool to make this process easier: https://www.theverge.com/2014/11/19/7245447/uber-allegedly-t... That whole "greyball" story, which involved personal tracking of law enforcement officers: https://www.nytimes.com/2017/03/03/technology/uber-greyball-...

And don't forget they got hold of the medical records of a woman who'd reported she'd been raped by an Uber driver:

https://www.recode.net/2017/6/7/15754316/uber-executive-indi...

Re: Former employees say Lyft staffers spied on passengers

#208

Post by newfoundglory »

mattmanser wrote: post #203
djsumdog wrote: post #145

Earlier quoted context omitted.

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'…

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…

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

That sounds like a pretty simple set of bugs you are dealing with. I don't think anyone is arguing that they need this level of information to solve "When I click this button it crashes".

Re: Former employees say Lyft staffers spied on passengers

#210

Post by newfoundglory »

mattmanser wrote: post #206
chaostheory wrote: post #70

Earlier quoted context omitted.

> What's the need? It isn't needed all the time but the one scenario I can think of is for debugging. Sometimes it's hard to dissect or even replicate a bug without the original data.

Discussed elsewhere in the thread, it's definitely not needed day to day. The number of devs popping up in this thread who think routine access is needed to live data just to be able to debug is quite worrying. In the rare instances it is, an anonymized version of the live db should be used to recreate the bug. If this doesn't work, then you might put in temporary logging accessible to only approved people, which is…

From reading all of your comments here, it occurs to me that you might just not be talking about the kind of software that involves actually processing user data as the service. When customer data is incidental to the core engineering work, then yes you should be able to abstract it away. When the service is "upload your data and we will perform analysis on it and give you results", then it really does require that data to figure out why this customer says their results aren't making sense.
Post reply on HN