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.)
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.
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?
> 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...
> 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.
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.
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.
> 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?
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
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.
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.
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.
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.
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.
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).
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.
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.
> 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.
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"?
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?
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)
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
> 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.
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.
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.
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:
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.
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.)
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.
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.
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.
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.
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.
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.
> 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.
In my opinion, there's no moral issue with doing this. Fighting fraud and other kinds of cybercrime is an endless cat-and-mouse game. Although there are very bad associations with it, one simply does need to use fingerprinting and supercookies/"zombie cookies"/"evercookies" if they want even a fighting chance.
I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though.
> I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though.
Is this view conditional on the type of data Stripe is currently collecting or would it apply to any data Stripe collects? Would this be true if Stripe began recording every keystroke in the app and hooked every XHR request to my backend server and sent copies to Stripe?
I agree that Stripe has a sensible reason for using this data. If I started seeing a high rate of chargebacks, I'd consider enabling Stripe on more parts of my site so that Stripe could consume user behavior earlier on to detect fraud.
My issue is that if there's no agreement about what data Stripe is allowed to collect and what their retention policies are, then the implicit agreement is that Stripe can just collect anything it has access to and hold it forever.
As JavaScript running on my page, Stripe.js has access to basically all user data in my app. There are certain types of user data I would not be comfortable sharing with Stripe, even if it improved fraud detection, so I'd like there to be clear limits on what they're gathering.
Yes, I would say it's conditional. They should be more explicit about what data they're collecting from users. Opaque enough to not reveal all of the exact techniques, but clear enough so site owners can make an informed decision. (Someone dedicated and experienced enough could probably reverse engineer Stripe.js and figure out everything it's doing if they really wanted, but they're also probably updating it regularly.)
There's no need to rely on "security by obscurity". Stripe.js is just a thin client-side library everybody can analyse, so they might as well be fully transparent when it comes to data collection. I don't see the point of trying to obfuscate things, especially since the actual fraud-detection model works on the backend anyway.
With these kinds of adversarial things, I think it's a mix of frontend and backend.
It's a library everyone can technically analyze, yes, but by 1) using ever-changing obfuscation that requires a lot of work to RE, and 2) constantly changing the client-side logic itself, it makes the work of the adversaries a lot harder and more tedious, and means either fewer of them will consistently succeed, or more of them will be forced to become more centralized around solutions/services that've successfully solved it, which means Stripe can focus-fire their efforts a bit more.
Of course there's also a lot going on on the backend that'll never be seen, but the adversary is trying to mimic a legitimate user as much as they can, so if the JavaScript is totally unobfuscated and stays the same for a while, it's a lot easier for them to consistently trace exactly what data is being sent and compare it against what their system or altered browser is sending.
It's cat-and-mouse across many dimensions. In such adversarial games, obscurity actually can and often does add some security. "Security by obscurity is no security at all" isn't exactly a fallacy, but it is a fallacy to apply it universally and with a very liberal definition of "security". It's generally meant for things that are more formal or provable, like an encryption or hashing algorithm or other cryptography. It's still totally reasonable to use obscurity as a minor practical measure. I'd agree with this part of https://en.wikipedia.org/wiki/Security_through_obscurity: "Knowledge of how the system is built differs from concealment and camouflage. The efficacy of obscurity in operations security depends by whether the obscurity lives on top of other good security practices, or if it is being used alone. When used as an independent layer, obscurity is considered a valid security tool."
For example, configuring your web server to not display its version on headers or pages is "security by obscurity", and certainly will not save you if you're running a vulnerable version, but may buy you some time if a 0-day comes out for your version and people search Shodan for the vulnerable version numbers - your site won't appear in the list. These kinds of obscurity measures of course never guarantee security and should be the very last line of defense in front of true security measures, but they can still potentially help you a little.
In the "malware vs. anti-virus" and "game cheat vs. game cheat detection software" fights that play out every day, both sides of each heavily obfuscate their code and the actions they perform. No, this never ensures it won't be fully reverse engineered. And the developers all know that. Given enough time and dedication, it'll eventually happen. But it requires more time and effort, and each time it's altered, it requires a re-investment of that time and effort.
Obfuscation and obscurity is arguably the defining feature and "value proposition" of each of those four types of software. A lot of that remains totally hidden on the backend (e.g. a botnet C2 web server only responding with malware binaries if they analyze the connection and believe it really is a regular infected computer and not a security researcher or sandbox), but a lot is also present in the client.
Thanks for a thoughtful reply (upvoted), but have you looked at the library in question? The code is minified, but there is not much obfuscation going on: https://js.stripe.com/v3/
Most of your examples are quite low-level, but it's much harder to keep things hidden within the constraints of the browser sandbox when you have to interface with standard APIs which can be easily instrumented.
Yeah, theirs is far less obfuscated than most fraud/bot detection libraries I've seen. I believe almost all of the JS code I've seen from companies that primarily do fraud detection and web security is pretty heavily obfuscated. Here, it looks like Stripe.js is doing much more than just the fraud stuff - this is their client library for everything, including payment handling.
I haven't analyzed it and can't say this with any certainty, but my guess is that you're probably right: they're focusing primarily on backend analysis and ML comparing activity across a massive array of customers. This is different from smaller security firms who have a lot less data due to fewer customers, and a kind of sampling bias of customers who are particularly worried about or inundated by fraud.
They may be less interested in suspicious activity or fingerprinting at the device level and more interested in it at the payment and personal information level (which is suggested by articles like https://stripe.com/radar/guide).
Pure, uninformed speculation, but it's possible that if they get deeper into anti-fraud in the future (perhaps if fraudsters get smarter about this higher layer of evasion), they might supplement the data science / finance / payment oriented stuff with more lower-level device and browser analysis, in which case I wouldn't be surprised if they eventually separate out some of the anti-fraud/security parts into an obfuscated portion. (Or, more likely, have Stripe.js load that portion dynamically. Maybe they're already doing this, even? Dunno.)
I’ve implemented my own Stripe checkout for a native application in just a couple of hours, using their REST API. There’s nothing stopping everyone else from doing the same: it’s literally how you used to integrate with payment gateways before Stripe came along. No one gave you a JS library to use on your website.
In my opinion, there _is_ a moral issue. Not in that they collect this information for fraud prevention; that seems like a reasonable use for that data. It's in not having informed consent, in not having a clear document describing what is collected and when it is purged. And that document would need to be consumer-facing (since it's not the vendor's behaviour being tracked).
Responding after being caught is… good, but not as good as not needing to be caught.
This is a fair call-out. We have actually worked pretty hard to ensure that our Privacy[1] and Cookies[2] policies are clear and easy-to-read, rather than filled with endless boilerplate jargon. But we still did make a mistake by not have a uniquely clear document covering Stripe.js fraud prevention in particular.
Could you explain in plain language how this is different or the same as what a credit card company does?
My outsider understanding was that credit card companies happily sell your purchase history or at least aggregate it for marketing, in addition to using your purchase history model to predict if a purchase is fraudulent.
Stripe’s very readable privacy policy makes a clear statement on this:
Stripe does not sell or rent Personal Data to marketers or unaffiliated third parties. We share your Personal Data with trusted entities, as outlined below.
From that and my reading of the rest, I think the answer is clearly no. Also I doubt the data of consumer purchases on Stripe integrated websites is even that valuable to begin with. At least compared to Stripe’s margins.
That's true. They should give more clear and explicit information so site owners can make an informed decision. Including the difference in what's collected if the script is included on just the checkout page(s) vs. on every page.
I am so sick of informed consent and cookie and GDPR etc. popups and banners and forms and checkboxes. I could not care less and neither could most people out there. This crap is ruining the internet for no tangible benefit to the inexplicable thunderous applause of people on tech websites. It didn't hurt anyone when Sears collected rewards data for advertising and it never hurt anyone when web companies used data from user interaction. A simple static webpage is going to end up impossible for anyone but a megacorp to run legally if we keep going down this nonsensical path.
Imagine I mailed you an unsolicited letter and you were legally required to burn it and never say or benefit from what was inside just because I said so. That's the insanity of these "privacy" laws.
I agree with you in general, but this is a big step up. This is essentially the most invasive, intrusive technology that can possibly be deployed on the web - because fraudsters (and other cybercriminals) use the most tricky, dynamic evasion techniques.
And this is regarding website owners adding a script that may run on every page of their site; the consent is for the website owners who are using Stripe and deciding how/if to add their script to their pages.
Or you could just not collect information you don't need? You don't have to ask consent if you just don't do it, you know. The pop-ups are annoying because the website owners want you to just click through. Ever seen one of those where you have to uncheck every single box? Yep, those violate the GDPR. The default setting should be no advertising or other bullshit data, and opt-in if you want it. Which no one ever does. Hence the violations. Get mad at the manipulative ad companies, not the people who for once produced an OK piece of regulation.
He's not the guy who is collecting data. He's the guy whose data is being collected. And I agree with him. True choice is not imposing this cost on everyone. Let me set it in my browser. Then I'll consent to practically everything and you can consent to nothing. And since it's set at your user agent you can synchronize that across devices easily.
If I never see another damned cookie popup I'd be thrilled.
The cookie law is just insane to me. GDPR, or at least the parts that are commonly talked about, seems a lot more reasonable: a user should be able to request what data is being collected about them, and should be able to request a full account deletion, including deletion of all data collected from or about them (perhaps minus technical things that are very difficult to purge, like raw web server access logs).
> a user should be able to request what data is being collected about them, and should be able to request a full account deletion, including deletion of all data collected from or about them (perhaps minus technical things that are very difficult to purge, like raw web server access logs)
I think I'd find it very easy to like this. Honestly, these aspects of GDPR are great. Things I don't like:
* Not allowed to do "no service without data"
* Consent must be opt-in
Bloody exasperating as a user. At least if they'd set it in my user agent. But the browser guys just sit there like fools pontificating on third-party cookies instead of innovating for once and placing the opt-in / opt-out in the browser.
Is this not what the DNT (Do Not Track) header was attempting to achieve before it was essentially abandoned (after being implemented in all major browsers)? Genuinely curious what sort of user agent approach you're looking for.
Actually, I've changed my mind. I think people fall into either the advertiser+publisher camp who don't want this in the browser chrome because it will make it too easy to full opt-out and the browser guys don't want it there because they actually just want the advertisers to die out. What I'm asking for is not a stable equilibrium in any way so it's a pointless thought experiment.
Pretty sure I'd get an option of "free X more articles if you give us your data to sell". Not getting that is annoying because I was fine with giving away my data for articles.
The problem is that imposing the unsafe choice (aka tracking being on by default) puts people who'd rather opt out at risk (because their data is being leaked), while the current situation merely puts an annoyance to people who are happy to opt-in.
As far as the cookie popups go the majority of them are not actually GDPR compliant. Tracking should be off by default and consent should be freely given, which means it should be just as easy to opt-in as it is to opt-out. If it's more difficult to say no than yes then the consent is invalid and they might as well just do away with the prompt completely since they're breaking the regulation either way.
Interesting question, since the web used to exist and work just fine before online advertising. I'm not saying that we should go back in time, but claiming that ads are a requirement for the web to exist is a slight overstatement.
> Interesting question, since the web used to exist and work just fine before online advertising.
For what definition of "work"? There were static informational pages and....not much else. Content that requires upkeep requires revenue requires either ads or access fees, usually.
Reddit for example has nothing to sell me directly unless it was subscription-based which is a nonstarter. There's no other model for sites like that besides maybe browser-based crypto mining.
I wouldn't be surprised if a high percentage of reddit users use something like uBlock. I think universal ad blockers are going to slowly become more ubiquitous over time, too.
People have been trying to find ways to skip TV commercials for decades. It's going to be the same with ads. When it comes to our own personal devices, advertisers can't really win in the end. They're going to have to stick to things like billboards and other things put up in cities, but even those are being protested and banned in many places.
In theory, what about reddit can't be decentralized? All it stores is text and URLs to other content. There isn't all that much actual processing or computation going on, as far as I know, besides some rank calculation stuff. Am I wrong about this?
In that case, it comes down to figuring out how to pay the developers and some kind of election process for admins. But with a site with hundreds of millions of monthly active users, surely they'd be able to figure something out. Like each user who donates $10 or more gets a little perk.
And even without decentralization, micropayments and premium perks are already a much more promising model. Lots of people are buying reddit's silver/gold/platinum/a bunch of others awards. Tinder is free by default and manages to make loads of money without showing any ads. I don't think ads are going to be a sustainable model in 10, 20, 50 years from now. I think service providers are just going to have to figure out ways to provide value to users in exchange for money, like most "meatspace" companies do.
It wouldn't be a non-starter if no other site could do the same thing without also charging for a subscription. Services like Facebook, Reddit, and Instagram all provide a service that many people find valuable. Let people pay for it.
Media businesses have been funded by advertising for hundreds of years (since the start of regular newspapers in the 1600s at least)[1]. Many internet businesses are more like media businesses than shops.
That's not going to work for plenty of services. Most people (if not everyone) are not going to pay for search, social network, instant messaging, maps, mail etc.
That seems like quite a big assumption. Younger generations today think nothing of spending $xx/month on their phone/data plans and another $x/month on each of Netflix/Spotify/etc. It's not hard to imagine the same people paying real money for social networking sites they value. Search could obviously still do advertising even without any personal data mining, since it knows exactly what you're interested in at that particular moment. Useful informational sites could run ads without the privacy invasion and tracking as well, since they also are aimed at specific target audiences. Plenty more sites would continue to run without a (direct) goal of revenue generation anyway; I see no ads on the free-to-use discussion forum that we're all reading right now.
This idea that the only viable business model on the web is spyware-backed advertising is baloney, and it always has been. There is little reason to assume the Web is a better place because the likes of Google and Facebook have led us down this path, nor that anything of value would be lost if they were prohibited from continuing in the same way.
Why would they not? If someone wants to be able to use a social network, do you really think they wouldn't pay $5/month for something they use as much if not more than Netflix? You can't do it now because other services can undercut you and rely on advertising but there is no reason it couldn't be the standard.
My browser is setup to record no history or cookies.
It can be annoying to always have to dismiss the same popups you've dismissed before, but I've never had any issues with online payments or unnecessary captchas, including using stripe.
Because fraudsters' browsers/clients/scripts are also set up to record no history or cookies, and otherwise evade detection/categorization as much as possible. Somewhat ironically, in order for them to accurately distinguish between privacy-conscious users like yourself and actual criminals, and to block criminals from making a purchase while not incorrectly blocking you, they need to collect additional data.
If you don't commit fraud, the only two issues you'll see are that:
1) a small subset of sites will refuse to complete the transaction, as their anti-fraud thresholds are set to deny likely-fraudulent browsers such as yours; and,
2) you will be much more easily fingerprinted and tracked online due to your specific combination of extremely uncommon non-default settings in your browser (which may well mitigate #1 if you're originating from a residential IP address).
If you purchase high-value audio gear or clothing or gift cards — basically, high value things can be resold on eBay immediately — you may find your transaction held for review while someone phone calls you to prove that you're you, but for everyday Amazon or etc. purchasing it's unlikely to matter at all.
> Because fraudsters' browsers/clients/scripts are also set up to record no history or cookies, and otherwise evade detection/categorization as much as possible
Ah, right, bad guys use privacy-enhancing tech, so we'd better undermine it, even if it screws over legitimate users. You know what fraudsters also tend to use? Chrome. Let's block that, shall we?
Fastmail account recovery keeps an "evercookie" which is "first time account X successfully logged in from this device" which allows us to identify that you're using a device with a long history with the account when trying to recover your account after it was stolen. Obviously we don't want to re-authenticate somebody who first logged in yesterday, because that's probably the thief - but if your computer has been used successfully to log in for the past few years, then it's more likely that the recovery attempt is coming from you (obviously, that's still just one of many things we're checking for).
Do they really? evercookie generally has a specific definition, where the application attempts to persist that chunk of data in heavy-handed, abusive, malware-like ways and repopulating it on removal with the same token when possible; usually used in fingerprinting concepts - it isn't just a normal http cookie with the expiration date set years out.
A blanket statement "we need privacy invasion to have any chance against fraud, it cannot be done without, period." without argumentation about why we need this against fraud isn't very constructive.
For example, in my experience: user pays, website gets money, website releases product. It's the user that could be defrauded, not the website. I never heard of fraud issues from the website owners' perspective in the Netherlands where credit cards are just not the main method to pay online. Fraudulent Paypal chargebacks, sure, but iDeal.nl or a regular SEPA transfer just doesn't have chargebacks. It would appear that there is a way to solve this without tracking.
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