Hacker News Reader

Comment by threepio | Hacker News Reader

Stripe customer here. The question raised is, more broadly, "Is Stripe collecting this data in a legal and ethical way?" This too can be readily answered in the negative.

It doesn't matter whether "Stripe.js collects this data only for fraud prevention" or if it works in practice. Under CalOPPA [1], Stripe still has to disclose the collection of the data, and (among other things) allow customers to opt out of collection of this data, and allow customers to inspect the data collected. Stripe's privacy policy refers to opt-out and inspection rights about certain data, but AFAICT not this.

[This is not legal advice]

[1] http://leginfo.legislature.ca.gov/faces/codes_displayText.xh...

[2] https://stripe.com/privacy#your-rights-and-choices

View on HN

I am not an attorney. This is not legal advice.

Based on a plain reading of the law, several things about CalOPPA stand out to me. For one, it's not clear to me that the mouse movements in question qualify as "personally identifiable information". Mouse movements are not a first or last name, physical or email address, SSN, telephone number, or any contact method I am familiar with (maybe you know a way?).

Second, it seems to me that opt-out, right to inspect and update, and more are all contingent upon the data being PII within the scope of CalOPPA. Perhaps you can help me with something I've overlooked that would show me where I've erred?

Further, what do you think the correct legal and ethical way for Stripe to use mouse movement data would be? From your comment I can guess that you believe it should be treated as PII. Is that correct?

> first or last name, physical or email address, SSN, telephone number, or any contact method I am familiar with (maybe you know a way?)

What about a face? Fingerprints? Voice? Aren't those identifiable information even though it didn't make your (common sensical) short list? Mouse movements are on the same order of specificity.

Edit: Also not giving legal advice.

Edit2: Please see https://news.ycombinator.com/item?id=22939145

I have yet to hear of legally binding definition of PII that involves mouse movements.

Not a lawyer, but not that surprised that the laws you refer to are growing technical loopholes. Here are a couple things that mouse movements can identify in case no one knows what I'm talking about:

https://www.researchgate.net/publication/221325920_User_re-a...

https://medium.com/stanford-magazine/your-computer-may-know-...

Thank you for bringing hard research to this discussion!

I find it interesting that the one that contemplates authentication requires supervised machine learning and goes on to explicitly state that "analyzing mouse movements alone is not sufficient for a stand-alone user re-authentication system". Taken together, this suggests that a sizable corpus of mouse movement data known to be associated with one user may qualify as PII under some definitions.

Again, thank you for sharing this timely information.

This is how we can say mouse movements can lead to privacy violation: mouse movements as such doesn't contain PII like name, zipcode or gender. But when mouse movements are run through the machine learning algorithm, it can NOT only help you to identify the person (mouse dynamics are behavioral factors and you can map across different sites. By mapping across different sites, you will learn basically the same person is surfing these three sites and valuable information for advertising world, as an example) but you can analyze the mouse movements to identify your health issues. Now you take this information and link to other publicly available databases to identify the person!! So, overall, if stripe doesn't sell this data to analyze other patterns like id or health issues, its fine...but guaranteeing it is hard.

So at Unknot.id, we learn similar patterns to detect fraud but using smartphones. But we make sure, only needed results (that is fraud or not) can be achieved and not his health or other privacy related.

It's less my short list and more the one in the text of the law being cited. Other things, such as finger-, voice-, and face-prints were probably not contemplated by lawmakers in 2003 and thus go unmentioned. They may fall under the "maintains in personally identifiable form in combination with an identifier" clause, though.

Of course, that also provides an easy way to comply. Don't store mouse movements in a way that ties them to PII under CalOPPA, and you don't meet any criteria.

Makes sense, but I don't trust it to never be tied to PII.

That's definitely a question of implementation, policy, compliance, and liability. You are absolutely correct.

The law in question also requires data to be maintained in personally identifiable form. I am uncertain if a small number of mouse movements is likely to reach this. I do not see how, but that's not a reason why it cannot be so.

you have to account for someone using a on screen keyboard to input their credentials.

Javascript code cannot see mouse movements outside of its page, like in an on screen keyboard or another webpage.

They are a minority so its likely easy to account for, stuff like tracking them by learning their IP and transaction history to mark them with certain degree of trustability; on the other hand tracking mouse movements and other techniques are essential for users you have no record of (new ip, new user, new cc, etc)

