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

171–180 of 253 posts

Re: Former employees say Lyft staffers spied on passengers

#171

Post by tantalor »

jstarfish wrote: post #118
lobo_tuerto wrote: post #109

Earlier quoted context omitted.

"Just because you have access to something doesn't mean you're allowed to touch it without a valid business reason." Then you should not have access to it? People will touch them if they can. That's why Access Control rules exist.

That might be how we deal with children who can't handle responsibility, but the absence of technical controls for every nuance of life is why ethics and code of law exists for adults. Access controls are not a substitute for maturity.

> children who can't handle responsibility

Isn't the real concern bad actors? e.g., LOVEINT

Re: Former employees say Lyft staffers spied on passengers

#172

Post by cookiecaper »

gresrun wrote: post #85
mmanfrin wrote: post #79

The screenshots from the leaker mention that they are using "redshift", which is the name of Amazon's RDB product. Which means this is about people who have access to the database. This is unsurprising that they could access customer data given access to their database. I'm not sure how you prevent this without preventing access to the db (and there are legitimate reasons people within the company would have access -…

You can't prevent access but you can log all access and require a written reason for access. That, followed up by routine audits of access logs will reduce and discourage abuse as described in the article.

This is about Redshift, Amazon's cloud-based data warehousing tool. Auditing and logging every individual access made by data analysts, engineers, and others making use of Redshift would make their jobs impossible. One day of queries would take weeks to audit and validate a legitimate use case for all the individual data that got touched, and if you're just going to say "oh they needed everyone's PII because it was a big analytical query like they do all day", you're back at square one.

The reality is that some people are going to need wide-reaching access. You could monitor for certain problematic access patterns, like someone who is supposed to be doing primarily aggregate queries doing a lot of specific ones, and I'm sure that'd be a good thing to do, but to be honest there are probably much higher priorities since employees who need sensitive access are probably going to be able to avoid that type of detection.

Re: Former employees say Lyft staffers spied on passengers

#173

Post by misterbowfinger »

marshallbrekka wrote: post #161
Natsu wrote: post #152

Earlier quoted context omitted.

What do you use as the API Proxy?

It's a custom Go application that proxies rest/json based APIs, as well as gRPC/Protobuf.

Would you consider open sourcing it? It seems quite interesting and valuable

Re: Former employees say Lyft staffers spied on passengers

#174

Post by telchar »

megablast wrote: post #147
jacquesm wrote: post #139

Earlier quoted context omitted.

You would think that if they have the ability to audit at that level and with such prompt responses they would have the resources to lock down the systems properly and to implement a consent policy that works. Allowing everybody access is a bit like binding the cat to the bacon and then getting upset because the cat can not be trusted with bacon. Better to keep the cat and the bacon separate, the temptation to peek i…

Except putting barriers can cause even worse problems. If I can’t look up someone’s allergies because the system doesn’t think I should, fuck them right?

Exactly, barriers to looking up a patient's information can be fatal. I need to give someone medication now to stabilize them. What medications are they on now? Can't look it up? Better give it to them and hope there's no adverse reaction.

Better to avoid that situation and implement auditing while making sure people know the rules are enforced.

Re: Former employees say Lyft staffers spied on passengers

#175

Post by rtpg »

paulie_a wrote: post #143
rtpg wrote: post #116

Earlier quoted context omitted.

There's a bit of pragmatism involved in the level of control. If you add too much friction to the process of accessing information, then it can actually impede on actually handling user support. For example, having access to someone's ride history when trying to resolve a dispute seems relatively normal. Of course in Lyfts case it seems pretty clear that there can be more programatic locks. And auditable logs are abl…

If only we had modern phone infrastructure that could actually transfer useful info to the appropriate person... Instead we have terrible phone support that requires me to repeat the same info 3 times. That info should be unlocked the millisecond I am connected with a rep . It's not a moonshot

Yeah totally. It's doable

My feeling is that stuff is doable, but hard-ish. For example, for this case now you're writing something to interface with the phones? How do you know the phone number is for a certain client?

Though I definitely see someone writing a thing where your ticketing/support system grants partial data access, you end up either making the support system pull in information from the DB... or your DB access controls being controlled through the support system.

the latter one can potentially introduce security issues. The former one's easier but you can easily run into the "oh, this information's not gettable through the ticketing system".

Re: Former employees say Lyft staffers spied on passengers

#176

Post by fjsolwmv »

jamestimmins wrote: post #59
mpolichette wrote: post #5

When I did an internship at a national lab, a lot of the hard rules about security relied on the fact that you had gone though their hiring process and would follow the rules. There were different access levels, for sure, but only like 2 or 3. You might have "had access" but you shouldn't be anywhere you didn't have a good reason for being. Lyft should be checking on this, running audits and whatnot, but they also sh…

This was how it worked when I worked in admissions during college. You had access to every applicants' information, grades, essays, etc., as well as counselor feedback. But you were told that if you looked up yourself, someone you knew, or any celebrities, then you could be fired. I don't know if there were automated checks for that kind of thing, but everyone knew there was a line you didn't cross.

My "elite" college had crisis counselors, student volunteers. Guess what happened if you dated one of them. They searched the counseling files to look for dirt on you.

Re: Former employees say Lyft staffers spied on passengers

#177

Post by fjsolwmv »

jonknee wrote: post #102
Theodores wrote: post #42

Earlier quoted context omitted.

I used to be in the habit of taking my cat to the vet in a regular taxi, with a local company. I always got the same guy and the same car as they always 'knew' where I was going. The guy I got liked cats, didn't mind waiting around and made sure everything was looked after. Others were allergic to cats or only doing airport trips, so I had no problem with them looking at my history and doing their best for me.

That’s great for you, not great for say someone who’s being stalked by an abusive ex. It’s such an obvious and foreseeable problem, they need to own it.

Most male employees wouldn't forsee that problem.

Re: Former employees say Lyft staffers spied on passengers

#178

Post by schwabacher »

ryan_j_naughton wrote: post #122

Having seen this at too many companies, we at fair.com decided to adopt stronger policies to prevent this, viz: - all inbound API requests first go to our API proxy in the secure layer. - the API proxy encrypts all PII using the encryption service in the secure layer - then API proxy sends the request on to the appropriate service, having swapped all PII for tokens. - all services in the general layer are not able to…

The tricky part about this sounds like it would be specifying in the proxy service which parts of structured requests are responses are PII - how do you handle this?

Re: Former employees say Lyft staffers spied on passengers

#180

Post by marshallbrekka »

misterbowfinger wrote: post #173
marshallbrekka wrote: post #161

Earlier quoted context omitted.

It's a custom Go application that proxies rest/json based APIs, as well as gRPC/Protobuf.

Would you consider open sourcing it? It seems quite interesting and valuable

It's so specific to our architecture that there would be little value in open sourcing it.

That being said, there are some lessons we learned along the way that I do think are worth sharing.

As I mentioned above the API proxy supports REST and gRPC API calls.

For REST based APIs, we developed a YAML syntax for declaratively specifying (per route) the input/output keys that needed to be encrypted/decrypted. This is accomplished using a JsonPath like syntax, along with attributes for each key that specified the type of data, as well as letting us perform limited validation on the data.

However this approach provided little visibility into what fields are not being encrypted, leaving room for mistakes.

This is where gRPC/Protobufs come in to play, it's the newest addition at the API Proxy level, but is not new to our internal architecture.

Using protocol buffers as our IDL has been a huge help in terms of our data auditing capabilities. Unlike our YAML based solution before, with protobufs we can see every single field that is expected as an input or output of an API call.

We've utilized this feature by creating wrapper message types that indicate when a field contains data that needs to be encrypted/decrypted, and have helper libraries that can traverse an instantiated protobuf message, perform the encrypt/decrypt operation, and swap out the original value(s) for the one(s) returned from the encryption service.

Once we have the library to perform the traversal and the compiled protobufs, integrating it into the API Proxy (along with grpc-gateway to translate to REST/Json) is actually pretty straight forward.

Post reply on HN