←back to thread

1134 points mtlynch | 1 comments | | HN request time: 0s | source
Show context
pc ◴[] No.22937303[source]
Stripe cofounder here. The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative. This data has never been, would never be, and will never be sold/rented/etc. to advertisers.

Stripe.js collects this data only for fraud prevention -- it helps us detect bots who try to defraud businesses that use Stripe. (CAPTCHAs use similar techniques but result in more UI friction.) Stripe.js is part of the ML stack that helps us stop literally millions of fraudulent payments per day and techniques like this help us block fraud more effectively than almost anything else on the market. Businesses that use Stripe would lose a lot more money if it didn't exist. We see this directly: some businesses don't use Stripe.js and they are often suddenly and unpleasantly surprised when attacked by sophisticated fraud rings.

If you don't want to use Stripe.js, you definitely don't have to (or you can include it only on a minimal checkout page) -- it just depends how much PCI burden and fraud risk you'd like to take on.

We will immediately clarify the ToS language that makes this ambiguous. We'll also put up a clearer page about Stripe.js's fraud prevention.

(Updated to add: further down in this thread, fillskills writes[1]: "As someone who saw this first hand, Stripe’s fraud detection really works. Fraudulent transactions went down from ~2% to under 0.5% on hundreds of thousands of transactions per month. And it very likely saved our business at a very critical phase." This is what we're aiming for (and up against) with Stripe Radar and Stripe.js, and why we work on these technologies.)

[1] https://news.ycombinator.com/item?id=22938141

replies(52): >>22937327 #>>22937331 #>>22937352 #>>22937362 #>>22937385 #>>22937475 #>>22937518 #>>22937526 #>>22937559 #>>22937599 #>>22937775 #>>22937815 #>>22937962 #>>22938015 #>>22938068 #>>22938208 #>>22938310 #>>22938383 #>>22938533 #>>22938646 #>>22938728 #>>22938777 #>>22938855 #>>22938884 #>>22939026 #>>22939035 #>>22939376 #>>22939803 #>>22939814 #>>22939916 #>>22939952 #>>22940051 #>>22940090 #>>22940177 #>>22940282 #>>22940315 #>>22940317 #>>22940352 #>>22940686 #>>22940751 #>>22941252 #>>22942502 #>>22942538 #>>22942710 #>>22942907 #>>22943100 #>>22943453 #>>22944163 #>>22944509 #>>22944652 #>>22945170 #>>22946136 #
threepio ◴[] No.22938646[source]
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

replies(9): >>22938707 #>>22938733 #>>22938916 #>>22939641 #>>22940272 #>>22940285 #>>22940307 #>>22940438 #>>22943152 #
Kalium ◴[] No.22938916[source]
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?

replies(6): >>22939055 #>>22939773 #>>22939959 #>>22940138 #>>22942576 #>>22942757 #
lucb1e ◴[] No.22940138[source]
> 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...

replies(3): >>22940210 #>>22942777 #>>22945387 #
Kalium ◴[] No.22940210[source]
> 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?

replies(1): >>22940376 #
lucb1e ◴[] No.22940376[source]
> [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.

replies(6): >>22940539 #>>22940557 #>>22940567 #>>22940578 #>>22940589 #>>22941143 #
DevKoala ◴[] No.22940567[source]
As someone who had to implement GDPR for a DSP, that doesn't make the data PII.
replies(1): >>22948083 #
lucb1e ◴[] No.22948083[source]
Digital Signal Processor? Delaware State Police? Defense Support Program? DSP is a little ambiguous here.
replies(1): >>22948838 #
1. ceefry ◴[] No.22948838[source]
Given context of GDPR, I'm assuming Demand Side Platform ("buying" half of programmatic advertising).