You mean on a touchscreen device, or because of a physical disability? Because the latter case seems exceptional enough that I'm not sure how that would legally work (do you have to think of all possible edge cases? What if someone uses dictation because they can't type, does that mean you'd potentially capture social security numbers if you use the microphone for gunshot detection and process the sound server-side?) and in the former case I'm pretty sure taps on a keyboard are not registered as a mouse movement in JavaScript.

> or because of a physical disability? Because the latter case seems exceptional enough that I'm not sure how that would legally work

There have been a number of accessibility-based lawsuits recently. Generally speaking, yes, you absolutely have to allow for them to use an alternative system without locking them out.

Because if your particular methodology breaks things for a people group that way, all kinds of discrimination laws become a hammer that someone can toss your way.

> allow for them to use an alternative system without locking them out

That's not what I'm arguing against, though. I was not saying: forbid screen readers. I said:

> do you have to think of all possible edge cases? What if someone uses dictation because they can't type, does that mean you'd potentially capture social security numbers if you use the microphone for gunshot detection and process the sound server-side?

Inadvertently capturing social security numbers does actually open you up to a lot of PII laws. So yes, that is still a problem.

Any time you get data from a user, you need to be careful about what you're grabbing.

mouse movements will contain personally identifiable information if the user has any kind of writing to text system turned on. You definitely can't rule it out. (not a lawyer) I think what stripe is doing is illegal

Writing-to-text tools are technographic data, not really personally identifiable information (PII), and not run in-browser.

When used with other technographic data it can be used to fingerprint a user, but without any PII, you don't know who that user is.

if they write their SSN in the tool and it gets recorded in the mouse movements, how is that not PII?

> Mouse movements are not a first or last name, physical or email address, [or one of a dozen other obvious examples]

You misunderstand what personally identifiable information is. Each individual letter of my name is also not identifiable, the letters of the alphabet are not PII, but when stored in in the same database row, the separate letters do form PII no matter that you stored them separately or even hashed or encrypted them. My phone number is also not something that just anyone could trace to my name, but since my carrier stores my personal data together with the number (not to mention the CIOT database where law enforcement can look it up at will), there exists a way to link the number to my person, making it PII. Everything about me is PII, unless you make it no longer about me.

Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person.

Another example[1] mentioned on a website that the Dutch DPA links to (from [2]) is location data. Coordinates that point to somewhere in a forest aren't personal data, but if you store them with a user ID...

[1] (English) https://www.privacy-regulation.eu/en/4.htm

[2] (Dutch) https://autoriteitpersoonsgegevens.nl/nl/over-privacy/persoo...

> You misunderstand what personally identifiable information is.

Not to belabor a point discussed elsewhere, but those were not arbitrarily chosen types of PII. They are how PII is defined in the specific law that was cited - CalOPPA. The comment to which I responded contains a link. The text of the law contains its definition of PII.

Please accept my apologies. I can see I failed to communicate clearly and readers interpreted my statements as broad comment about what is or isn't PII across a union of all potentially relevant laws and jurisdictions. This was in no way, shape, form, or manner my intended meaning. Again, please accept my apologies for failing to be clear.

> Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person.

Maybe it's just me, but I was under the distinction impression that some patterns of input are characteristic of humans and others of inhuman actors. Is it possible that a user could be identifiable as human or inhuman without having to know which specific human an input pattern corresponds to? Have I misunderstood something?

> [could one distinguish] human or inhuman without having to know which specific human an input pattern corresponds to?

You can't rely on the client asking the server anonymously and adhering to the response. If you want to avoid a connection to a "specific human", it would go like this:

Fraudulent lient: POST /are/these/mouse_movements/human HTTP/1.0 \r\n Content-Type: JSON \r\n [{"x":13,"y":148},...]

Server: that's a robot

Fraudulent client: discards server response and submits transaction anyway

To make sure the server knows to block the transaction, it has to tie the mouse movements to the transaction, and thereby to a credit card number (afaik Stripe does only credit cards as payment option), at least during the processing of the submission before discarding the mouse movement data.

I'm not arguing this is evil or mistrusting Stripe or anything, just that this is considered PII in my part of the world.

Which is absolutely fine by the law if it isn't stored tied to PII.

GDPR doesn't apply only to storage, though? Maybe I'm confusing it with the previous data protection directive but I'm pretty sure the new GDPR also defines PII processing to include things like transmitting and operating on it.

But if there is some source (e.g. case law, data protection authority) that confirms that you can process two pieces of data and keep one as non-PII if you promise not to connect them in storage or forward them to another place in an identifiable manner, that would be interesting.

