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

151–160 of 253 posts

Re: Former employees say Lyft staffers spied on passengers

#151

Post by cwkoss »

fooblitzky wrote: post #50
ryacko wrote: post #45

Earlier quoted context omitted.

https://danluu.com/wat/ apparently this is normal: Facebook famously let all employees access everyone’s profile for a long time, and you can even find HN comments indicating that some recruiters would explicitly mention that as a perk of working for Facebook. And I can think of more than one well-regarded unicorn where everyone still has access to basically everything, even after their first or second bad security b…

It doesn't need to be normal. There's no reason companies couldn't build a system that required approval from your manager before being able to access customer data. Any time a manager granted access, that could be audited by some second tier.

"Okay, stay on the line. My manager went to the bathroom 15 minutes ago, he should be back any minute, and then we can proceed with..."

After-the-fact accounting for all 'sensitive' actions would probably be more practical for most business needs.

I'd put a wizard in front of the thing that grants the access token to figure out the purpose and scope of the token needed.

Information request: "Rider History"

User: current caller

Scope: Between 9 AM and 11AM today

Reason: Lost an item this morning, need to lookup driver

If you were fancy you might even be able to convert the wizard's contained information into a request against the backend. Select trip.driver, trip.time from trips where user_id={caller_user_id} and time={9:00-11:00 today}

Re: Former employees say Lyft staffers spied on passengers

#152

Post by Natsu »

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…

What do you use as the API Proxy?

Re: Former employees say Lyft staffers spied on passengers

#153

Post by djsumdog »

nkkollaw wrote: post #56

I was talking about this with my girlfriend at dinner tonight. While we were eating, I noticed a few cameras that got a view of the whole restaurant, and wondered: of course filming the restaurant might be useful in case of a robbery (?) or for insurance, etc., but what are the chances the minimum-wage employees that checks those DON'T use it to check out hot women or embarassing stuff that happens from time to time.…

They are public cameras taking pubic photos.

That's the whole deal with the "creepshots" deal on Reddit/Tumbler/etc. The subjects are in a public place. If someone does candid shots of lots of different types of people in a city and puts them in an art gallery, they're often considered art (even if 10% ~ 15% of the photos are of really pretty men or women that might be taken as being sexual). However, if you have a site that's only attractive men/women in public settings .. then it's not art ... or is it?

It all comes down to context. Legally it's fine to take public photos of people in many countries (and probably should be, because we don't want to go down that slope). Is it immoral? Well, that's another issue, and that depends on the context the photos were taken in. But you have to set a line somewhere, at least with the legal concerns. You might not like it, but it's just a part of being in a free society you have to deal with.

Now if someone takes a photo in a private area, like a bathroom or spying into a home, that's a different legal issue (unless it's looking up a skirt in Texas[1])

[1]: https://news.vice.com/article/court-ruling-makes-taking-pict...

Re: Former employees say Lyft staffers spied on passengers

#154

Post by marshallbrekka »

kevin_nisbet wrote: post #132
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…

This is a very intriguing approach. I'm curious about one aspect though, have you put much thought into what happens and the side effects of doing something like key rotation if you're encrypted service is potentially compromised / leaked. The second aspect I'm curious about, is you mention services in your general layer are not able to talk to the encryption service to decrypt data, but what about encrypting data? T…

I can elaborate on these points.

The service acts more like a key value store (this is a simplified explanation, but for your questions it will do).

You give it a value, it gives you back a token, which you can later exchange for the original value.

This means the real value is stored in the encryption service, not in the receiving applications database. This gives us the flexibility to perform key rotation (and even upgrade our ciphers as the crypto landscape evolves) at any time without having to worry about where the the encrypted value is being used, as the only data stored outside the service are opaque tokens.

As for de-anonymizing, the service is not designed to take an encrypted value and return its token. If that were possible, we wouldn't have done a very good job encrypting it ;)

Re: Former employees say Lyft staffers spied on passengers

#155

Post by marshallbrekka »

wyattjoh wrote: post #137
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…

Are you using something like Vault [0] for that? Always been interested in different approaches for this. [0]: https://www.vaultproject.io/

The service is written in-house, but we do use Vault for things like provisioning temporary credentials.

Re: Former employees say Lyft staffers spied on passengers

#156

Post by closeparen »

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…

Isn’t it pretty standard practice to confine (overt, obvious) PII to the users table/user CRUD service, so that the rest of the infrastructure only speaks in user IDs?

Re: Former employees say Lyft staffers spied on passengers

#157

Post by ams6110 »

btown wrote: post #111
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.

Too much reliance on programmatic access controls causes people to think “if it’s allowed by the controls, it’s allowed by common sense” which is rarely the case.

On the flipside, systems that are too cumbersome to use because of access controls lead people to do things like maintain shadow systems in Excel spreadsheets just to get their work done. Of course with no security at all.

Re: Former employees say Lyft staffers spied on passengers

#158

Post by marshallbrekka »

jjeaff wrote: post #123
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…

While I like that, and is a cool approach, what is really the difference between just storing PII encrypted in the same database and then keeping your keys locked down based on permission levels? The API proxy would be great if you have a trusted 3rd party in charge of it or something. But abstracting it out to a separate layer doesn't seem necessary since it's all within the same company anyway, and developers will…

In addition to the points already raised by ryan_j_naughton, another consideration is how to perform key rotation and cipher upgrades over time. This is a lot more complex if every application is doing it on their own, but is quite easy if you centralize all (or most) crypto to a single service.

See my reply to another comment: https://news.ycombinator.com/item?id=16236798

Re: Former employees say Lyft staffers spied on passengers

#159

Post by segmondy »

marshallbrekka wrote: post #154
kevin_nisbet wrote: post #132

Earlier quoted context omitted.

This is a very intriguing approach. I'm curious about one aspect though, have you put much thought into what happens and the side effects of doing something like key rotation if you're encrypted service is potentially compromised / leaked. The second aspect I'm curious about, is you mention services in your general layer are not able to talk to the encryption service to decrypt data, but what about encrypting data? T…

I can elaborate on these points. The service acts more like a key value store (this is a simplified explanation, but for your questions it will do). You give it a value, it gives you back a token, which you can later exchange for the original value. This means the real value is stored in the encryption service, not in the receiving applications database. This gives us the flexibility to perform key rotation (and even…

For de-anonymizing, the idea is to give the encrypted service the plain text and get a matching token. But then that will be more of a hash. If you are encrypting where all the tokens are different, you can't do a join or analysis. You can't for instance count how many unique phone numbers you have. If a user is using your app, how do they see their PI data?

Re: Former employees say Lyft staffers spied on passengers

#160

Post by ams6110 »

dkarl wrote: post #96
jamestimmins wrote: post #59

Earlier quoted context omitted.

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.

At Lyft people did think there were automated checks, did know there was a line that shouldn't be crossed, and yet there was rampant abuse. Don't you suspect that many of the students in your position abused their access? I think companies should be responsible for implementing effective security, whether that means preventing improper access or at least detecting it and punishing it after the fact, not just establis…

If you have rules but don't enforce any consequences for breaking them, the rules pretty quickly get ignored.

If Lyft had fired a few rulebreakers early on, everyone else would know they were serious.

Post reply on HN