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

161–170 of 253 posts

Re: Former employees say Lyft staffers spied on passengers

#161

Post by marshallbrekka »

Natsu wrote: post #152
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?

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

Re: Former employees say Lyft staffers spied on passengers

#162

Post by ryan_j_naughton »

closeparen wrote: post #156
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?

Not if you have credit reports and other data that could contain PII as well. You don't want the name or address in the credit report to just point to your user's table, with an assumption that that was the name in the report. And if you don't know with certainty that the credit report pulled was for that person (there are collisions, mismatches, etc), then you want to store that data as associated to the report and not the user (which the report is then associated to the user).

For proper data integrity and data provenance, you want to know what you knew at each point in time. Thus, simply pointing to a user_id and hoping the data on the user's table was the data at some point in time in the past will result in leakage for data science (https://www.kaggle.com/wiki/Leakage).

Re: Former employees say Lyft staffers spied on passengers

#163

Post by noobermin »

jstarfish wrote: post #14
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…

> Basically, I think its reasonable to both allow many people access and expect them to not abuse it. Indeed. The FCRA accounts for bored clerks looking up random peoples' credit history. Just because you have access to something doesn't mean you're allowed to touch it without a valid business reason. I'm no fan of regulation but the wild west of PII is long past needing to be tamed. Companies need to be held respons…

Couldn't this come under violation of terms of service under Lyft's end and open them up to class action, so there's no need for new regulation at least for this current issue.

Not that I'm against new regs, I'm for it.

Re: Former employees say Lyft staffers spied on passengers

#164

Post by marshallbrekka »

segmondy wrote: post #159
marshallbrekka wrote: post #154

Earlier quoted context omitted.

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?

You're correct that it does make certain kinds of analysis more difficult.

However that doesn't mean we can't ever get access to the original data. Most of our current BI needs to can be met using the un-encrypted data, but for example, if we did want to answer your phone number question, we could craft a special purpose program to perform the analysis without compromising user privacy.

1. Select all phone number tokens

2. Decrypt

3. Produce counts (total unique, etc)

Said program would have to go through normal code review and approvals, and then deployed into the secure zone (so it could access the encryption service).

Re: Former employees say Lyft staffers spied on passengers

#165

Post by closeparen »

ryan_j_naughton wrote: post #162
closeparen wrote: post #156

Earlier quoted context omitted.

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?

Not if you have credit reports and other data that could contain PII as well. You don't want the name or address in the credit report to just point to your user's table, with an assumption that that was the name in the report. And if you don't know with certainty that the credit report pulled was for that person (there are collisions, mismatches, etc), then you want to store that data as associated to the report and…

>You don't want the name or address in the credit report to just point to your user's table, with an assumption that that was the name in the report

Well ok. In your example, call it a "credit report subjects" table.

>Thus, simply pointing to a user_id and hoping the data on the user's table was the data at some point in time in the past

References can be versioned or even hashed, i.e. Git. You would run the same risk with tokens, no?

Re: Former employees say Lyft staffers spied on passengers

#166

Post by lobo_tuerto »

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.

Agreed, too bad humanity's level of maturity as a whole is very far away from ideal. If everyone did what they should we would probably be living in an utopia. But that's not the case.

I don't mean that everything should be super-locked down to the point where it's inaccessible, just tweak it enough to not be misused.

The idea of an audit trail is good, since you can go back in history and make any misbehaving parties accountable. Or design a system where the client authorize a rep to look into her records ---just like banks do when you ask for your balance.

Re: Former employees say Lyft staffers spied on passengers

#167

Post by pfarnsworth »

This is the biggest point I've been making to all my friends. What they believe Uber is so evilly doing, it will probably show that companies like Lyft and Didi and Grab, etc are all engaged in the same sorts of actions. Uber is the whipping boy for ridesharing, but I'm willing to bet that they are do basically the same thing.

My question for Steve Yegge is:

He seems to somehow believe that Grab has the moral high ground over Uber and Lyft. What is he going to do when he finds out that Grab behaves in exactly the same manner as Uber?

Re: Former employees say Lyft staffers spied on passengers

#168

Post by crdb »

jacquesm wrote: post #138
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…

I sincerely hope that your approach becomes common enough that I will see it implemented in practice. Right now it is rather the opposite, plain text data flying around everywhere and at rest in test databases and backups is the norm. And if you are really unlucky you will find it on the laptops of developers in the form of a two week old copy of main database. And if you are even more unlucky that developer does not…

A database would already provide a layer of security (most people, including many "professionals", would not know what to do with it).

Customer data is often stored in a large, denormalised table in an Excel file called "customers" which contains the entire set of customers past and present, including those who unsubscribed or have not ordered for years, with all attributes (phone, address, etc.).

There is also no oversight on who has access to this file, since "marketing needs it for Facebook" or "customer service needs it for returns" or whatever the excuse du jour is. Even the newly hired intern with a stronger than usual interest in every system's credentials gets a copy.

You get some measure of security when there are more than one million customers and they need to start partitioning.

The most secure setup I've seen was a company whose entire repairs department ran on paper slips. Since nobody had the time or inclination to enter the information somewhere digital, no internal staff knew how to find customer information, even if they walked to the shop floor. I think a couple of old timers knew how to navigate the pile of slips and were the de facto DBMS engine.

Re: Former employees say Lyft staffers spied on passengers

#169

Post by kyrra »

cronjobma wrote: post #13
joshuamorton wrote: post #6

Earlier quoted context omitted.

(I work at Google, but these views are my own): This works until you need some kind of ombudsperson. At some level the data needs to be accessible and audit-able, otherwise what am I to do if my driver just drops me off at a different place than where I asked, or doesn't pick me up. You need to know that I was in their vehicle, otherwise how can they charge me if I ruin their car. You need to know they were my driver…

You could completely anonymize when certain key variables are met. In your example, when the ride is successfully completed and both parties confirmed this, the data can be anonymized.

Sadly there is money moving on both sides of this transaction. Depending on the state/country, there may be requirements to retain this data in a certain way or to report it to the government.

When you are moving money (especially when you are moving lots of money) you start having to deal with KYC, risk models, and all other kinds of fun.

Re: Former employees say Lyft staffers spied on passengers

#170

Post by rdiddly »

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.

Well, does Lyft's hiring process optimize for maturity? Do they often hire people in their 40s, for example?
Post reply on HN