> But if there is some source (e.g. case law, data protection authority) that confirms that you can process two pieces of data and keep one as non-PII if you promise not to connect them in storage or forward them to another place in an identifiable manner, that would be interesting.

It would be impossible to follow the GDPR otherwise, all data would implicitly be PII, since all data is associated with an IP address and GDPR defines IP as PII.

> GDPR doesn't apply only to storage, though?

This doesn't matter, because you can always collect data for business critical purposes, which fraud protection reasonably is.

As someone who had to implement GDPR for a DSP, that doesn't make the data PII.

Digital Signal Processor? Delaware State Police? Defense Support Program? DSP is a little ambiguous here.

Given context of GDPR, I'm assuming Demand Side Platform ("buying" half of programmatic advertising).

> You can't rely on the client asking the server anonymously and adhering to the response. If you want to avoid a connection to a "specific human", it would go like this:

I'm afraid I don't understand. Maybe you can help me? Seems to me you could not store things, you could require a signed and expiring token from the /are/these/mouse_movements/human service, or you could treat the request as super risky without that signed token. I'm sure there are others, I am known to suffer failures of imagination at times.

> To make sure the server knows to block the transaction, it has to tie the mouse movements to the transaction, and thereby to a credit card number (afaik Stripe does only credit cards as payment option), at least during the processing of the submission before discarding the mouse movement data.

I'm clearly wrong, but doesn't the logic here only work if the mouse movements are identifiable in the same sort of way that a phone number is? What happens if that's not accurate and mouse movements from a session are not so personally identifiable? What have I failed to understand? Wouldn't this logic also make transaction timestamps PII?

Your feigned "maybe you can help me?" reads more like sealioning than like a genuine lack of understanding.

However, sure, I'll humour you. A "signed and expiring token" is not sufficient because then a single attacker could use that token to try 1000s of cards before it expires.

Thus, you need a unique token, and wherever you store that unique token (to invalidate it, akin to a database session), you can optionally store the mouse movements or not. The association still exists. A unique token isn't functionally different from just sending the data along in the first place.

I think he/she is being very patient with people who don't seem to have a good understanding of the law they're citing.

Really, you read that as being patient? To me it seems to be an obvious attempt to rub the person they're replying to entirely the wrong way while feigning ignorance.

I would flag it as attempting to trigger others if each reply did not also contain one or two constructive sentences.

> with people who don't seem to have a good understanding of the law

"People" had a fine understanding of applicable PII law, but the person clarified (in between a bunch of bullshit about how godforsaken sorry they are) that they were talking about some USA thing specifically and not the broader definition.

You keep using that ridiculously apologetic tone that really rubs me the wrong way while making constructive remarks. If you could lose the former without the latter, I might actually appreciate your replies. But then, I'm reasonably sure that it's meant to annoy.

> Seems to me you could not store things, you could require a signed and expiring token

That's actually a good idea.

OK.

You didn't read the law I was talking about that was specifically and clearly linked in the initial comment to which I responded. The comment in question made a specific claim about a specific law in a specific jurisdiction to which I responded narrowly and specifically. My comment referred clearly to the law in question and summarized points from it.

All points about other laws in other locations are irrelevant to the specific points I was offering discussion of.

> That's actually a good idea.

It is... provided that a handful of mouse movements actually qualify as PII. Which, as claimed here under CalOPPA, seems like it might be doubtful. As others have pointed out, there's room to doubt that a few mouse movements would be considered PII under any current regulatory regime (there are multiple notable ones, they don't agree on all points).

As an approach, it's useful for things like SAML and OAuth protocols when you're dealing with different systems controlled by different parties and need to delegate trust through an untrusted party. It's rarely the best way to move data around inside a system, though, unless you have some compelling reason to introduce this level of blinding.

but you are giving stipe pii when you buy something directly. at that point the mouse movement is nothing. and if you dont buy something the mouse movement is not pii.

> but you are giving stipe pii when you buy something directly. at that point the mouse movement is nothing

1) but that's not how the law works

2) law aside, I'm also not sure it holds up ethically to say "you're giving them <some info necessary to fulfill your payment>, what's wrong with giving them <unnecessary other data>". Now, if you say "but it's not unnecessary, it's for anti-fraud!" then sure, that's a different argument: then the argument is not that you might as well give it because of something else you gave but because it's necessary for fraud. They could still do the courtesy of telling users before tracking them (which might bring us back to the legal argument, which tells us that is is indeed necessary to do so).

