Stripe records user movements on its customers' websites

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?

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

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.

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

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

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.

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.

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.

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

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?

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.

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?

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

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.

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.

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

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.

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

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.

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.

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.

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

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.

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?

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

That's actually a good idea.

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.

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

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.

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

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.

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.

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

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.