Huh? Client sends data to bot-detection server, server sends back a signed response with a nonce and an expiration date saying "Yep, this is a human". Server stores the nonce to prevent replays. Client attaches the signed validation when submitting the transaction. The server that receives that verifies the signature and expiration date, then checks and invalidates the nonce. No association between the transaction and the mouse data necessary.

I don't know if that's how Stripe is doing it, but you could do it that way.

How is the nonce not an association?

We have two possible options here:

1. Client sends mouse-data + card info to a server, server checks the mouse data, turns it into a fraudPercent, and only stores that percent. That seems to be what they're doing now.

2. Client sends mouse data, gets back a unique nonce, and then sends that nonce to the server with card info. The server could have either stored or discarded the mouse info. It's perfectly possible the nonce was stored with the mouse info.

Those two things seem totally identical. The nonce by necessity must be unique (or else one person could wiggle their mouse, and then use that one nonce to try 1000 cards at once), and you can't know that they don't store the full mouse movement info with the nonce.

You gain nothing by adding that extra step other than some illusion of security.

Note, cloudflare + tor has a similar problem that they tried to solve with blind signatures (see https://blog.cloudflare.com/the-trouble-with-tor/), but that hasn't gone anywhere and requires a browser plugin anyway. It's not a viable solution yet.

If you're going to go as far as "it's perfectly possible that the nonce was stored with the mouse info", then your example following:

> If you want to avoid a connection to a "specific human", it would go like this:

doesn't work either. It's perfectly possible that the server stored that info with the IP address and session information, since it also has access to those, and that could then be connected up with the transaction. I don't understand at this point what standard you're trying to meet, because it sounds like by what you're saying, literally any data sent to a server is "PII" if at some point that server also can, in principle, know your name.

I don't think it's PII. My point is just that your scheme of signed tokens doesn't avoid an association. There isn't a way to.

And that's fine because it's not PII and it's the only way to implement this (in my mind). What you're proposing is just shuffling around deck chairs, not actually sinking the ship.

Oh, I mistook you for the previous commenter. Yeah, I agree that what I proposed doesn't really buy you anything unless you for some reason need the mouse data not to touch the server that's processing the transaction, which seemed to be what they were saying was required. There are multiple layers to why what they're saying doesn't make sense.

Surely the point of mouse movement detection for anti-fraud is more "did the mouse move in an exact straight line to the exact center of an element and therefore isn't a human" or "the last 3 orders on this site used exactly the same pattern of mouse movements therefore is a recording" rather than some sort of "gait detection" to tell who someone is.

The purpose of processing the individual mouse positions over time may be exactly that, but I'm not sure that the intent matters. For example, a website asking for my social security number for the sole purpose of verifying whether it matches the checksum (Dutch SSNs contain a checksum) would still be processing my SSN, no? I'd be interested if I'm wrong, though.

> Each individual letter of my name is also not identifiable, the letters of the alphabet are not PII, but when stored in in the same database row, the separate letters do form PII no matter that you stored them separately or even hashed or encrypted them.

This is a correct statement, but it's implied suggestion that Stripe is doing this is incorrect. There are lots of ways around this: no storing specific keys and hashing input would be my initial impressions.

My guess is Stripe is more concerned about the action patterns than the specific keys that a being pressed.

This is an opinion and not a fact.

I don't need to know the identity of the guy wearing a balaclava and carrying a pillow case to know if that guy is in a bank and reaching into his jacket pocket, there's a high likelihood he's robbing the place.

When he shows up at the next place to rob, I don't have to have any PII on him to identify him as a robber. Might not be the same robber at both banks, but they both exhibit similar patterns. If they both limp or talk with a slur, I can reasonably connect the two without knowing the underlying identity.

> My guess is Stripe is more concerned about the action patterns than the specific keys that a being pressed.

Don't they still need to process the data server-side to derive that pattern to make a decision on it?

Yeah? It is clearly personally identifiable. In fact it is pyschologically identifiable when Stripe can associate that with your name, credit card, Ip address, time of the purchase, the vendor, type of the item, how you get to the store, the items you are paying for, how much time you spent on the item or the store, which links you clicked, the browser you are using, the device you are on, your location etc. Do you want me to list all the possibilities they are recording?. You are out of touch with reality here.

Counter-point: if your business is selling digital or physical product into New Zealand the NZ tax department requires you to collect two different types of data for the transaction that prove the customer is located in NZ. This can include IP address, phone number, address.

So, in some instances, Stripe is legally required to collect some of this data.

How does an IP address (in a world with VPN) or a phone number (which is likely to be mobile and could be located anywhere in the world) "prove that the customer is located in NZ"?

https://stripe.com/privacy describes what we do in some detail (including disclosing that we use this kind of browsing data).

More broadly, I assure you that Stripe.js and our fraud prevention technologies are very carefully designed with full compliance with the relevant California (and other) statutes in mind. I’d be happy to connect you with our legal team if you’d like to discuss this in more detail. (I'm patrick@stripe.com.)

Why not address it here publicly? I don't think you want/expect everyone observing this discussion on HN to reach out to you.

Oh, offer was made in case GP wants to have a deeper discussion/back-and-forth than is readily achievable with an online forum. Timing constraints notwithstanding, we work hard to answer questions on HN too.

For your European customers you should likely make it more clear what stripe.js does before urging them to install it on every page of their website. Using it as soon as a user has a probable interest to purchase a product (e.g. when he/she clicks on “Register” and chooses a plan) would very likely be acceptable as a legitimate interest under GDPR, tracking all users even if they don’t have a clear intent of purchasing something and e.g. only want to get information about the product will definitely not be acceptable as a legitimate interest and would therefore require clear consent first.

From a legal perspective, isn't the burden of communicating privacy to the customer on the website/content provider, not Stripe?

Stripe.js is an API -- developers use this API to build something used by their customers. The customer is the one who's data is being collected, and the developers are the one's facilitating that collection via their service. The fact that it got sent to Stripe is not really relevant to who bears responsibility on clarifying data rights to the customer.

The data is collected by Stripe, though. The content provider doesn't have access to the mouse movement data, and might not be even aware of that the data is collected.

That doesn't necessarily mean the content provider isn't responsible though. I can break a law even if I don't know that the law exists.

Fair enough, but this specific collection of data has not been clearly disclosed by Stripe (until now?).

It’s specifically different in this case: a big part of Stripe's value to a web vendor is that Stripe can collect credit-card info directly from the buyer (thereby exempting the vendor from PCI compliance and other issues related to storing and processing CCs).

"The simplest way for you to be PCI compliant is to never see (or have access to) card data at all. Stripe makes this easy for you as we can do the heavy lifting to protect your customers’ card information." [1]

Interesting question whether Stripe incurs statutory privacy duties to the web vendor and the buyer separately. I would imagine so, because given the "triangular" nature of this kind of Stripe transaction, Stripe ends up collecting data from two parties.

[This is not legal advice]

[1] https://stripe.com/docs/security

> From a legal perspective, isn't the burden of communicating privacy to the customer on the website/content provider, not Stripe?

They get the burden, but they wouldn't be able to know about evil activities from the third party provider.

In the unlikely case where Stripe was a bad player, the customer would sue the website, the website would countersue Stripe

All this existing legislation is about protecting personal data, not any data.

If what is collected is not linked to an individual and does not allow to identify an individual then these are not personal data and the legal point is moot.

You mentioned legal and ethical but only addressed the legal side. Of course legality and ethicality are not the same, can you also address the ethics side?

If Stripe are indeed tracking mouse movements to detect bot traffic (which is plausible) then that seems broadly ethical and reasonable from an ethical perspective.

In the same way that if the government is tracking our private conversations to detect human traffickers then it's broadly ethical and reasonable from an ethical perspective?

Can you explain how the privacy violation of tracking mouse movements on a subset of online markets is similar in scope or substance to tracking all conversation?

I see a number of obvious differences: I can opt out of purchasing from stripe-managed sites, while I cannot opt out of dragnet government monitoring. I can imagine less invasive ways of stopping human trafficking, while I cannot for fraud prevention, etc.

Still seems unethical if the collected data is stored or stored in a processed form. The same technology can be used to uniquely identify users across devices.

Keyword:consent.

Exactly so if your business is using stripe and customer sues you in court under CalOPPA, will stripe be cover your lawsuit and pay for it?

> The question raised is, more broadly, "Is Stripe collecting this data in a legal and ethical way?" This too can be readily answered in the negative.

I think the real issue is that in the U.S. most people's views on things like basic analytics software aren't shaped by reading books on digital privacy or taking classes on privacy law, but rather by some vague cultural memory of the holocaust. It makes it very difficult to have a rational discussion with people.

Is there a good Stripe alternate that respect customers privacy?

Square Payments?

Adyen?

Reply on news.ycombinator.com