Stripe records user movements on its customers' websites(mtlynch.io)
mtlynch.io
Stripe records user movements on its customers' websites
https://mtlynch.io/stripe-recording-its-customers/
412 コメント
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
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
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?
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...
[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. 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?
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.
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.
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.
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.
> 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.
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?
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
That's actually a good idea.
> 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.
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.
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.
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.
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.
> 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.
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).
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).
[deleted]
As someone who had to implement GDPR for a DSP, that doesn't make the data PII.
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.
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.
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.
> 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?
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.
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"?
[deleted]
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.
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.
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?
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.
Any time you get data from a user, you need to be careful about what you're grabbing.
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
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.
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?
> 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
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
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.
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.
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.
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-...
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.
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.
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.
[deleted]
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 [email protected].)
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 [email protected].)
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.
[deleted]
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.
[deleted]
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.
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.
> 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
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
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
"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
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?).
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.
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.
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.
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.
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.
> 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.
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.
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.
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 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.
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.
[1] https://stripe.com/privacy
[2] https://stripe.com/cookies-policy/legal
[1] https://stripe.com/privacy
[2] https://stripe.com/cookies-policy/legal
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.
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.
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.
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.
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.
In the end its simply preference, I'm fine with it, you are not fine with it. Its then boil down to who can force other to follow.
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.
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.
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.
How is the first exasperating you as a user?
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.
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.
How do you expect the web to be funded without this advertiser data? People won't pay for every single website.
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.
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.
The same way businesses have always been funded - by selling things people think are worth buying.
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.
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.
Reddit can sell you virtual coins: https://www.reddit.com/premium
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.
[1] https://en.wikipedia.org/wiki/History_of_advertising#16th%E2...
[1] https://en.wikipedia.org/wiki/History_of_advertising#16th%E2...
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.
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.
Why are 'evercookies' necessary.
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.
What am I missing?
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.
What am I missing?
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.
Right, but I'm saying my setup is no different from the 'fraudsters' you describe, yet I have a seamless shopping experience online.
If I'm able to shop online without issues, why does everyone else 'need' an evercookie?
I'm sure it's helpful, it's the idea that it's necessary is what I take issue with.
If I'm able to shop online without issues, why does everyone else 'need' an evercookie?
I'm sure it's helpful, it's the idea that it's necessary is what I take issue with.
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.
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?
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.
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.
Addendum: I have no clue if they actually are using fingerprinting or supercookies. I just know many anti-fraud service providers do.
Hey pc, good to see you here on HN. Things like this bother me as a Stripe customer who advocates strongly for privacy. I've asked repeatedly for options which let me have more control over what exactly is happening on my page - or to have a JavaScript-free flow on Stripe.com that I can redirect users to in order to complete their card details. Another easy option would be to use subresource integrity so that I can audit each release of Stripe.js, but your team has turned this down, too. Of course, I could go full PCI, but PCI compliance is a big burden for small businesses. Do you have any plans for making Stripe more accomodating of users with privacy concerns?
Hi ddevault -- we would like to do this, and I'm very supportive in principle (and, per GP, we are perfectly fine with anyone not using Stripe.js), but our current product/engineering focus is on trying to build better tools for the businesses who are losing tens or hundreds of thousands of dollars to fraud. We think we have to first help the businesses who need help immediately. We'll probably then circle back to build products that explore more points on the [efficacy of fraud prevention] - [PCI burden] continuum.
Thanks for the info, pc! I'm worried that this is a dismissive answer, though. Stripe has been in business for 10 years, and fraud has been and will continue to be a constant battle for you. When can I expect to start seeing other problems like this prioritized?
Definitely no dismissiveness intended -- apologies. While Stripe has been in business for 10 years, Radar (our fraud prevention tool) has only existed for 3.5. We've made a good deal of progress in that time and I would guess that it's 1-2 years away from being sufficiently complete that we can start to seriously focus on things other than fraud. (As it happens, I just had a conversation about this with the guy who leads it.)
I'm not looking forward to another 1-2 years of waiting - or 3-4, schedules slip ;) - but so be it. Thanks for clarifying!
I'm in the same boat with my communication based startup. I'm being very cautious about any third-party interaction and the heavy activity from the stripe JS wasn't compatible with that.
I had to take some goofy steps to ensure that the Stripe components were limited to just the payments page and didn't bleed over into anything else.
FWIW, reading this I thought "Isn't that for fraud detection?" and then I got to the part where your agent says "it's for fraud detection"...
I'm normally against this sort of thing (even though everybody does it, it seems like) but in this case, it's clear that this really is "works as intended" at least to me, FWIW.
I'm normally against this sort of thing (even though everybody does it, it seems like) but in this case, it's clear that this really is "works as intended" at least to me, FWIW.
My thoughts exactly as I was reading. Analytics gathering that’s not related to UI improvements wouldn’t bother to collect information on pointer movements.
But it turns out to be a pretty good tool for bot detection. That’s why you can now just check a box to verify you’re human (Something about that sentence feels quite dystopian).
I just don’t see the issue with Stripe’s practice here. They have a clear business model, and selling user data could severely undermine that model.
But it turns out to be a pretty good tool for bot detection. That’s why you can now just check a box to verify you’re human (Something about that sentence feels quite dystopian).
I just don’t see the issue with Stripe’s practice here. They have a clear business model, and selling user data could severely undermine that model.
Sure, but business models change.
The main issue here is that this behavior is enabled by default and hidden. If API would be used like this, I would see no problem:
``` import { ensureUsersAreTrackedForFraudPrevention, loadStripe, } from '@stripe/stripe-js';
ensureUsersAreTrackedForFraudPrevention() ```
Of course, they will never do that, because then many developers would opt-out, and they need the masses to make fraud prevention work.
The main issue here is that this behavior is enabled by default and hidden. If API would be used like this, I would see no problem:
``` import { ensureUsersAreTrackedForFraudPrevention, loadStripe, } from '@stripe/stripe-js';
ensureUsersAreTrackedForFraudPrevention() ```
Of course, they will never do that, because then many developers would opt-out, and they need the masses to make fraud prevention work.
Likely many developers would opt-in when business sees the 5% surcharge for extra fraud.
And regardless, stripe explicitly says in their documentation that you should include stripe.js on every page of your app, so they can do tracking of pointers movements for fraud detection. This has not been hidden in any way from devs.
And regardless, stripe explicitly says in their documentation that you should include stripe.js on every page of your app, so they can do tracking of pointers movements for fraud detection. This has not been hidden in any way from devs.
If the API was used like that it could be disabled trivially by someone committing fraud.
Until someone trains a reinforcement algorithm to click the box like a human ;)
Hi Patrick, thanks for reading!
Glad to hear you're going to clarify that language in the ToS.
I'm interested to know if you're open to implementing mechanisms that limit what data Stripe collects within my app. I'm happy to help Stripe prevent chargebacks against my app, but I'd like to be in control of what parts of my app's data I hand over to help achieve that rather the current situation which basically grants the library carte blanche to vacuum up whatever data it wants.
Glad to hear you're going to clarify that language in the ToS.
I'm interested to know if you're open to implementing mechanisms that limit what data Stripe collects within my app. I'm happy to help Stripe prevent chargebacks against my app, but I'd like to be in control of what parts of my app's data I hand over to help achieve that rather the current situation which basically grants the library carte blanche to vacuum up whatever data it wants.
Yep, certainly open to that. We'll address that in the page we put together about this.
This should be a case study in how to properly handle bad press. Of course, it helps when you’re Doing The Right Thing™ to begin with, as it limits your recovery to simple reassurance of the user base. Still, it appears this is being handled exceptionally well.
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
This is kind of a straw man. These valuable data sets are typically kept by tech companies to keep a competitive edge. For example, not even Google sells or rents user data.
The more relevant question is "is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?"
My guess is that the answer to this is likely yes. Fraud prevention is the current product built on this data. But it would be shocking if the company never put the data set to additional uses.
This is kind of a straw man. These valuable data sets are typically kept by tech companies to keep a competitive edge. For example, not even Google sells or rents user data.
The more relevant question is "is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?"
My guess is that the answer to this is likely yes. Fraud prevention is the current product built on this data. But it would be shocking if the company never put the data set to additional uses.
> Is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?"
No, it's not. This telemetry is useful for helping businesses avoid crippling fraud losses and we don't use or plan to use it for anything else. I don't think investors even know about it.
We're perfectly happy with the business model we currently have!
No, it's not. This telemetry is useful for helping businesses avoid crippling fraud losses and we don't use or plan to use it for anything else. I don't think investors even know about it.
We're perfectly happy with the business model we currently have!
I'm assuming that you store the info for a length of time. Just a couple questions, if I may:
If Stripe is ever purchased or goes bankrupt, can you provide any reasonable assurances that this data won't be sold?
If your company ever receives a search warrant for those records, how will you respond?
Not really looking for in-depth answers! Thanks!
If Stripe is ever purchased or goes bankrupt, can you provide any reasonable assurances that this data won't be sold?
If your company ever receives a search warrant for those records, how will you respond?
Not really looking for in-depth answers! Thanks!
Okay thanks for the prompt response!
Hey, that's not how arguments on the internet are supposed to go :-).
Haha :)
I'll take this moment to say I appreciate how active you've been on HN responding to questions every time a Stripe article pops up.
I realize this can't be very fun for you to have this as the top result for the last however many hours.
I'll take this moment to say I appreciate how active you've been on HN responding to questions every time a Stripe article pops up.
I realize this can't be very fun for you to have this as the top result for the last however many hours.
It's not super fun per se but Stripe is an important infrastructure service and scrutiny comes with the territory. I'm always happy to answer questions.
^ What an insanely good interaction, right here.
Well, you are just 1 person though. Can you speak for the (potentially secret, never spoken until it is that time) mind of other founders and the ideas of investors now and forever in the future? That seems rather unlikely.
The problem is also, that the damage done, when/if the data at some point is sold or hacked or whatever, cannot be properly compensated. What is your personal skin in the game, if that happens, besides going for a new, probably high paid job ('cause of impressive CV of being founder of Stripe)?
The problem is also, that the damage done, when/if the data at some point is sold or hacked or whatever, cannot be properly compensated. What is your personal skin in the game, if that happens, besides going for a new, probably high paid job ('cause of impressive CV of being founder of Stripe)?
To be honest, Stripe does not need this data. To provide functionality, they collect all data on card payments, who's paying, who's the seller, seller volume. They can see which cards are used across which services and the like.
Tracking mouse clicks and URLs is auxiliary imo would not move the needle for them right now, unless they move into advertising (not impossible long term, if they go public).
Tracking mouse clicks and URLs is auxiliary imo would not move the needle for them right now, unless they move into advertising (not impossible long term, if they go public).
The cofounder says that the data they're collecting is part of the algorithm that has reduced their fraud numbers, and gives concrete data. Either they do need the data, or he's just outright lying, over and over, all across this thread.
What user data doesn't google sell?
https://developers.google.com/authorized-buyers/rtb/download...
https://developers.google.com/authorized-buyers/rtb/download...
> (CAPTCHAs use similar techniques but result in more UI friction.)
Not only are they inconvenient, but they're often inaccessible for some users. So I just wanted to say thanks for not going that way, even if the cost we must pay is some theoretical compromise in privacy.
Edit: On thinking about this some more, it occurred to me that by using a user's activities on a web page to determine whether they're a bot committing fraud, you might be inadvertently penalizing users that use assistive technologies, such as a screen reader, voice input, eye-tracking, etc. I haven't had a problem with this when doing a Stripe checkout with a screen reader, but I just wonder if this possible pitfall is something that your team has kept in mind.
Not only are they inconvenient, but they're often inaccessible for some users. So I just wanted to say thanks for not going that way, even if the cost we must pay is some theoretical compromise in privacy.
Edit: On thinking about this some more, it occurred to me that by using a user's activities on a web page to determine whether they're a bot committing fraud, you might be inadvertently penalizing users that use assistive technologies, such as a screen reader, voice input, eye-tracking, etc. I haven't had a problem with this when doing a Stripe checkout with a screen reader, but I just wonder if this possible pitfall is something that your team has kept in mind.
If they are really in full compliance with the relevant California (and other) statutes as the co-founder claimed they must have also taken the accessibility aspect into account.
We’re big-time Stripe users (ACH mostly to the tune of $300M+ annually) but soon will be branching into debit/credit & in the research so far have found the Radar product impressive.
Having this information up-front and center makes it easier to pass to our Infosec folks + another check in the transparency box.
As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already.
The JS package is really nifty and helpful though, we will be able to standup a one-off late payment page utilizing their checkout flow & one-time payments (server/client - couldn’t expose all the SKUs to folks so had to go that route instead of just client) but the fact we could use Stripe to send the emails with our branding & all we have to really do is pull the payment they owe & create a checkout session to hand-off to Stripe is pretty awesome.
Having this information up-front and center makes it easier to pass to our Infosec folks + another check in the transparency box.
As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already.
The JS package is really nifty and helpful though, we will be able to standup a one-off late payment page utilizing their checkout flow & one-time payments (server/client - couldn’t expose all the SKUs to folks so had to go that route instead of just client) but the fact we could use Stripe to send the emails with our branding & all we have to really do is pull the payment they owe & create a checkout session to hand-off to Stripe is pretty awesome.
Glad you're liking Radar!
You're right that, if you don't use Stripe.js, PCI compliance will be more work.
And, yes, you can definitely include Stripe.js only on a single page.
You're right that, if you don't use Stripe.js, PCI compliance will be more work.
And, yes, you can definitely include Stripe.js only on a single page.
We are, indeed.
As far as PCI compliance, I was just saying your comment about more work is true depending on your setup w/o using Stripe.js.
In our business we already have our own proprietary fraud models and other PII we secure, so the level of effort to keep PCI compliance for the additional Stripe components is a wash whether or not we use Stripe.js
I totally agree if you're going to use Stripe and you don't have to deal with PCI already in your normal course of business it's a complex area to navigate & using stripe.js is a much smoother path to take.
Basically goes back to basic principles, don't add more stress or work for something outside your core competencies unless necessary & in many cases, I can see where companies should just leverage stripe.js plus the UI utilities as they're well done & save a lot of time.
Big fans of Stripe, even if your ACH rates are significantly more than Wells Fargo or others :P
As far as PCI compliance, I was just saying your comment about more work is true depending on your setup w/o using Stripe.js.
In our business we already have our own proprietary fraud models and other PII we secure, so the level of effort to keep PCI compliance for the additional Stripe components is a wash whether or not we use Stripe.js
I totally agree if you're going to use Stripe and you don't have to deal with PCI already in your normal course of business it's a complex area to navigate & using stripe.js is a much smoother path to take.
Basically goes back to basic principles, don't add more stress or work for something outside your core competencies unless necessary & in many cases, I can see where companies should just leverage stripe.js plus the UI utilities as they're well done & save a lot of time.
Big fans of Stripe, even if your ACH rates are significantly more than Wells Fargo or others :P
> You're right that, if you don't use Stripe.js, PCI compliance will be more work.
That is not what @brogrammernot wrote. What @brogrammernot wrote was:
> As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already.
Note the the conclusion of "... in the same manner you should be already."
That is not what @brogrammernot wrote. What @brogrammernot wrote was:
> As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already.
Note the the conclusion of "... in the same manner you should be already."
Wouldn't it be just a server side to stripe call on a form submit? Even easier than using js (probably not as good user experience wise)
I think that you will be on the hook for PCI compliance if card data touches your server, while with Stripe.js your server never sees the card data. Of course, it's extremely stupid, because your server is still the one serving the original page and can change it to silently exfiltrate the card details if it gets compromised.
I mean, if your server is compromised, you are completely screwed, no matter what services you do or don’t use.
I believe the point was, if your server is compromised but you're using stripe.js, you're not legally on the hook for exposing CC details, even though they definitely could have been exposed.
(I have no idea if this is even true, this was just my reading.)
(I have no idea if this is even true, this was just my reading.)
> Wouldn't it be just a server side to stripe call on a form submit? Even easier than using js (probably not as good user experience wise)
Sure! You just have to also handle PCI-DSS.
One of the nasty things I've had to accept about PCI-DSS is that if you think you have a clever hack for getting around it, you probably don't. It's really a remarkable work of standards authoring.
Sure! You just have to also handle PCI-DSS.
One of the nasty things I've had to accept about PCI-DSS is that if you think you have a clever hack for getting around it, you probably don't. It's really a remarkable work of standards authoring.
Sure, you could.
We more or less do this today, but if you need to setup a new workflow to take payments (one-time or recurring) there's a lot of work already done for you in the Stripe.js ecosystem.
So in our case, to take one-time payments it would've been more work to stand-up the checkout page itself and all of that work behind the scenes. It is much easier to just create a checkout session (basically just hitting the DB to pull the outstanding payment record and creating a stripe customer if one doesn't already exist) and redirect to Stripe's checkout.
The PCI part isn't overstated either, that checkout session lives on Stripe's domain not ours and that's where payment method is collected & stored within Stripe so you're not having to worry about it.
It's pretty nifty, give it a look - https://stripe.com/docs/payments/checkout/one-time
We more or less do this today, but if you need to setup a new workflow to take payments (one-time or recurring) there's a lot of work already done for you in the Stripe.js ecosystem.
So in our case, to take one-time payments it would've been more work to stand-up the checkout page itself and all of that work behind the scenes. It is much easier to just create a checkout session (basically just hitting the DB to pull the outstanding payment record and creating a stripe customer if one doesn't already exist) and redirect to Stripe's checkout.
The PCI part isn't overstated either, that checkout session lives on Stripe's domain not ours and that's where payment method is collected & stored within Stripe so you're not having to worry about it.
It's pretty nifty, give it a look - https://stripe.com/docs/payments/checkout/one-time
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
Until it is.
Google once said their motto was "Don't be evil", look at where they are now.
Careful about those promises.
Until it is.
Google once said their motto was "Don't be evil", look at where they are now.
Careful about those promises.
Indeed -- although our business model is, I think, more closely aligned with our users. We serve only one kind of customer: businesses receiving payments with Stripe. Our revenue is a roughly linear function of that of our customers.
I appreciate the security and the clarity on this issue. I only wish you didn't sneak in a pricing increase for long-standing users a few months ago, and I wish Stripe was more honest about its enterprise pricing.
I apologize that anything about the pricing change felt sneaky. (We tried to do the opposite: we emailed every single impacted customer!) I posted a few thoughts about the refund change here: https://news.ycombinator.com/item?id=22893388.
We're not transparent about enterprise pricing since our costs on any given user are so country/business model/implementation-dependent. It's less that our sales team isn't willing to share the details and more that the models themselves are very complicated and change frequently. (Visa and Mastercard are both making big changes to their pricing this year, for example, and that will change almost all of them.)
We're not transparent about enterprise pricing since our costs on any given user are so country/business model/implementation-dependent. It's less that our sales team isn't willing to share the details and more that the models themselves are very complicated and change frequently. (Visa and Mastercard are both making big changes to their pricing this year, for example, and that will change almost all of them.)
I appreciate that. My particular beef with the enterprise negotiation experience was that Stripe lists a specific number after which they're open to negotiating and when we'd far exceeded that number (with minimal fraud risk due to the nature of our business), their answer was "You have too many Amex customers, but aren't you happy you're grandfathered into x, y, and z feature we now charge extra for [which we don't even use]".
Then shortly after, Stripe raised pricing on a model I'd just been told was grandfathered in.
Then shortly after, Stripe raised pricing on a model I'd just been told was grandfathered in.
There has to be some room for negotiation at scale, given that Shopify Payments offers lower base rates, and Stripe powers their payments.
Stripe is cheaper than most other processors and charges a flat rate for the transaction, regardless of the upstream cost. Amex is more expensive than Visa for example. A fact of doing business is that things will go up in price, as I'm sure your company also raises prices from time to time.
I think what is being mentioned is that Stripe started keeping the original transaction fees on refunds. In my opinion this is borderline fraudulent since visa/mc/amex do not keep these charges and refund them back to Stripe.
You do realize that this is a free market? If visa/mc/amex are so much better, people can use them. Charging a flat fee for a service doesn't seem that fraudulent to me.
Based on your comment you're clearly not a Stripe user, so I'm not sure why you felt the need to post this.
If visa/mc/amex are so much better, people can use them.
Stripe uses visa/mc/amex, it is not a competitor. You completely missed my point. Stripe uses visa/mc/amex to process credit card transactions, then when a refund is issued the CC companies return the charged amount to Stripe, but Stripe does not return the full amount back to the customer. They keep a percentage. This is what I consider "borderline fraudulent".
Charging a flat fee for a service doesn't seem that fraudulent to me.
But it is not a flat fee. They keep a percentage of the refunded amount. So if a customer bought a $1000 item, then changed their mind and cancelled the order 5 min later, Stripe would still keep $40 just for the fun of it. A small flat fee to cover network expenses would be more appropriate, not a percentage of the amount.
If visa/mc/amex are so much better, people can use them.
Stripe uses visa/mc/amex, it is not a competitor. You completely missed my point. Stripe uses visa/mc/amex to process credit card transactions, then when a refund is issued the CC companies return the charged amount to Stripe, but Stripe does not return the full amount back to the customer. They keep a percentage. This is what I consider "borderline fraudulent".
Charging a flat fee for a service doesn't seem that fraudulent to me.
But it is not a flat fee. They keep a percentage of the refunded amount. So if a customer bought a $1000 item, then changed their mind and cancelled the order 5 min later, Stripe would still keep $40 just for the fun of it. A small flat fee to cover network expenses would be more appropriate, not a percentage of the amount.
> Stripe would still keep $40
So you have to charge $1000 + ($40 * % of users who return + cushion) for the product. That means non-Stripe businesses can start to out-compete you on cost.
What makes it so that Stripe has such a unique position and can impact your costs and competitiveness to such a large degree?
> A small flat fee to cover network expenses would be more appropriate
That sure seems like the solution a free market in processing would settle on. Something is up.
So you have to charge $1000 + ($40 * % of users who return + cushion) for the product. That means non-Stripe businesses can start to out-compete you on cost.
What makes it so that Stripe has such a unique position and can impact your costs and competitiveness to such a large degree?
> A small flat fee to cover network expenses would be more appropriate
That sure seems like the solution a free market in processing would settle on. Something is up.
So you have to charge $1000 + ($40 % of users who return + cushion) for the product. That means non-Stripe businesses can start to out-compete you on cost.*
If you charge your customers more you will still end up paying more. The $40 was based on a 4% fee. (I'd like to make a correction, as in my case it is actually 3.5%)
What makes it so that Stripe has such a unique position and can impact your costs and competitiveness to such a large degree?
Stripe and PayPal are the biggest players in this space. There are others but they are either built on top of these two or do not have the easy API's and/or integration with other 3rd party services. PayPal was the first to start keeping the fees for refunds, and then Stripe followed.
Stripe is a great company otherwise, and I will continue being a customer but that doesn't mean that I can't get upset over such an blatant money grab.
If you charge your customers more you will still end up paying more. The $40 was based on a 4% fee. (I'd like to make a correction, as in my case it is actually 3.5%)
What makes it so that Stripe has such a unique position and can impact your costs and competitiveness to such a large degree?
Stripe and PayPal are the biggest players in this space. There are others but they are either built on top of these two or do not have the easy API's and/or integration with other 3rd party services. PayPal was the first to start keeping the fees for refunds, and then Stripe followed.
Stripe is a great company otherwise, and I will continue being a customer but that doesn't mean that I can't get upset over such an blatant money grab.
Google never promised that it would not use data for advertising. That was their whole business model from the beginning. It'd be more effective to point out specific instances where Google made an agreement not to use data for a certain purpose and later reneged on that commitment.
I get that one can object to any form of monetization of user data on principle, but pointing to Google as some kind of precedence doesn't seem sound.
I get that one can object to any form of monetization of user data on principle, but pointing to Google as some kind of precedence doesn't seem sound.
Come on, his comment is legally binding.
"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."
The language of the revised ToS could go something like "Stripe shall only use the data for fraud prevention. Stripe shall not permit the data to be used for any other purpose, inlcuding, without limitation, any use that aims to increase customer acquisition or sales of products or services."
The problem with statements like "We only use the data for X" is that this is not a limitation. It is perhaps a representation of what Stripe is doing as of the date of the ToS, however it does not mean Stripe does not have permission to use the data for any other purpose. Further, it only applies to Stripe. Another party could be using the data for some other purpose besides fraud prevention and the statement would still be true. Nothing requires that there be a sale or "rental" for another party to make use of the data.
The problem with statements like "We will never sell/rent/etc. the data to Y" is that it does not prevent Stripe from using the data to help Stripe or other parties to sell products and services. Stripe does not need to sell or rent the data to provide that assistance.
To recap, a ToS should limit how the data can be used. Stating how a company currently uses the data is not a limitation. Stating that a company will not sell or rent the data does not necessarily limit how the data can be used by that company or anyone else.
Facebook does not sell or rent data but their collection of data ultimately results in more advertising on the web, and on Facebook-owned websites. How does that happen. The first problem is the collection of data above and beyond what is needed to fulfill a user's request, i.e., the purpose for which it was collected. Ideally we could stop the unnecessary collection of user data, e.g., through law and regulation, and this would reduce the amount of data we need to worry about. The second problem is that after users "agree" to the collection of data, there are no contractual obligations on the collector over how the data can be used, other than not sharing it.
"Stripe.js collects this data only for fraud prevention -- it helps us detect bots who try to defraud businesses that use Stripe."
The language of the revised ToS could go something like "Stripe shall only use the data for fraud prevention. Stripe shall not permit the data to be used for any other purpose, inlcuding, without limitation, any use that aims to increase customer acquisition or sales of products or services."
The problem with statements like "We only use the data for X" is that this is not a limitation. It is perhaps a representation of what Stripe is doing as of the date of the ToS, however it does not mean Stripe does not have permission to use the data for any other purpose. Further, it only applies to Stripe. Another party could be using the data for some other purpose besides fraud prevention and the statement would still be true. Nothing requires that there be a sale or "rental" for another party to make use of the data.
The problem with statements like "We will never sell/rent/etc. the data to Y" is that it does not prevent Stripe from using the data to help Stripe or other parties to sell products and services. Stripe does not need to sell or rent the data to provide that assistance.
To recap, a ToS should limit how the data can be used. Stating how a company currently uses the data is not a limitation. Stating that a company will not sell or rent the data does not necessarily limit how the data can be used by that company or anyone else.
Facebook does not sell or rent data but their collection of data ultimately results in more advertising on the web, and on Facebook-owned websites. How does that happen. The first problem is the collection of data above and beyond what is needed to fulfill a user's request, i.e., the purpose for which it was collected. Ideally we could stop the unnecessary collection of user data, e.g., through law and regulation, and this would reduce the amount of data we need to worry about. The second problem is that after users "agree" to the collection of data, there are no contractual obligations on the collector over how the data can be used, other than not sharing it.
millions of fraudulent payments per day
Are there ways for transparently communicating (verifiable) stats for this claim?
To be clear, I am not saying that your claim is not true but if one thing HN has taught me, it is to always ask for data backing up claims that are tall.
Are there ways for transparently communicating (verifiable) stats for this claim?
To be clear, I am not saying that your claim is not true but if one thing HN has taught me, it is to always ask for data backing up claims that are tall.
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.
Thanks! Very glad it worked out for you. I quoted you in my response at the top -- hope you don't mind. (Can remove if you prefer.)
No worries. I am glad Stripe was there to help us when we needed it
Having worked with payments on a number of products it's really not a tall claim at all. On a small product that's an offshoot of a large media company we had the luxury of firewalling off a lot of countries, prior to that we'd see thousands of fraudulent attempts / payments a week. A lot of them are people iterating through lists of stolen card numbers looking for ones that are still working, so while the actual number of people / bots doing it might be lowish the volume of attempted charges can be huge.
I used to work on fraud detection on a product with transactions totaling billions of dollars a year, and for a period of time we could have stopped something like 90% of our fraud attempts (with like a 99% accuracy rate) by simply blacklisting IPs from Turkey, Vietnam, Ghana, and Nigeria.
Very interesting. By any chance do you have recommended engineering/product reading around this?
Even if they're blog posts from eng/prod teams that would be a huge favor.
Even if they're blog posts from eng/prod teams that would be a huge favor.
Not sure what verifiable stats could look like here, I'm afraid... but I can assure you that it is in fact true!
For one, some definitions would be nice. How do you define "fraudulent payments"? If I tried to checkout while on VPN and firefox with resistfingerprinting enabled, and your antifraud system stopped me, did that count toward your "millions per day"?
We build models that predict P(payment charged back as 'fraudulent') and then let small random samples through in order to test the accuracy of our predictions. This calibration means that we can compute a pretty accurate "true" total from those we have blocked.
Out of curiosity, when a transactions is part of one of those random samples and is flagged as fraudulent, are the costs/impacts to the merchant the same as any other fraud chargeback/dispute (particularly those that don't use Stripe Chargeback Protection)?
The question was interesting. Too bad we did not get an answer here.
Thanks for responding Patrick, as I said I actually do believe that the claim you're making is not false.
I am always curious about/collecting patterns successful teams leverage for solving problems that I consider important.
Being able to communicate fraudulent payments that Stripe blocks is definitely one of them.
I was being a bit selfish when I asked that, my thought process was like; "Going forward data-collection is going to be scrutinized much more than now and rightfully so. If I ever run a business where we collect data for a very important use case I would want to make sure that we are able to communicate what, why, and how with utmost level of transparency)."
Hope that puts some context to my question, it was a good-faith question. :)
I am always curious about/collecting patterns successful teams leverage for solving problems that I consider important.
Being able to communicate fraudulent payments that Stripe blocks is definitely one of them.
I was being a bit selfish when I asked that, my thought process was like; "Going forward data-collection is going to be scrutinized much more than now and rightfully so. If I ever run a business where we collect data for a very important use case I would want to make sure that we are able to communicate what, why, and how with utmost level of transparency)."
Hope that puts some context to my question, it was a good-faith question. :)
Awesome response, handled exactly as it should have been. There was a clear ambiguity in the terms, clarified and then codified.
I didn't even read the article. I immediately clicked through to the comments because I knew Patrick would clarify it. Stripe is one of a handful of companies I actually trust.
I recently was denied a credit application because I used Linux when I filed out the application. Not only that, but they still ran my credit. They even told me on the phone the reason they denied my application because I was using a suspicious browser (Chromium).
Let's be honest here. Stripe.js may be about fraud prevention, but what that means is that you'll use every method available to gather data about that individual to build an identity. Then in 3 years when someone changes positions, that system will end up getting compromised, sold to the highest bidder, shared with some government agency, or used for nefarious purposes.
This will be tied to all their IP, OS information, transactions, etc. Just like they are using facial recognition at several retail stores. They make you use a chip reader now for credit/debit transactions, but it has no use online. I'd rather see an open-source universal effort towards decentralized currency, voting, identity, etc.
Let's be honest here. Stripe.js may be about fraud prevention, but what that means is that you'll use every method available to gather data about that individual to build an identity. Then in 3 years when someone changes positions, that system will end up getting compromised, sold to the highest bidder, shared with some government agency, or used for nefarious purposes.
This will be tied to all their IP, OS information, transactions, etc. Just like they are using facial recognition at several retail stores. They make you use a chip reader now for credit/debit transactions, but it has no use online. I'd rather see an open-source universal effort towards decentralized currency, voting, identity, etc.
I'm running into more and more things that claim they don't support Firefox on Linux. We're headed to browser monoculture
Having worked at an ML fraud prevention company, can confirm that this is a pretty standard part of a fraud prevention stack. It's essentially used to block credential stuffing. There's a high probability your bank also does this.
There's a difference between doing collecting data on your own site and doing it on third-party sites so banks are a bad example (unless your banks work differently than mine).
Banks only don’t do it on third party sites as they very rarely have third party endpoints. If they did, they would do it there too. If you want an example of another payment processor that does this - Authorize, PayPal, WorldPay will all do this too.
While I believe this, you might want to add a way for the developer to disable certain GET variables or pages from being sent. I doubt sending everything helps Stripe detect fraud.
Yes, this is a good point.
You can already selectively include it on pages. And it doesn't make sense to me to "disable certain [parts of the url]".
Some websites send sensitive or identifying data in their GET variables. I personally have analytics data on my pages I don't want to give to Stripe for no reason and definitely does not help them track fraud.
Here's hoping it also reduces the exorbitant amount of false positives we've been seeing with Stripe's fraud prevention services, which cost us a lot in lost legitimate sales.
I'm sorry to hear that! Feel free to email me ([email protected]) and I'll connect you with the team if you'd like us to do a deeper dive.
But, yes, part of the intent here is to enable us to achieve better ROC[1] in our models and to block more fraud while also encumbering fewer false positives. From our testing, it's very clear that these bot-detection techniques do substantially improve the accuracy when compared to other, coarser heuristics.
[1] https://en.wikipedia.org/wiki/Receiver_operating_characteris...
But, yes, part of the intent here is to enable us to achieve better ROC[1] in our models and to block more fraud while also encumbering fewer false positives. From our testing, it's very clear that these bot-detection techniques do substantially improve the accuracy when compared to other, coarser heuristics.
[1] https://en.wikipedia.org/wiki/Receiver_operating_characteris...
A user shouldn't have to email a cofounder to get in touch with a team member. The last time I integrated stripe on a site as a final test before it went live I had my cousin make a purchase and the site got flag as potential money laundering because we had the same last name. At the time literally zero customer service. It took 8 years before stripe started doing any customer support. Cool launch pages but personally I'll never use stripe again
I've always launched with fraud turned down. The bots don't know you're there yet and Stripe can figure out your traffic. Then, you can turn it up once you get a few dozen or so sales under your belt.
We have the opposite problem. People with 50 carding attempts and radar scores of 30 or so. There is no value in Radar if so many of these cases pop up because you can’t really tell the truth from the false.
We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases.
Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.
We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases.
Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.
It isn't the only source for getting support for a particular issue, calmate.
"This data has never been, would never be, and will never be sold to advertisers or any other third parties. "
Does this mean it "will not be shared with or rented to" advertisers?
Does this mean it "will not be shared with or rented to" advertisers?
“Will never be sold” is an unprovable claim. I assume if any company has a liquidity crisis, all assets are up for sale.
Yes.
This goes without saying but I love it when Patrick jumps in to respond to stuff like this on here (and always thoughtfully, too).
There's many instances when someone from $company shows up in one of these threads on "$company is doing something nefarious" to do damage control... and I think this is the first one that doesn't reflect poorly on the $company in question.
The reason for this is that Stripe did do something wrong, and it wasn't in the script - it was in the disclosures and communication surrounding the script. So rather than PR spin, this is actually addressing the real problem.
To all other companies (and Stripe on some other day), this one thread is the exception that proves the rule that damage control in internet comments is a bad look.
The reason for this is that Stripe did do something wrong, and it wasn't in the script - it was in the disclosures and communication surrounding the script. So rather than PR spin, this is actually addressing the real problem.
To all other companies (and Stripe on some other day), this one thread is the exception that proves the rule that damage control in internet comments is a bad look.
Updating the TOS on the Stripe site doesn't really apply when the site executing the script is the site that consumes the API. The user of the consumer site never sees the Stripe TOS.
> 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.
Can someone give an example of the kind of fraud schemes involving bots that this would stop? What are the bots programmed to do, how does it benefit the owner of the bots and how do you detect it?
Can someone give an example of the kind of fraud schemes involving bots that this would stop? What are the bots programmed to do, how does it benefit the owner of the bots and how do you detect it?
Sure -- one very common form of attack is "card testing". Here's a quick summary: https://www.forbes.com/sites/tomgroenfeldt/2017/05/02/card-t....
My startup was recently facilitating card testing attacks via the Stripe checkout on our website. It wasn't small purchases, but just started and cancelled transactions.
Unfortunately, I was not alerted by Stripe, but by a "customer" whose credit card number had been stolen somewhere and who saw on his statement our company name (I'm not sure how, since the attackers don't complete the transaction).
The startup is dormant, so checking the Stripe dashboard isn't part of my daily routine. Or even my monthly routine. Even when it was active, we had only a handful of transactions - it's a niche market.
I contact Stripe customer support only because I thought the email from the "customer" could be a phishing attempt. Stripe customer support saw the logs and helped me roll a new public key. When I asked why I wasn't informed of such impossibly high token creation, the answer was that it wasn't a feature. When I checked the dashboard logs, I found that there had been 75k tokens created in the last 28 days (100% card testing). That's 75k stolen credit cards that my website (and Stripe) have helped to validate - and just in the last 4 weeks.
For all the promise of AI, I'd be happy just to get an alert that 75k tokens were created in four weeks, while exactly 0 (zero) completed transactions in the same period.
Unfortunately, I was not alerted by Stripe, but by a "customer" whose credit card number had been stolen somewhere and who saw on his statement our company name (I'm not sure how, since the attackers don't complete the transaction).
The startup is dormant, so checking the Stripe dashboard isn't part of my daily routine. Or even my monthly routine. Even when it was active, we had only a handful of transactions - it's a niche market.
I contact Stripe customer support only because I thought the email from the "customer" could be a phishing attempt. Stripe customer support saw the logs and helped me roll a new public key. When I asked why I wasn't informed of such impossibly high token creation, the answer was that it wasn't a feature. When I checked the dashboard logs, I found that there had been 75k tokens created in the last 28 days (100% card testing). That's 75k stolen credit cards that my website (and Stripe) have helped to validate - and just in the last 4 weeks.
For all the promise of AI, I'd be happy just to get an alert that 75k tokens were created in four weeks, while exactly 0 (zero) completed transactions in the same period.
> but by a "customer" whose credit card number had been stolen somewhere and who saw on his statement our company name (I'm not sure how, since the attackers don't complete the transaction)
I detected a hacked database this way. My credit card (a burner from privacy.com) notifies me of any transaction, including pre-authorizations.
Most likely your customer saw the pre-auth show up.
I detected a hacked database this way. My credit card (a burner from privacy.com) notifies me of any transaction, including pre-authorizations.
Most likely your customer saw the pre-auth show up.
> (I'm not sure how, since the attackers don't complete the transaction).
Its called "pre-auth" or "pre-authorization". It will show up on your statement for up to 48 hours but then will disappear since transaction is not "settled". During this period you would see a descriptor of transaction like NIKE NEW YORK 310XXXX, or if its dynamic/soft descriptor and merchant is utilizing it, it may say your order number and store like NIKE.COM 11-3939329.
Its called "pre-auth" or "pre-authorization". It will show up on your statement for up to 48 hours but then will disappear since transaction is not "settled". During this period you would see a descriptor of transaction like NIKE NEW YORK 310XXXX, or if its dynamic/soft descriptor and merchant is utilizing it, it may say your order number and store like NIKE.COM 11-3939329.
> Credit card testing, a tactic used by fraudsters to test stolen credit card numbers with small incremental purchases before making large-dollar purchases on the card
Testing for what? That the card hasn't been cancelled or has zero money on it? Can they test for how much money is on the card or anything else useful?
And they need bots because they might have say 1000s of cards from a database hack and most of the cards won't be useful?
What kind of large dollar purchases would someone try to make once a card has been confirmed? Why not let bots attempt lots of large dollar purchases?
Testing for what? That the card hasn't been cancelled or has zero money on it? Can they test for how much money is on the card or anything else useful?
And they need bots because they might have say 1000s of cards from a database hack and most of the cards won't be useful?
What kind of large dollar purchases would someone try to make once a card has been confirmed? Why not let bots attempt lots of large dollar purchases?
They test the cards so that they can sell the card list and promote such a sale with assertions about how much of it is good (100% tested, etc).
These brokers don't want to get involved in any significant fraudulent charges for various reasons.
These brokers don't want to get involved in any significant fraudulent charges for various reasons.
Once you have a stolen card though, what large purchases could you realistically get away with that won't leave an audit trail right back to you?
Lots of ways to monetize a working stolen card, although as GP says, the people stealing the credit card information are generally selling those cards to other people who'll actually try to turn them into cash. Gift cards and any sort of virtual currency are always big and easy. Buying advertising for affiliate marketing works. If you're willing to take on more risk, ordering actual physical goods to be delivered to empty houses and picking them up there - back in the day, we caught a guy who was ordering a bunch of iPods online, having them delivered to a bunch of houses in a development that wasn't finished yet, and then just following the UPS truck around when they got delivered and picking them up off the front doorsteps.
Given that gift cards and virtual currencies are obvious and common approaches, could banks or payment processors not somehow put up big restrictions on cards being used for sudden large purchases on products like this?
At the end of the day, there's a lot more legitimate transactions than fraudulent ones. It's very difficult to restrict a particular type of purchase en masse without having a huge false positive rate. That's exactly why companies like Stripe work so hard on developing signals to feed into their fraud models.
Gift cards are one of the biggest avenues
Thanks for posting this explanation and making an effort to update your terms of service to call out this behavior.
We appreciate that you are intent on fixing this, it helps us know that there are honest people working at Stripe and helps clear the fog that what seem to be a lot of us believing you are doing malicious things.
I hope you and your family stay healthy during this pandemic.
We appreciate that you are intent on fixing this, it helps us know that there are honest people working at Stripe and helps clear the fog that what seem to be a lot of us believing you are doing malicious things.
I hope you and your family stay healthy during this pandemic.
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
I don't think first-order data access is really the problem here, but rather where that data is going in general and who is authorized to access it, for how long, etc., and the volume of data any one person has access to at one time.
I don't think first-order data access is really the problem here, but rather where that data is going in general and who is authorized to access it, for how long, etc., and the volume of data any one person has access to at one time.
>This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
Is there a reliable, independent way your customers can verify this statement is true?
Or is it perhaps your position that there is no legitimate reason for people to want this?
And let me add that "Nobody else does this" is not a suitable answer.
Is there a reliable, independent way your customers can verify this statement is true?
Or is it perhaps your position that there is no legitimate reason for people to want this?
And let me add that "Nobody else does this" is not a suitable answer.
> 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
So, in order of Stripe to make more money (1.5% less fraud), you chose to track everybody.
Probably me too. Thanks for that.
So, in order of Stripe to make more money (1.5% less fraud), you chose to track everybody.
Probably me too. Thanks for that.
>> Stripe records the full URL, including query parameters and URL fragments (e.g., /account?id=12345#name=michael), which some websites use to store sensitive information.
Can you comment on this part as well? If you collect sensitive data unbeknownst to website owners and users you are most likely in for some trouble (i.e. gdpr)
Can you comment on this part as well? If you collect sensitive data unbeknownst to website owners and users you are most likely in for some trouble (i.e. gdpr)
>This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
I chortled a bit. Everything beyond has is questionable, though I believe there is sincerity about past actions and maybe even ethical business considerations.
If location data can be used for supplemental revenue in a fashion that won't hurt revenue more than help revenue, it will, it's only a question of when. It may or may not be advertising, but it absolutely will be used for all sorts of functions beyond fraud detection (if it's not already), especially once Stripe is publicly traded and/or gobbled up by some other massive business.
I chortled a bit. Everything beyond has is questionable, though I believe there is sincerity about past actions and maybe even ethical business considerations.
If location data can be used for supplemental revenue in a fashion that won't hurt revenue more than help revenue, it will, it's only a question of when. It may or may not be advertising, but it absolutely will be used for all sorts of functions beyond fraud detection (if it's not already), especially once Stripe is publicly traded and/or gobbled up by some other massive business.
It's nice when you go into the comments expecting the worst, that Stripe are now one of the bad guys after all, only to find a perfectly reasonable explanation and a clarification from someone talking plain english. Nice.
As an end user, can you provide me with all of the event data you have collected about me? Or does Stripe help sites that integrate stripe.js to respond to data requests?
Ie, CCPA / GDPR says I have the right to see and correct it if I live in one of those jurisdictions.
Ie, CCPA / GDPR says I have the right to see and correct it if I live in one of those jurisdictions.
You could send a subject access request to [email protected] - it would be interesting to see how they respond if you share the unique identifier mentioned in the article.
CCPA has a Right to Access like GDPR does, but it does not have a Right to Rectification.
Under both laws, if Stripe claims to be a Processor/Service Provider, then they have an obligation to facilitate sites using Stripe to respond to access requests. But they have no obligation to process those requests themselves. I think CCPA requires they direct you to the actual Controller, but that's one aspect of CCPA that has changed since December.
Under both laws, if Stripe claims to be a Processor/Service Provider, then they have an obligation to facilitate sites using Stripe to respond to access requests. But they have no obligation to process those requests themselves. I think CCPA requires they direct you to the actual Controller, but that's one aspect of CCPA that has changed since December.
This seems like a pretty good reason to phone home with this data, but ... sending back urls WITH query params? It’s pretty common for sensitive data to be in query params, sometimes even things like bearer tokens. I can’t see how query params would be very useful for fraud detection, and sensitive data like this is something you really want to avoid collecting, IMO that’s low hanging fruit to remove.
That's just bad application design to have sensitive info in the URL.
You're expecting people to trust Stripe.
The problem is that there's not much reason left to trust tech companies by default.
The problem is that there's not much reason left to trust tech companies by default.
This isn't Stripe's fault here, but if to make a payment online you need to track everyone just to make sure the transaction isn't fraud, then the system is broken.
Why can't online payments use a use two-factor authentication by default?
Why can't online payments use a use two-factor authentication by default?
Because, "business". That is, sales will drop for anyone who does this.
That's friction that will reduce sales, and online sellers will move to a provider that does not do this. Stripe would go out of business if it made it more difficult to buy things.
That's friction that will reduce sales, and online sellers will move to a provider that does not do this. Stripe would go out of business if it made it more difficult to buy things.
Put your money where your mouth is, and put in the terms that this data will ever be sold/rented to advertisers. If it is, pay a penalty of $25 per datapoint.
Also, if not advertisers, who will get this information? Make it any “third party”.
Also, if not advertisers, who will get this information? Make it any “third party”.
Woohoo bury mob
It's like installing anti-cheating rootkit to windows kernel. It's like recording your voice, taking retina scan, requiring you to take off your clothes and bugging a GPS device on you before swiping a card in a physical shop. How can it be possibly OK? For fraud prevention? Yes, if every customer were under 24/7 surveilence, there wouldn't be frauds (nor terrorists). Unless they were too smart to hack all the devices and fake the data. It is very wrong and there is no way it can be justified to monitor all URLs and mouse movements before the payment. Having javascript available doesn't mean you are allowed use it for spying on customers! Black Mirror in real life. It will get worse if people accept this and agree with this. Quite sad. :(
How can you say "...will never be sold/rented/etc. to advertisers"? Are you the fortune teller or a prophet? In case of a new CEO or changed ownership everything can change...
Does that kind of data even have value for advertisers ?
Beside the user tracking cookie I personally think the rest is fine if Stripe cannot tell some kind of buyer pattern (and sell it).
Beside the user tracking cookie I personally think the rest is fine if Stripe cannot tell some kind of buyer pattern (and sell it).
Be careful with that. We have seen recently (see social distancing apps) that even public health does not justify invasion of privacy, so why should online fraud?
Can you please go into more detail about the exact method that “sophisticated fraud rings” use to attack? Like what specifically do they do, please ELI5
And how much GDPR risk?
Is it not the case that sites using this would have to explicitly gain consent from visitors to capture data in advance?
Is it not the case that sites using this would have to explicitly gain consent from visitors to capture data in advance?
Under GDPR, no. Fraud detection is the canonical Legitimate Interest, and the only one mentioned by name in the text of the law.
PECR is a different matter. That's more restrictive but I'm not sure about the exact contours of what's considered "essential."
PECR is a different matter. That's more restrictive but I'm not sure about the exact contours of what's considered "essential."
I don’t think recital 47 allows carte blanche data collection in the name of fraud detection, and at the very least I would think there is an obligation for disclosure of the data collection, a mechanism to access it (DSAR) and the ability to correct inaccuracies.
You're correct about all of these points. GDPR still means that the principles of transparency, purpose limitation, data minimization, etc. are in play, as are data subject rights like access, rectification, and erasure. I was only addressing the specific issue of consent from your previous comment. Consent wouldn't be necessary if there's a different legal basis, and fraud detection qualifies as a Legitimate Interest.
Note that collecting consent still doesn't give you carte blanche to collect all the datas. The principle of data minimization still restricts you to only the data you need for the purpose you state when gathering consent.
Note that collecting consent still doesn't give you carte blanche to collect all the datas. The principle of data minimization still restricts you to only the data you need for the purpose you state when gathering consent.
For the avoidance of doubt, the main point of my comment was the not insignificant risk (a maximum fine of 20 million euro or 4% of turnover if that is greater) if a data controller does not meet the obligations of the GDPR.
Consent, as you point out, is only one aspect of this.
Consent, as you point out, is only one aspect of this.
> was the not insignificant risk (a maximum fine of 20 million euro or 4% of turnover if that is greater)
Facebook and Google are still around. There is absolutely zero risk of any significant GDPR fine as long as the biggest offenders are allowed to run freely.
Facebook and Google are still around. There is absolutely zero risk of any significant GDPR fine as long as the biggest offenders are allowed to run freely.
Facebook and Google have very deep pockets and are taking lots of steps to comply with the letter, but arguably not the full spirit of GDPR.
I think it would be unsafe to assume that there is zero risk of significant GDPR fines on the basis that the regulatory bodies have not picked a battle with google and Facebook.
Smaller organisations that seem to be doing less to respect GDPR are probably an easier starting point for regulators to begin enforcing the law.
I think it would be unsafe to assume that there is zero risk of significant GDPR fines on the basis that the regulatory bodies have not picked a battle with google and Facebook.
Smaller organisations that seem to be doing less to respect GDPR are probably an easier starting point for regulators to begin enforcing the law.
There's absolutely more than zero risk. In Denmark a medium sized taxi company was fined $200,000 for keeping their customer data longer than necessary.
Also: How are Google and Facebook offenders of GDPR?
Also: How are Google and Facebook offenders of GDPR?
I think this is exactly the point. Smaller companies (like stripe), that play fast and loose (maybe not stripe) with European customers’ data are a good target for regulators to make a point.
It seems like sending users to the new Stripe-hosted Checkout would probably be better for everybody, too.
From my naive perspective, if the CC or other provider validate the customer's credentials all is good and you get paid. Integration of a payment method seems fairly simple and straightforward (I'm not a web dev).
I don't really know about the types of fraud that are possible and what a Saas should be prepared for.
Question: what are the typical fraudulent activities and their symptoms?
I don't really know about the types of fraud that are possible and what a Saas should be prepared for.
Question: what are the typical fraudulent activities and their symptoms?
i worked for a company that made tools like this for diagnosing ui flow issues with machine learning, its possible and likely some companies use this for tracking their users, but it has some meritable uses as well.
[deleted]
Since when do billionaire CEOs respond to these types of posts?
It could be disclosed with a court order though, right?
Don't get me wrong, but a lot of CTOs said so in the past...including the one responsible for the infamous google PREF cookie that helped the NSA spy on literally the whole planet due to how google safe browing service has to be implemented.
As long as there's no control, your statement is worth nothing. Even if you are acting morally correct with the data, your future replacement might not.
PayPal were the good guys, too, until they were not.
In my opinion these tracking mechanisms are not GDPR compliant, as there's no opt-out possibility.
As long as there's no control, your statement is worth nothing. Even if you are acting morally correct with the data, your future replacement might not.
PayPal were the good guys, too, until they were not.
In my opinion these tracking mechanisms are not GDPR compliant, as there's no opt-out possibility.
If it's recorded and transmitted it can be intercepted by intelligence agencies.
How long is this data retained, and what does it actually include?
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
Unless Stripe goes bankrupt, in which case it'll be liquidated along with all the other assets.
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
Unless Stripe goes bankrupt, in which case it'll be liquidated along with all the other assets.
I'll ask our legal team if we can somehow contractually preclude ourselves from sharing this data in the case of liquidation or otherwise bind ourselves in a useful fashion...
To your question about what the data actually includes and what the retention policies are -- we'll put together a summary of this on the page I mentioned in GP.
To your question about what the data actually includes and what the retention policies are -- we'll put together a summary of this on the page I mentioned in GP.
If you get clarity on liquidation, please consider open sourcing it à la YC's startup documents. It's something I've long wanted to include in my projects.
I hope the result has some teeth to it, and I'd like to see follow up once this item is complete.
If I were negotiating for a vendor to collect such an invasive level of personal data about me or my customers, I would insist on accordingly strong protections.
At a minimum there should be clause in your ToS making our consent expressly contingent on you upholding your protection commitments, particularly around what data is collected, who it's shared with, and when it is destroyed or 100% anonymized. It should insist you have contracts containing terms of equal strength in place with any of your vendors, subcontractors, partners, etc. who might conceivably gain access to the sensitive data.
The clause should be written such that the liability follows along to any assigns, heirs, successors, etc, and it should be excluded from any loopholes in other portions of the contract (particularly any blanket ones which allow you to change the ToS without gaining fresh, explicit consent) and preferably free from any limitations of liability.
I'm glad Stripe is taking a responsive approach to the matter and I hope you'll consider this feedback when you revisit your legal agreements.
If I were negotiating for a vendor to collect such an invasive level of personal data about me or my customers, I would insist on accordingly strong protections.
At a minimum there should be clause in your ToS making our consent expressly contingent on you upholding your protection commitments, particularly around what data is collected, who it's shared with, and when it is destroyed or 100% anonymized. It should insist you have contracts containing terms of equal strength in place with any of your vendors, subcontractors, partners, etc. who might conceivably gain access to the sensitive data.
The clause should be written such that the liability follows along to any assigns, heirs, successors, etc, and it should be excluded from any loopholes in other portions of the contract (particularly any blanket ones which allow you to change the ToS without gaining fresh, explicit consent) and preferably free from any limitations of liability.
I'm glad Stripe is taking a responsive approach to the matter and I hope you'll consider this feedback when you revisit your legal agreements.
Thanks for answering questions about this and being so open! In your top-voted comment, you claimed that this data will never be sold to advertisers. Are you now saying that you're unsure? If so, it would be helpful to update the comment, since it seems it's not accurate.
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers
Will you post the response from the legal team here or is there some other place we should watch like the blog?
> I'll ask our legal team if we can somehow contractually preclude ourselves from sharing this data in the case of liquidation or otherwise bind ourselves in a useful fashion...
Attack real problems on all flanks, but I don't think you can get an affirmative from Legal.
Do you have cryptographers on staff? The "technology as a contract" approach is to implement a homomorphic encryption technique to do your cross-site correlation without being able to unmask the individual who is using multiple sites.
That way you don't have to trust your users, customers, sysadmins, big-data people, LEO, OR creditors. Keep it as secret sauce, or even better, drop an open-source library on github to advance the state of privacy. I would like to be able to ask vendors, "why AREN'T you protecting users' privacy this way?".
Attack real problems on all flanks, but I don't think you can get an affirmative from Legal.
Do you have cryptographers on staff? The "technology as a contract" approach is to implement a homomorphic encryption technique to do your cross-site correlation without being able to unmask the individual who is using multiple sites.
That way you don't have to trust your users, customers, sysadmins, big-data people, LEO, OR creditors. Keep it as secret sauce, or even better, drop an open-source library on github to advance the state of privacy. I would like to be able to ask vendors, "why AREN'T you protecting users' privacy this way?".
> Unless Stripe goes bankrupt
Yep. Also: sale, acquisition, merger, as well as government requests for data, and third party access. Speaking from experience selling a company, it’s difficult to plan for unknown eventualities, and even more difficult to keep any promises about what happens to data you have. The only effective way I know of to guarantee data you have doesn’t get shared is to delete it.
Yep. Also: sale, acquisition, merger, as well as government requests for data, and third party access. Speaking from experience selling a company, it’s difficult to plan for unknown eventualities, and even more difficult to keep any promises about what happens to data you have. The only effective way I know of to guarantee data you have doesn’t get shared is to delete it.
IANAL and I don't claim to understand any of this well, but I would naively assume that if Company A collected data under a binding legal agreement that they can only use it for X, then they go bankrupt, that shouldn't give Company B the ability to buy the data as a "liquidation asset" then do anything they feel like with it. Shouldn't the binding restrictions "move" with the data?
This depends on how the company is liquidated/sold. In the cases I mentioned of sale or acquisition, often the corporate entity remains in existence through the transition, so the effect is that nothing changes wrt the binding legal agreement, but a large group of new people gain access to the data. Also while legal agreements are binding, they can usually be changed, it takes some careful planning to prevent a contract from being changeable by the new owner of the contract. Think about the question of who owns the collected data in the first place. If the company owns it, and the investors own the company, the company might have a tough time getting investors to agree to waive their right to sell what they consider to be a valuable asset in the case of bankruptcy. If the company doesn't ask the investors, or can't get them to agree, then whatever they do has grounds for future legal challenge. It's all around better to delete any such data before anything changes hands.
If a company as big as Stripe hasn't already considered this and have to ask their legal team then they are playing dumb.
I honestly don't think it's that simple, and in fact I suspect it gets harder the bigger the company. They could have every intention, even a plan and an working implementation today to keep any data they collect out of the hands of a buyer or the government, and still have a very hard time ensuring it when the time comes. It does sound like @pc is actively committed to it though.
I don't think anyone's playing dumb. I am completely speculating, yet absolutely certain, that they have actually considered future scenarios for collected data, and I believe that there are legitimate reasons to still need to discuss this and other scenarios that come up with a legal team every time. If it's not clear why this can happen, it will become clear if/when you run a company.
It's true that not collecting any data is a foolproof way to guarantee it doesn't get into the wrong hands, but that's tying both arms behind your back in the online world, and it would mean in this case choosing to not train any fraud detecting neural networks. There could be an even bigger mob if Stripe knew how to prevent certain kinds of fraud and chose not to for ambiguous privacy reasons.
I don't think anyone's playing dumb. I am completely speculating, yet absolutely certain, that they have actually considered future scenarios for collected data, and I believe that there are legitimate reasons to still need to discuss this and other scenarios that come up with a legal team every time. If it's not clear why this can happen, it will become clear if/when you run a company.
It's true that not collecting any data is a foolproof way to guarantee it doesn't get into the wrong hands, but that's tying both arms behind your back in the online world, and it would mean in this case choosing to not train any fraud detecting neural networks. There could be an even bigger mob if Stripe knew how to prevent certain kinds of fraud and chose not to for ambiguous privacy reasons.
FTFY: ...is to not have it.
> The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative.
Are Stripe co-founders paid by the word, or did that message get through about two dozen lawyers before being posted?
Are Stripe co-founders paid by the word, or did that message get through about two dozen lawyers before being posted?
Dude, you are a machine!
In other words, it’s useful data for them to collect as a whole..
You got caught, spin it as much as you want. This has nothing to do with fraud. We know you got caught because of the speed of your response. This is called damage control, there is also a more scientific name for it called plausible deniability.
I am disgusted with this form of surveillance. I will make sure that I won`t use Stripe in the future and force vendors to use something else.
I am disgusted with this form of surveillance. I will make sure that I won`t use Stripe in the future and force vendors to use something else.
I used to work for a company that transferred a huge amount of money from tenants to landlords. Fraud is a really big deal in that domain, and we were really excited to update our credit card entry forms to use the newer Stripe Elements forms that include this user behavior tracking, to feed into Stripe radar and in turn use Radar’s api to feed the fraud likelihood data in to our own fraud detection platform. This agent behavior tracking is proudly highlighted in Stripe’s documentation as the feature that it is - they’re not being sneaky about this in any way and this feature is incredibly useful to help companies stop fraudsters from doing serious financial harm. In other words, this is not news. If you could somehow prove that Stripe is selling this data, THAT would be a huge story. But as far as we know their explicit claims that they do not is true. Thanks for your awesome anti-fraud features, Stripe - they helped us help people to pay and accept rent safely.
Honest question, what exactly do people mean by fraud? How could someone exploit a payment page?
Also, how would fraud detection work in Europe, where there is the GDPR?
The GDPR doesn't say "You can't do anything", the tldr of it rather is "the user must be informed and/or you must have their opt-in, then it's allowed"
As a Stripe customer, I have to say it is pretty easy to deduce this from their documentation. They recommend loading Stripe.js on every page of your website rather than just the payment form. The given reason is to detect fraud. [1]
> To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.
There are also indications on the product page for Stripe Radar and other places where it is obvious they are doing device fingerprinting.
I can accept Stripe's explanation given the nature of their product and the effectiveness of Stripe Radar. That said, I think they need to make some changes. First of all, they should lay it out clearly that the tracking is high-resolution and includes mouse movement. Second, the tracking should be disabled by default and more closely tied to the usage of Radar. Most businesses don't need Radar until they reach a certain scale. Stripe could encourage the use of Radar when the account transaction volume reaches a certain size and use that opportunity to explain the benefits of enabling the tracking system. It should be optional, even then, though.
1: https://stripe.com/docs/js
> To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.
There are also indications on the product page for Stripe Radar and other places where it is obvious they are doing device fingerprinting.
I can accept Stripe's explanation given the nature of their product and the effectiveness of Stripe Radar. That said, I think they need to make some changes. First of all, they should lay it out clearly that the tracking is high-resolution and includes mouse movement. Second, the tracking should be disabled by default and more closely tied to the usage of Radar. Most businesses don't need Radar until they reach a certain scale. Stripe could encourage the use of Radar when the account transaction volume reaches a certain size and use that opportunity to explain the benefits of enabling the tracking system. It should be optional, even then, though.
1: https://stripe.com/docs/js
I recently worked on a fraud detection POC with a few vendors in this space and it is common for them to require adding a js snippet to capture info like this. This isn't out of the ordinary behavior.
But this IS wrong!! What if my browser doesn't support javascript? It won't allow me to purchase anything! Why there HAS to be javascript to prevent fraud? That is simply an abuse of programmable functionality which was not made for such purposes. Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?!
> What if my browser doesn't support javascript? It won't allow me to purchase anything!
Unless you are Alex Jones, it is probably not worth it to redesign your website to accommodate doomsday preppers. I just disabled JS and you can't even sign in to Amazon or eBay without it. Most websites are now heavily built on JS frameworks, so most projects I have worked on would not be meaningfully functional without it.
> Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?!
No... The reversal doesn't prevent someone from buying something and taking the item. Sure you can reverse the transaction, but then the merchant takes the hit.
Credit cards are safe for the consumer because transactions can be reversed and tracked. They are not safe for the merchant.
Unless you are Alex Jones, it is probably not worth it to redesign your website to accommodate doomsday preppers. I just disabled JS and you can't even sign in to Amazon or eBay without it. Most websites are now heavily built on JS frameworks, so most projects I have worked on would not be meaningfully functional without it.
> Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?!
No... The reversal doesn't prevent someone from buying something and taking the item. Sure you can reverse the transaction, but then the merchant takes the hit.
Credit cards are safe for the consumer because transactions can be reversed and tracked. They are not safe for the merchant.
There's a difference too between allowing self-hosted JS and 3rd party JS. As a no-script user, if a site does not work with JS blocked, I will allow self-hosted JS while still blocking 3rd party. If it still doesn't work, then I consider if the site is something I'm really interested in or not. If not, tab closes. If I am, then I'll look to see if there's 3rd party stuff I trust.
In your example, allowing Amazon's JS allows the site to work at least as far as AWS Console behaves. I don't really use eBay, so I can't speak to what JS is required.
In your example, allowing Amazon's JS allows the site to work at least as far as AWS Console behaves. I don't really use eBay, so I can't speak to what JS is required.
I think most businesses would be more than happy to lose the tiny percentage of customers who use NoScript in exchange for better fraud detection.
> Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?!
Whether or not the money is actually safe or not doesn't really matter when the card networks routinely assess penalties that affect the business. Running cards that have transactions that are later disputed, or for having too many disputed transactions in a certain period of time gets you penalized. The card networks do not make consumer protection programs free, and so fraud prevention happens at every layer. It is as much a battle between a vendor and the card network as it is a battle between a vendor and fraudsters.
Whether or not the money is actually safe or not doesn't really matter when the card networks routinely assess penalties that affect the business. Running cards that have transactions that are later disputed, or for having too many disputed transactions in a certain period of time gets you penalized. The card networks do not make consumer protection programs free, and so fraud prevention happens at every layer. It is as much a battle between a vendor and the card network as it is a battle between a vendor and fraudsters.
> What if my browser doesn't support javascript?
You are SOL. If enough people are SOL and care, then maybe things will change. If not, then you’ll change. Or you won’t.
You are SOL. If enough people are SOL and care, then maybe things will change. If not, then you’ll change. Or you won’t.
Ublock blocks this from happening and only allows stripe.js when the payment goes through and i've had 0 problems, even with 3d secure.
There's two ethical questions here:
1) How much data should a payment services provider be allowed to capture for fraud-detection purposes?
2) What should middleware be allowed to do without the end developer's consent?
The first one I'm not gonna answer because I'm pretty unhappy with the state of non-cash payments in general and this would turn into a rant.
For 2) I think the answer is anything that leaves the process boundaries (or frame in the case of the web) should be explicitly requested by the developer and if it's a long-running task (like mouse movement tracking on a web page) the developer should be able to abort it at any time. If it's associated with any kind of storage that clearly belongs to the developer's app the developer should be able to clear that storage at any time.
1) How much data should a payment services provider be allowed to capture for fraud-detection purposes?
2) What should middleware be allowed to do without the end developer's consent?
The first one I'm not gonna answer because I'm pretty unhappy with the state of non-cash payments in general and this would turn into a rant.
For 2) I think the answer is anything that leaves the process boundaries (or frame in the case of the web) should be explicitly requested by the developer and if it's a long-running task (like mouse movement tracking on a web page) the developer should be able to abort it at any time. If it's associated with any kind of storage that clearly belongs to the developer's app the developer should be able to clear that storage at any time.
[deleted]
This is a good reason to use a technique like cperciva's payment iframe: https://www.paymentiframe.com/
It lets you use stripe.js (thus getting the PCI compliance benefits) without Stripe being able to spy on your visitors.
It lets you use stripe.js (thus getting the PCI compliance benefits) without Stripe being able to spy on your visitors.
That is so ridiculously insecure I'm surprised the author has published it without a massive disclaimer.
Do NOT use an unknown third-party, without PCI qualification, to whom you have no contractual relationship, in between you and your payment provider.
Do NOT use an unknown third-party, without PCI qualification, to whom you have no contractual relationship, in between you and your payment provider.
It says at both the top and bottom of the page not to trust him, and at the bottom it says to implement it yourself if you care about security.
Seems fairly "disclaimed" to me.
Seems fairly "disclaimed" to me.
While I trust him, how can we be sure that paymentiframe.com starts serving an iframe that steals the credit cards in the future?
From the page:
> Why should I trust you?
> [...] If you're worried about both, consider this a proof-of-concept which you should replicate on your own server (using a separate domain name from the rest of your site).
> Why should I trust you?
> [...] If you're worried about both, consider this a proof-of-concept which you should replicate on your own server (using a separate domain name from the rest of your site).
Yeah nobody should be embedding this verbatim to process payments that will fail any pci audit.
This is kinda common. Events with other anti-fraud providers are similar, it's a black box to the outside world that figures out what's normal and what is risky.
It being common practice doesn't make it okay.
To defend against credit card fraud in an automated world, it’s kinda the only thing we got: an automated risk assessment.
That's true, but the data collection doesn't have to be this automated. It's a tradeoff for ease-of-use.
Everyone used to use Paypal, right? That doesn't track anything on your site in the default flow, but it requires sending the user to paypal.com, where they will have to enter even more information. But at least it doesn't collect mouse movements on all users on non-payment pages.
Everyone used to use Paypal, right? That doesn't track anything on your site in the default flow, but it requires sending the user to paypal.com, where they will have to enter even more information. But at least it doesn't collect mouse movements on all users on non-payment pages.
>Stripe is getting free data to train its fraud-detection models and potentially selling that information to advertisers.
That's ridiculous. It's not getting free data to train it's fraud model, it's getting data to _use_ the fraud model!
That's ridiculous. It's not getting free data to train it's fraud model, it's getting data to _use_ the fraud model!
[deleted]
I wasn't very comfortable with integrating either Paypal or Stripe in my app for payments. So I ended up adding it only to the checkout page. Any user who isn't paying never loads their JS and shouldn't have to.
Needs a tiny bit more work, but avoids tons of JS.
You can also use CSP to only allow selected resources to load and e.g. block trackers, but allow bare-bones payment endpoints.
Needs a tiny bit more work, but avoids tons of JS.
You can also use CSP to only allow selected resources to load and e.g. block trackers, but allow bare-bones payment endpoints.
The most effective anti-fraud solution would be a major privacy violation just by the nature of anti-fraud itself. So, since the stripe user is the one being charged for disputes anyway, giving them control over how much more privacy to give up in exchange for better protection is completely obvious. Even if the default is to be extremely pervasive as Stripe’s anti-fraud measures are now, the option to reduce that tracking is a must.
Who do you mean as “the stripe user”? As a customer of a website using Stripe, I have very little concern for fraud, MasterCard and Visa protect me quite well. As a website operator who has somebody use a stolen credit card on my site, MC and Visa protect the owner of the stolen credit card quite well. Stripe is protecting both the website operator and the real owner of the credit card.
The person responsible for paying for the dispute. The user who goes to create an account on stripe.com to allow them to sell stuff on their site.
[deleted]
Having done some anti-fraud work in the past... that is
Not something I would turn off for some over wrought privacy concerns. There is a reason for the GDPR exemptions for this.
What GDPR exemptions are you referring to?
You can opt out of Stripe.js, but then you must accept the burden of being PCI compliant (or instead chose to use a hosted Stripe flow).
This is how other companies gather fraud signals as well. If you've ever clicked "I am not a robot", it also works on signals like mouse movements. Stripe is following industry best practices.
I haven't used reCAPTCHA, but based on my understanding from Google's documentation[0], there are a few differences:
1. reCAPTCHA doesn't send information until you explicitly call their library. Stripe's library immediately begins reporting to data as soon as the script is loaded.
2. reCAPTCHA is explicit in its documentation that it's collecting behavior about your users. Its sole purpose is to track user behavior, so implementers understand that it does this. Stripe's main purpose is to accept payment information, and it is currently not transparent about how it collects user behavior to achieve that. I don't believe that most implementers understand the nature of Stripe's data collection.
[0] https://developers.google.com/recaptcha/docs/v3
1. reCAPTCHA doesn't send information until you explicitly call their library. Stripe's library immediately begins reporting to data as soon as the script is loaded.
2. reCAPTCHA is explicit in its documentation that it's collecting behavior about your users. Its sole purpose is to track user behavior, so implementers understand that it does this. Stripe's main purpose is to accept payment information, and it is currently not transparent about how it collects user behavior to achieve that. I don't believe that most implementers understand the nature of Stripe's data collection.
[0] https://developers.google.com/recaptcha/docs/v3
> Stripe is getting free data to train its fraud-detection models and potentially selling that information to advertisers.
Can the author back up the second claim with any non-speculative information that stripe will actually sell it to advertisers? advertising is not even stripe's business model. Hypothetically any site anywhere can "potentially" use any data they collect to sell to advertisers.
Can the author back up the second claim with any non-speculative information that stripe will actually sell it to advertisers? advertising is not even stripe's business model. Hypothetically any site anywhere can "potentially" use any data they collect to sell to advertisers.
Author here. Happy to answer any questions or hear feedback about this post.
This is a common practice for anti-fraud detection systems. The whole article is sensationalistic. You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.).
Thanks for reading!
> This is a common practice for anti-fraud detection systems... You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.).
I respectfully disagree.
My bank tracks my movement on their own website. They don't track movement on other businesses' websites.
I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page. The fact that JS library runs on every page and sends data back to Stripe, even before the app calls the API, is unexpected. I believe that Stripe should, at the very least, make this more obvious to integrators and, ideally, give site owners the ability to limit what data Stripe collects.
> This is a common practice for anti-fraud detection systems... You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.).
I respectfully disagree.
My bank tracks my movement on their own website. They don't track movement on other businesses' websites.
I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page. The fact that JS library runs on every page and sends data back to Stripe, even before the app calls the API, is unexpected. I believe that Stripe should, at the very least, make this more obvious to integrators and, ideally, give site owners the ability to limit what data Stripe collects.
>I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page. The fact that JS library runs on every page and sends data back to Stripe, even before the app calls the API, is unexpected.
It's not unexpected when they tell you to include it on every page:
As was in their docs ages ago and still now: https://stripe.com/docs/js
>Including Stripe.js >Include the Stripe.js script on each page of your site—it should always be loaded directly from https://js.stripe.com, rather than included in a bundle or hosted yourself.
>To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.
... they are asking you to enable them to track your user's interaction with your entire website.
It's not unexpected when they tell you to include it on every page:
As was in their docs ages ago and still now: https://stripe.com/docs/js
>Including Stripe.js >Include the Stripe.js script on each page of your site—it should always be loaded directly from https://js.stripe.com, rather than included in a bundle or hosted yourself.
>To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.
... they are asking you to enable them to track your user's interaction with your entire website.
> I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page.
What makes you believe that exactly?
If you include stripe.js on your About page, all bets are off for that page. You can believe all you want here, but you have explicitly included some 3rd js code, so feigning surprise that it gets executed is shallow.
What makes you believe that exactly?
If you include stripe.js on your About page, all bets are off for that page. You can believe all you want here, but you have explicitly included some 3rd js code, so feigning surprise that it gets executed is shallow.
>> I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page.
> What makes you believe that exactly?
I've read all the StackOverflow and Github issue posts I can find related to this issue.[0,1,2,3,4] The overall sentiment from developers is that they're surprised and don't want Stripe to send this information. That said, there's obviously a selection bias because the ones who consider it expected behavior don't post.
> If you include stripe.js on your About page, all bets are off for that page. You can believe all you want here, but you have explicitly included some 3rd js code, so feigning surprise that it gets executed is shallow.
Sure, I'm ultimately responsibility for what runs on my site. I believe Stripe is also responsible for clearly disclosing the behavior of their library, and I feel like open critique is an appropriate way to encourage that.
[0] https://github.com/stripe/react-stripe-elements/issues/257
[1] https://github.com/stripe/react-stripe-elements/issues/99
[2] https://stackoverflow.com/questions/45718026/stripe-js-makin...
[3] https://stackoverflow.com/questions/56481458/why-does-stripe...
[4] https://stackoverflow.com/questions/55904278/reduce-network-...
> What makes you believe that exactly?
I've read all the StackOverflow and Github issue posts I can find related to this issue.[0,1,2,3,4] The overall sentiment from developers is that they're surprised and don't want Stripe to send this information. That said, there's obviously a selection bias because the ones who consider it expected behavior don't post.
> If you include stripe.js on your About page, all bets are off for that page. You can believe all you want here, but you have explicitly included some 3rd js code, so feigning surprise that it gets executed is shallow.
Sure, I'm ultimately responsibility for what runs on my site. I believe Stripe is also responsible for clearly disclosing the behavior of their library, and I feel like open critique is an appropriate way to encourage that.
[0] https://github.com/stripe/react-stripe-elements/issues/257
[1] https://github.com/stripe/react-stripe-elements/issues/99
[2] https://stackoverflow.com/questions/45718026/stripe-js-makin...
[3] https://stackoverflow.com/questions/56481458/why-does-stripe...
[4] https://stackoverflow.com/questions/55904278/reduce-network-...
You may not be aware of how many banks/airlines/ticket websites have outsourced their fraud fighting to solutions like Shape Security, or Sift (Science). Web-wide tracking via cookies is a reasonable and widespread technique for fighting fraud.
Given your background I'd imagine you'd be aware of this.
Given your background I'd imagine you'd be aware of this.
> You may not be aware of how many banks/airlines/ticket websites have outsourced their fraud fighting to solutions like Shape Security, or Sift (Science). Web-wide tracking via cookies is a reasonable and widespread technique for fighting fraud.
I view that as a different situation. If a bank/airline/ticketer outsources fraud to a third party, there's presumably an informed exchange of "we'll let you run JS on every page on our website and suck up whatever information you want if you help us detect fraud."
In the case of Stripe, I don't believe they're clear with client applications that they're collecting information from every page of an app. I think most developers integrate with Stripe so they can accept payment on one or two pages and probably don't expect Stripe to be collecting the level of data they're reporting back to Stripe servers.
I view that as a different situation. If a bank/airline/ticketer outsources fraud to a third party, there's presumably an informed exchange of "we'll let you run JS on every page on our website and suck up whatever information you want if you help us detect fraud."
In the case of Stripe, I don't believe they're clear with client applications that they're collecting information from every page of an app. I think most developers integrate with Stripe so they can accept payment on one or two pages and probably don't expect Stripe to be collecting the level of data they're reporting back to Stripe servers.
This “level of data” doesn’t strike me as alarming. It’s views and mouse locations. Really no different than any simple analytics solution.
Hypothetically: I tell a dev to drop a piece of JS on every page that seems related to payments. That dev probably isn’t doing their job super well if they don’t ask me why or wonder why and find out.
I think you imagine HN readers to be dumb. Nothing here is surprising.
I know it’s covid era and we felt good as a community wagging our fingers at Zoom’s naughty FB tracking inclusion. Legitimate concerns there given the advertising business model, and no good reason for zoom to be doing it. This is fundamentally different: the data is for a good purpose with a narrow scope to a good company with a user-positive value creation model.
I believe your princess is in another castle.
Hypothetically: I tell a dev to drop a piece of JS on every page that seems related to payments. That dev probably isn’t doing their job super well if they don’t ask me why or wonder why and find out.
I think you imagine HN readers to be dumb. Nothing here is surprising.
I know it’s covid era and we felt good as a community wagging our fingers at Zoom’s naughty FB tracking inclusion. Legitimate concerns there given the advertising business model, and no good reason for zoom to be doing it. This is fundamentally different: the data is for a good purpose with a narrow scope to a good company with a user-positive value creation model.
I believe your princess is in another castle.
You might have some reasonable arguments, but your condescending tone is completely undermining the conversation.
I honestly cannot fault him. While online fraud prevention is a massive industry that touches almost every major website we use, you don't exactly have people giving talks about how serious the problem is or how advanced the detection tooling is because the nature of the industry requires you to keep your methods secret.
Heck, I have a friend who's working on a non-finance web app with <20k MRR, and even at that size he's starting to encounter fraud problems that require tooling to mitigate.
If your app stores any data that may be sellable on the dark web, you are a target.
Heck, I have a friend who's working on a non-finance web app with <20k MRR, and even at that size he's starting to encounter fraud problems that require tooling to mitigate.
If your app stores any data that may be sellable on the dark web, you are a target.
> reasonable and widespread
One of those can be factual and the other is clearly subjective.
One of those can be factual and the other is clearly subjective.
title is a little sensationalist, i find that a little hard to forgive :) it is well understood any anti fraud system records movement. how does your analysis fare on Google's reCAPTCHA v3?
or rather the actual issue, the x00,000's of sites that actually record movement for product research and, yes, marketing? sensationalizing this issue on stripe, which is a probable good actor, doesn't help the sites and web users deal with the real bad actors.
but its a well written article with solid recommendations so kudos for that.
or rather the actual issue, the x00,000's of sites that actually record movement for product research and, yes, marketing? sensationalizing this issue on stripe, which is a probable good actor, doesn't help the sites and web users deal with the real bad actors.
but its a well written article with solid recommendations so kudos for that.
> it is well understood any anti fraud system records movement.
I don't think that's true of every anti-fraud system. I've integrated PayPal checkouts by pasting some HTML on a single page and that works fine. I'm sure it works better if you can record movement, but that doesn't necessarily mean I'm okay with handing over so much data to achieve those gains.
> how does your analysis fare on Google's reCAPTCHA v3?
I haven't looked too carefully at it, but my understanding is that reCAPTCHA 3 works if you place it on a single page. If reCAPTCHA is directing users to place it on every page of their app and not making it clear that Google's tracking it, I'd have a problem with that as well. From a cursory look at Google's documentation, they don't seem to be doing that.
I don't think that's true of every anti-fraud system. I've integrated PayPal checkouts by pasting some HTML on a single page and that works fine. I'm sure it works better if you can record movement, but that doesn't necessarily mean I'm okay with handing over so much data to achieve those gains.
> how does your analysis fare on Google's reCAPTCHA v3?
I haven't looked too carefully at it, but my understanding is that reCAPTCHA 3 works if you place it on a single page. If reCAPTCHA is directing users to place it on every page of their app and not making it clear that Google's tracking it, I'd have a problem with that as well. From a cursory look at Google's documentation, they don't seem to be doing that.
No, it’s not well understood. Perhaps you, and people in your direct field understand this, but does an average web developer who is reading Stripe’s documentation? Does a consumer?
Silent, given the lack of documentation or notification, is 100% appropriate here.
Silent, given the lack of documentation or notification, is 100% appropriate here.
I mean, the docs literally spell this out, so I'm not sure how much you or the author of the article wants their hand held:
> To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.
https://stripe.com/docs/js
> To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.
https://stripe.com/docs/js
[deleted]
It's not super clear to me what harms you've identified here. Tracking mouse movements is a very common way to separate human users from automated fraud, and tracking page views is a relatively common way of identifying normal navigation of a website (homepage-->click on link to search-->click on search results-->click on product reviews-->click on buy) vs fraud navigation (open product page directly-->click on buy). This kind of anti-fraud has existed since the Silvertail days.
Additionally, the Stripe cookie can reasonably be read as a way to reduce false positives: if you've purchased from a dozen stripe merchants with no chargebacks and they see you in the same browser with the same payment method, you're probably good to go. The user benefits from having fewer charges declined, and from their goods being less expensive (due to lower shrink for their merchant).
One great thing about Stripe is their extraordinary transparency. The fact that the stripe.js payload is sent in ~cleartext is either a sign that their eng team was unwilling to roll their own encryption, didn't feel it was necessary, or consciously chose to make it visible so curious users can understand what's going on. I suspect their fraud solution doesn't rely on these being unobserved by bad guys. I am surprised that it's not necessary to include some tamper-evident field though.
For what it's worth, a post to login to aa.com includes this spectacularly obscured blob of who knows what. Would be interesting to know how much of my personal data got hoovered up here, but you won't get clickbait upvotes on HN by going after someone _less_ reputable than Stripe.
Additionally, the Stripe cookie can reasonably be read as a way to reduce false positives: if you've purchased from a dozen stripe merchants with no chargebacks and they see you in the same browser with the same payment method, you're probably good to go. The user benefits from having fewer charges declined, and from their goods being less expensive (due to lower shrink for their merchant).
One great thing about Stripe is their extraordinary transparency. The fact that the stripe.js payload is sent in ~cleartext is either a sign that their eng team was unwilling to roll their own encryption, didn't feel it was necessary, or consciously chose to make it visible so curious users can understand what's going on. I suspect their fraud solution doesn't rely on these being unobserved by bad guys. I am surprised that it's not necessary to include some tamper-evident field though.
For what it's worth, a post to login to aa.com includes this spectacularly obscured blob of who knows what. Would be interesting to know how much of my personal data got hoovered up here, but you won't get clickbait upvotes on HN by going after someone _less_ reputable than Stripe.
X-6LdxA4pr-a: 6eta-yIqpITGjyIefMI7BLhyY6Km5cM_Y7j0t6yyo4MA4ih7jsy8=4-9MsInBvm36VNvPpZQ1AT9BLMCIihQx7-bZONZNCkleLk76Wh9HOkBR5wuPvy1BcKvj8Imtik9BnZQRATho7TXrAgGrGZwcyZZr2TXtqYN5Dk01eoWRC3ZKxLzfpC_iXMvNselNmhvj6Kntco7rXkLMm-8t4AFYmnR5XgZoahho9_F6s-bMLT8NmQuNoYABsM7YnFU1e67YsxaPimKHcMF5Hk8o3Fuf_7NoAh6jCcf5oFxrXClB3zWBX9wBvhXaXt1fiNajnZvNnNSjy=ajQ_wNcFxiphY=Ak6PXQe_4ImRrNnRo5GgZ-pRczZkALsR_jwjX3NaXyCoAbFR=9WNsE3toTKo9rZrX_GjskvGMIPrZNNYsr6PXyhYQ_9t_ZmaMIGo2Im_s8PBZkul9k9RZAtPsMutcK1GoSWtrFCtHbbj8-S=HyhMs54R8Fl=2-WYSY9wcoZHLTak9_zfoku_5h2BFhzVgGhOgy9j4F9PVh6YhFFwobuh6tC6cM0Gs22Rg-P5Gt6oHBF=Ana6OQ1BQ8bf7y0rX2x1ACqg46Gbl6V5pK8rX=2=96Hrs6_TGQZBl-lrVhujp20=JGZPXTbYmrZBXMmGXI2NN5NPXY5BNmStph9M4PK4e-zqX_CGrh6iMMl32tCYL-2BcgYr4KFjmLWbZMK6OR1RqQ76mh1Bzt25X-9B_yaicyvbAMur9Y4c6B7rGqZBXMvcyIv6AqYbXjGOOhhr=tmtpC7RMIh=3FvRgk7repW5XIMhzoPBXEYBxMh54MxioTGMs3K-ZqPB4I6qkmWoAkXrUAmqQM2rcoFPsMVhsuZjyIFYskzRckQ6WhmSszZNaFP6QFCBXIk397PT4yF=4Izfuknf5NGMghGRAkz-gQl1xy8B4tC=QrZBsPwrWKhrLg3oA-lV7YZBnFqB36Z-pNG1qq7Rc_vBXkFtzFlBpN4YyosHNw9tQVWEsyU=3t9oJQf54GPjiy91x7ZtM==_xnZjyYatAhKiVKD-QgJbQIvPx8FHQ3FjQh86HmFr2IFSnmPRZT964Y7r2=PaLCvfoMs1XF_tph0-5Fn6c2Fwsy9HsMzBvNGo3mZPmRm5A6aNQ2XjnYN-X5KP7AWBnF1pAyCjnZNBA-wBsMlSQBFRX54tsF28zhvRDSWtfYNPeZ2j--2rQyaBsyeNeTnn02L6Cjaq437Ph-vM68sPWCWr4MuPXK8Rg-aYLkl_4ZvtiYZ6AOg6ahoNNIuBLMyjMTxtMCagHYNtVhCVQIojjkwjmlMqzya-HjuT4QLpzRwtphLxQjFPNkoBzTbrPbPvl-lSVhlRlhC=Akofr77Bs0C57N_r422gAqhON3PrXGsico7=AhlcL-6PLk26x3WPy8htgIvt5mF57Q_5esF6imK5gQZBXM8_vh1rXqLrcyCtOkPt83KfgxGo7kujOhkNLnWPNNwcmYZo2rYPZbh1xILrcx7HsM0N6katLTm6c9atX29fMrAYOLuxut8RGUWtikC9cy8o=hLPqta6vyahVICSo-eBQMkMNyarWhQtMChig-SKOh9p4MPHmn7YsCuTAgZ9VEZtM54YmkYBLkuqikzjQoZ-syFnHTmbXYKM3FKUcy7Hskm9vhGSoMbsekHYLocm7QZ1zN7MLZTgZtLR8ZNaQ0Ctc9ZBEuSrAO0NyMaKWFyPph8_4MvBzy9jNwwjLbSRokmYObPNLm7gEk_WZThhNAFjLTuqvsDrHN61eTFjyr1jLklG8-vb0-aybYPYOt5L465GXt2acM0jNNQOy=7=97V=skvtX-yHLTG6vhF59oP=s2viMIlQncWNpK9tXCCjsICr2r=YQM0ffkQ5gT9iiSWBsxGRiQhBQAXfrY=TonV66FhNs-9-ckC6sMCBN53suhqH62s6xIghsMWj7R_6cCRteTvn45aBcI9=43WT4F8RxtlbekQYs6ZRenFjskeNsyzYYNNjLMMPcIla-PZHmb7g9-0R9g_iQ-vrC8PBWhvB=UPBMrQr4klRrMCR5rRKnFCGsy91zFvOyhaPXqVo9oTrHLVpoMF6OY766kPtC=_tMhWHsn7BqyuB4IyPik9tMtpwcy8GXcW6vR_jL6AGCIuYVhajLhCbvk9imglHVVJjsM0547V5sbW=6G7PhMGBG6Zfc-lBO_gRrklRMIFRZTmB3FvRckw-LN7qoXWtqkCBVNZrx-gcV=QGo59PgK_T9BZ6x67NsxZj6_yoJYhfcM0HsKCtXgZ-omzYNN1PLkuB9_br4MGg96ZHm77BVZ_5qL76eMaioyFYmToiCIlo9y9RfkFrCC4MqNIH86ZPX-8GeZ6TcIVrXbNfjYvtikGhQMCo9KGHVPNGvQZRgjhHSbL-LyVjNjur4nstoYVjsML-mga69gaiMMa=sjWfMk7-LTGtrPw5ETYjo6ZaXokiiN7BAFa=aHWjOmZic-JhX=GR2Izhlt4jnGGPL-05J2FtVha-4-FRAm7rehFRq-ABS2PNsqWPeQgcAkb5ojo59MGccM1ruVN-x_hsLk7ez6mVeTxNcLLBQK4=7YVMsGoHszFPsGhjyIPTrmPc8FUBzQ2Ys2hGehxroonf7jCfXFCYssUYsgNRfkltimVo4=7c5gBtoha-WmZNc2zTOhuQsMCrvb-6qb7OIzLbFNZtQI9TcTltZU7eg3B-mkh6sM554MChNpWtsR9LjFCjWh1o4MMYyIyjpVWtsIRPWxQ1lFC=aNaMJh8YmywVeo7YQ7Po2ZlRAkFm4MuhmzatgM6SsCq5X-lYNh9HObWBsoFrXENNXyV6lhh6ATu6sWWR3WW6g=6oJhwqzY1r6CwtXoZHQCm58-aGyIoo9-7QLkCRfkCMs=Z68-2PlnVtpN76mkur96ZScC0fc22tMIC37b7BsoVtsQv5Lk2tqgl_Qg5jMICoGhk5GhqqZqgrxMwtXy2pNgZRpkojQGtYLbSB4C8PskCBA5vtMN7rehlBxLJtxMmo9eWB3FKo=YJNL-CreTIjNTCR9I9NSuYGsM9B9hz5GT9RqICBlz7jOhFVlB0-cyG5A-uTiyxI5J1PxeHMsPQnDmDts=nq6jut52MrCgV=7M2gxmyYsgYR51Qg7M6-WNaBs0C6LkaRX5ZTGzPBGmZ-cp5=4G_M49PjxG_=ZTCp6m7tihXfqkXtfOkgXQNBVhaR3z7rc7Wg9j8=s2_T0twtiYkhs-UH--a6sxOfOmVjQMCBcyWTMbktrb3GCkCRphlBzF9RcYQML-9tphyBWhFOXT9PWCC=aK_YsMpELkCjg3PRxMzNAbnOmTwfc3Yr4PZNXCgG8-m6x0_q-kpBsYVHLTvTM=NHnncLsLVqmkGtA-XbWCFjpmhYnmVToTg-LbFR9yltsMFBXF9rA5eqsgPR5LZOpZAtgNUSQ9=-g_GYLk0g967-=ZlaVh0icM2rs_FhG5N1s2-6s0LB43715MyNVxGBc9ZTGFXR7hkr7F9fcIloGh9YnF6Rih960LWYNjp_XIFP6FPjq=_tctL=4MKNOyetekCM3=PBeb7BcKgoah1jMIvjyFFBAT66gklrfk8PXI8o4G4rWEFM6gG5o5AyAZZNsKwYLbWfoYZB991BHymB4MqBLT8oJkOt4yaReFCtoTzMgnZNLNSYLTetAMgtcC-mvhbBsK66X9ZNOy0BS0w6Ow4NLqFtiwK5zNhbaz7o4_aaqj1jLykBeMVRgyxr4FRy7CwB4RhBahgjmklafkkrzbVpLFoM6TqgAMwyXeNBoYStVNZtcTh5XMlr=bPPLTl=4=hRc2xrsA-jX2Wfn-ltOVLrATCo2jijVh9BokuYmMaa4turX6iB6B5o3nPBcyhjsKbAphuYsFuNeqZrLMzTcM9BXTvR4LPTahCjLThfMh8t8CXMsFh=-wqta87BC3Ztcyv=45bSikeBihag92vB8FwfctK54IwPLb7BVBgjsyPYLklSo-x1L5vGBEKxyTw6LylPcIy=HLWj6UDNNhAjyI8b4e71XXsVqyFRXMp=_kaPH_0tSNL6QgEo4MzM4-vRrkKPrFho4kCPQj9NLkacntlBrNRo4wzrA5_6cyaByy9jy-6pAtCqgPwPNUbiLqaB9xDML5Y4sTC-cPvBsPZjsM9PxzZ=4gAY-BPPxM8jLxARGyR=9n7T4xZrXj8-4eKB977bHhopct9PoTaqoTCPX5IBLThNjjxR4_lhs7N> The fact that the stripe.js payload is sent in ~cleartext is either a sign that their eng team was unwilling to roll their own encryption, didn't feel it was necessary
It is indeed not necessary when you can just use HTTPS.
It is indeed not necessary when you can just use HTTPS.
Have you tried sequestering the payment logistics to a separate domain or subdomain? If you had a pay._____.com that processed payments using Stripe.js, and that redirected back to app._____.com (which would not be using stripe.js), would tracking continue into your app pages?
EDIT: didn't expect this to be so controversial (6 downvotes!)
EDIT: didn't expect this to be so controversial (6 downvotes!)
That was one of the solutions I considered. I believe that would successfully limit Stripe's tracking, but it's just logistically complicated to stand up a whole second app just to serve one page and manage state between the payment app and my main app.
Could you simply use an iframe with a sandbox attribute? Idea being you dynamically create an iframe, fill it with content (styles, postmessage scripts, what have you), then dynamically set a semi-restrictive sandbox before loading Stripe's library. When you're done (i.e. have a payment token in the parent) just remove the iframe. This way everything Stripe related is sandboxed and the script is unloaded as soon as you're finished with it.
Good chance I'm missing something, or there's some kind of protections in place around this.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
Good chance I'm missing something, or there's some kind of protections in place around this.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
That was another solution I considered. I think that would work, but it seemed expensive to implement. I believe it would still require me to host a separate copy of my app or a standalone app that handles just payments. Stripe also creates its own child iframe for displaying payment UI, so at that point, my app would look like:
Main app
My sandboxed iframe
Stripe's iframe
My problem is primarily that I'm working with SPAs where a refresh really lowers the game.
I put together a proof-of-concept using a 'same-domain frame', no secondary domains or apps. The idea is separation over security, so you can unload without any side hustle. Tho without a second domain you're relying on Stripe being as trustworthy as they are, and not looking to actively undermine your sandboxing attempts [which I think is ok - we embedded their library in the first place].
https://codepen.io/theprojectsomething/full/ExVNEoZ
I put together a proof-of-concept using a 'same-domain frame', no secondary domains or apps. The idea is separation over security, so you can unload without any side hustle. Tho without a second domain you're relying on Stripe being as trustworthy as they are, and not looking to actively undermine your sandboxing attempts [which I think is ok - we embedded their library in the first place].
https://codepen.io/theprojectsomething/full/ExVNEoZ
I use stripe.js in a number of my projects but I've never trusted it. Looks like my fears were justified.
Instead of loading it on startup, I always load the library as the last step before the checkout flow is initiated. Here is a working example of how to do this for anyone who's curious.
https://jsfiddle.net/167ajcbw/
Instead of loading it on startup, I always load the library as the last step before the checkout flow is initiated. Here is a working example of how to do this for anyone who's curious.
https://jsfiddle.net/167ajcbw/
no, they weren't.
did you read pc's comment (top currently)?
did you read pc's comment (top currently)?
"It's okay because 'fraud prevention' " isn't a good enough reason to horde my user's data without their consent.
Furthermore, a heartfelt promise from a payment provider to never sell my data means about diddly squat to me.
Furthermore, a heartfelt promise from a payment provider to never sell my data means about diddly squat to me.
How is this any different than loss prevention watching you walk around in a store on cctv and taking note in a notebook if you look suspicious?
Do people routinely avoid all B&M retail stores?
Do people routinely avoid all B&M retail stores?
If you hire a loss prevention officer to protect your store, you're directing them in how they collect information about your customers and how they handle that data.
The closer equivalent would be if I purchased Square point of sale tablets to accept credit card payments in my store, and then Square sent their own loss prevention officers to my store to monitor my customers without telling me about it and kept the data for their own purposes.
The closer equivalent would be if I purchased Square point of sale tablets to accept credit card payments in my store, and then Square sent their own loss prevention officers to my store to monitor my customers without telling me about it and kept the data for their own purposes.
What if you hire a 3rd party security contractor (also common)? i.e. rent-a-cop
In this case Stripe does tell store owners what they're doing if they would have done due diligence and examined the service more.
Either way, not sure why everyone's coming after Stripe instead of the stores that decided to use it
In this case Stripe does tell store owners what they're doing if they would have done due diligence and examined the service more.
Either way, not sure why everyone's coming after Stripe instead of the stores that decided to use it
The HN crowd likes to freak out whenever data is being collected...
This is not the only thing that bothers me about Stripe.
For example, if you run a Stripe Connect platform, and you set up webhooks to receive some events asynchronously, Stripe will send you all events of the types you select about the accounts connected to your platform, no matter if the events are related to your platform or not.
There may be applications which might need to receive all the activity, but in a simple case of a marketplace which allows merchants to sell stuff and collect a small fee, this is a disturbing amount of information. If I were a bad actor, I could silently collect the information about my merchants' activity on the marketplaces of my competitors.
Moreover, if your platform has enough merchants, you could track their buyers. Stripe will readily hand over all this information to you. In a charge.succeeded webhook alone, you get quite enough information to fingerprint a customer, and if you use some deduction, you can identify them, too.
This sounds like putting a Ring of Power into the Gollum's hand all of a sudden.
I'm wondering if the marketplaces should hang a big warning, for privacy reasons, that "this site uses Stripe for payments. Any payment information might be shared with an unknown number of third parties, and there's diddly we can do about this."
For example, if you run a Stripe Connect platform, and you set up webhooks to receive some events asynchronously, Stripe will send you all events of the types you select about the accounts connected to your platform, no matter if the events are related to your platform or not.
There may be applications which might need to receive all the activity, but in a simple case of a marketplace which allows merchants to sell stuff and collect a small fee, this is a disturbing amount of information. If I were a bad actor, I could silently collect the information about my merchants' activity on the marketplaces of my competitors.
Moreover, if your platform has enough merchants, you could track their buyers. Stripe will readily hand over all this information to you. In a charge.succeeded webhook alone, you get quite enough information to fingerprint a customer, and if you use some deduction, you can identify them, too.
This sounds like putting a Ring of Power into the Gollum's hand all of a sudden.
I'm wondering if the marketplaces should hang a big warning, for privacy reasons, that "this site uses Stripe for payments. Any payment information might be shared with an unknown number of third parties, and there's diddly we can do about this."
Don't single out Stripe, this is how many parts of the world work. Like @ryneandal said, what you're allowed to do with the data is usually covered by legal contracts.
Mastercard and Visa see all the transactions processed for the cards and so does the institution that issued your card (your bank). Unlike Stripe, they do a lot of non-fraud-related analysis on that information.
But putting fintech aside, GCP and AWS have access to everything on their customers' platforms, unless it's E2EE. They could (very illegally, and very stupidly) access all that data. There is no concrete difference between this and what you're talking about.
No matter how much encryption you put on it, your ISP has access to a history of a the IPs you directly connect to. To all the connections you make through them.
It's the nature of a middleman service provider to have access to these things. We can push to improve the status quo (more E2EE, decentralized designs and what not) but a better alternative has to exist before you can cry wolf about those that follow the norm.
Mastercard and Visa see all the transactions processed for the cards and so does the institution that issued your card (your bank). Unlike Stripe, they do a lot of non-fraud-related analysis on that information.
But putting fintech aside, GCP and AWS have access to everything on their customers' platforms, unless it's E2EE. They could (very illegally, and very stupidly) access all that data. There is no concrete difference between this and what you're talking about.
No matter how much encryption you put on it, your ISP has access to a history of a the IPs you directly connect to. To all the connections you make through them.
It's the nature of a middleman service provider to have access to these things. We can push to improve the status quo (more E2EE, decentralized designs and what not) but a better alternative has to exist before you can cry wolf about those that follow the norm.
Almost like a...services agreement (https://stripe.com/legal#section_d)?
Look, I'm just a random Joe who wants to buy a handmade mug on a marketplace with handmade mugs. I don't even know at any point that this is powered by Stripe. When I buy the mug, lots and lots of PII flies, via the webhook, not only to the marketplace through which I bought the mug, but also to that other place to which my particular seller is connected, maybe they sell handmade Bilbos. And that place which is an aggregator of spaces-to-let. You name it. It's not Stripe per se, it's the unknown number of unknown third parties.
And at this point, a wild commenter appears and tells me, the random Joe, that Gotcha!, you should read all that legalese for Stripe! Dammit, should I also fire up the web inspector on each site I visit, just in case they use something I should be privy to the legal terms of?
Listen, bub, at no point I (the buyer) and Stripe even enter a contract. I want to buy a fricking mug and I'd just be happy if that information stayed between me and whoever sold that to me.
And at this point, a wild commenter appears and tells me, the random Joe, that Gotcha!, you should read all that legalese for Stripe! Dammit, should I also fire up the web inspector on each site I visit, just in case they use something I should be privy to the legal terms of?
Listen, bub, at no point I (the buyer) and Stripe even enter a contract. I want to buy a fricking mug and I'd just be happy if that information stayed between me and whoever sold that to me.
Some of you bringing up ethical and moral issues.
But let me raise a totally different issue: what if I am a 100% keyboard person or use a phone with voice commands? Will most my purchases be marked as possibly fraudulent? Will my Amazon packages arrive a week later than anyone elses?
And to the bigger question: will we soon live in a world where AI can discriminate against anyone who is slightly different and everyone are okay with that??
But let me raise a totally different issue: what if I am a 100% keyboard person or use a phone with voice commands? Will most my purchases be marked as possibly fraudulent? Will my Amazon packages arrive a week later than anyone elses?
And to the bigger question: will we soon live in a world where AI can discriminate against anyone who is slightly different and everyone are okay with that??
Probably not, it's just more effort to verify you as legitimate and your baseline behaviour is closer to a robot, meaning when your account gets hijacked, it's more difficult to detect deviance.
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.
What about to companies or people who are not advertisers?
What about to companies or people who are not advertisers?
@pc - how about an answer to this question?
@dang - is there a service or function that allows some kind of notification specifically based on @ mentions?
@dang - is there a service or function that allows some kind of notification specifically based on @ mentions?
So it's being used for anti-fraud, let's say that's fair. But what if you're accidentally classified as bot or fraudulent? The GDPR allows automated individual decision making in general, but there must (legally) be an option to ask a human for a second opinion. How does that work with Stripe?
Relevant text for those who want to know what GDPR says about this: "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL... (So one has to prove that it 'significantly' affects you, but I guess e-commerce is commonplace enough that being banned from a common platform could be argued to significantly impact you. But IANAJudge so this is up for interpretation by a real judge.)
Relevant text for those who want to know what GDPR says about this: "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL... (So one has to prove that it 'significantly' affects you, but I guess e-commerce is commonplace enough that being banned from a common platform could be argued to significantly impact you. But IANAJudge so this is up for interpretation by a real judge.)
For those that are working with SPAs or similar and are not overly affected by fraud, I've put together a simple example showing how to sandbox Stripe.js code and unload it when you're done. No secondary domains, no reverse engineering of the Stripe.js library. It also maintains a reasonable level of trust in Stripe, who deserve it.
https://codepen.io/theprojectsomething/full/ExVNEoZ
https://codepen.io/theprojectsomething/full/ExVNEoZ
The thing I don't get about the outrage in this thread is what the actual harm is. Is there any plausible way you could be harmed by someone tracking your mouse movements?
[deleted]
Slightly off topic, but does anyone else find customer support emails that start like this to be particularly ingratiating?
> Hi Michael,
> Thanks for getting in touch. Faith here from Stripe support.
> Jumping right in, ...
Are those first sentences really necessary? It’s not like the customer expected to have a conversation and you need to apologize for moving directly to the point of the email.
At some point I was taught that it’s best to put things like “hope you’re well” or “thanks for getting in touch” at the end of the email, because putting them at the beginning just makes whatever comes after seem extra disingenuous. Eg “Hope you’re well! Just wondering when you’re going to send the signed contract over.” Doesn’t really sound like you care about my well being, does it?Always better to get straight to the point.
Anyway, pedantic rant over. Now back to the regularly scheduled pedantic rants.
> Hi Michael,
> Thanks for getting in touch. Faith here from Stripe support.
> Jumping right in, ...
Are those first sentences really necessary? It’s not like the customer expected to have a conversation and you need to apologize for moving directly to the point of the email.
At some point I was taught that it’s best to put things like “hope you’re well” or “thanks for getting in touch” at the end of the email, because putting them at the beginning just makes whatever comes after seem extra disingenuous. Eg “Hope you’re well! Just wondering when you’re going to send the signed contract over.” Doesn’t really sound like you care about my well being, does it?Always better to get straight to the point.
Anyway, pedantic rant over. Now back to the regularly scheduled pedantic rants.
In a previous role all front line support were given instructions to add similar information at the start of conversations. Seemed silly until the data showed that customer satisfaction with the support team went up by something like 4% and agent retention went up closer to 10%. If there is an ongoing relationship, I can definitely see the pleasantries seeming fake but in a one time interaction I don't mind them.
Very interesting, especially the agent retention. I suppose feeling like less of a robot boosts morale.
As for SPAs it makes a lot of sense to inject the script at the exact page where it’s needed and then eject it after the payment is processed. At least that’s how I deal with these kinds of single-purpose-ja-files.
> is in the best interests of the user
This is why you hire people with empathy who can write to do support. Actually, just hire them for every position.
This is why you hire people with empathy who can write to do support. Actually, just hire them for every position.
I point at what I read, what I look at; this is just eye tracking. Is there a browser extension that can block this nonsense?
this is really creepy. All these data being collected, analyzed and sold to third parties ...
Author uses python one-liner to pretty-print JSON struture. There is marvelous MIT-licensed tool "jq" just for that and ton more: https://github.com/stedolan/jq
Time to add Stripe to uBlock Origin...
If you believe "this data is not going to be sold to anyone" then boy do I have a bridge to sell you. In my 20 years experience I've never heard anyone say "no, we can't sell this because that would be unethical!".
"Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn?
Also:
`The Stripe library generates a new request like this every time a user views a new page in my app.`
In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
Also:
`The Stripe library generates a new request like this every time a user views a new page in my app.`
In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
Thanks for reading!
> "Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn?
I struggled a lot with the title, as I didn't want to project intention onto Stripe.
That said, the behavior is pretty subtle. They don't disclose it in the npm package or the JS documentation. Other API calls initiated by your app show up in your Stripe dashboard, but these ones don't appear anywhere. You can only discover them by inspecting HTTP traffic.
> In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
I'm having trouble understanding this. Assuming you're being sincere: I can't possibly know the side effects of every piece of code in my app. Assuming you're being sarcastic: I'm not sure what your point is. Since I don't 100% understand every dependency in my app, I have no grounds to be bothered when one of my dependencies does something that violates my expectations?
> "Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn?
I struggled a lot with the title, as I didn't want to project intention onto Stripe.
That said, the behavior is pretty subtle. They don't disclose it in the npm package or the JS documentation. Other API calls initiated by your app show up in your Stripe dashboard, but these ones don't appear anywhere. You can only discover them by inspecting HTTP traffic.
> In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
I'm having trouble understanding this. Assuming you're being sincere: I can't possibly know the side effects of every piece of code in my app. Assuming you're being sarcastic: I'm not sure what your point is. Since I don't 100% understand every dependency in my app, I have no grounds to be bothered when one of my dependencies does something that violates my expectations?
I love Stripe, but this type of feature should be made front and clear when installing it. Some people use Stripe for a very small part of a very large app. If it's an online store, then it's totally fine. If it's an app where 95% of the routes are supposed to be private then it's not ok. So I appreciate this post mtlynch.
voz_(2)
> "Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn?
I fail to see how it's clickbait. "Silently" conveys to the readers that the recordings were done without the user's consent or knowledge.
>In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
Way to victim blame.
I fail to see how it's clickbait. "Silently" conveys to the readers that the recordings were done without the user's consent or knowledge.
>In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
Way to victim blame.
Ok, we've abandoned silence in the title above. I think that's redundant anyhow.
I also took out "your". That's a standard moderation trick since second-person pronouns in titles tend also to be clickbait: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I also took out "your". That's a standard moderation trick since second-person pronouns in titles tend also to be clickbait: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
It's not redundant at all. Admit it you have updated the title because Stripe is HN's company. I don't remember anyone ever editing posts concerning Google's tracking / privacy issues, for example.
We edit titles all the time, including sensational titles about Google or anything else. This is routine. You probably wouldn't remember such edits because you probably wouldn't notice them in the first place.
We particularly edit titles that users have started complaining about: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... Experience has shown that to be the way to minimize off-topic title complaints (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...).
The meaning of the title in this case hasn't changed. Websites don't make noises when they record things.
Edit: out of curiosity, I looked for some other cases where we took out the word 'silently'. Here are some:
https://news.ycombinator.com/item?id=22678471 (changed from "~30% of Android apps silently inspect other apps installed on your smartphone")
https://news.ycombinator.com/item?id=20453115 (changed from "Apple is silently updating Macs * again* to remove Zoom's insecure software")
https://news.ycombinator.com/item?id=16715835 (changed from "Giraffes Silently Slip onto the Endangered Species List")
People have made HN title trackers over the years. My favorite is https://hackernewstitles.netlify.app/ (via https://news.ycombinator.com/item?id=21617016). It's not perfect because it can't distinguish what submitters did from what moderators did, doesn't know what the software changed, etc. But it gives the basic picture.
We particularly edit titles that users have started complaining about: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... Experience has shown that to be the way to minimize off-topic title complaints (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...).
The meaning of the title in this case hasn't changed. Websites don't make noises when they record things.
Edit: out of curiosity, I looked for some other cases where we took out the word 'silently'. Here are some:
https://news.ycombinator.com/item?id=22678471 (changed from "~30% of Android apps silently inspect other apps installed on your smartphone")
https://news.ycombinator.com/item?id=20453115 (changed from "Apple is silently updating Macs * again* to remove Zoom's insecure software")
https://news.ycombinator.com/item?id=16715835 (changed from "Giraffes Silently Slip onto the Endangered Species List")
People have made HN title trackers over the years. My favorite is https://hackernewstitles.netlify.app/ (via https://news.ycombinator.com/item?id=21617016). It's not perfect because it can't distinguish what submitters did from what moderators did, doesn't know what the software changed, etc. But it gives the basic picture.
I find https://hackernewstitles.netlify.app/ fascinating.
Perhaps we all have a natural unconscious bias against being "edited" ("you're not in control of me [or the OP]!!"). But seeing the edits over time in the open really makes one appreciate the moderation work. Maybe it's worth making this more official somehow (e.g., adding a footnote in the submission page or to the FAQ) - because like you say, it must surely minimize off-topic discussions as well.
Anyway, thanks for your work!
Perhaps we all have a natural unconscious bias against being "edited" ("you're not in control of me [or the OP]!!"). But seeing the edits over time in the open really makes one appreciate the moderation work. Maybe it's worth making this more official somehow (e.g., adding a footnote in the submission page or to the FAQ) - because like you say, it must surely minimize off-topic discussions as well.
Anyway, thanks for your work!
Maybe we should publish a complete log after all. Especially with the title edits, we've been doing them for so long now that they really have become routine. It's pretty much a craft at this point—a very tiny and trivial craft, with many tiny rules and heuristics. I used to mildly resent having to do it, because titles feel so, again, trivial. But eventually it dawned on me why they are such an emotional thing. There's more about this here if anyone cares:
https://news.ycombinator.com/item?id=20429573
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
https://news.ycombinator.com/item?id=20429573
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
I'd personally appreciate some way to tell right on HN that a title has been edited (or more importantly, that the original URL was altered to point to a different page... THAT is much more significant, and a bit troubling to me.) Then again, maybe title moderation works best for the community when done silently. (It'd be fair to use the word "silently" in this case, right?)
We nearly always post a comment when we change a URL: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... The most significant title edits get comments too: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... If we published a title log, URL changes could certainly be included.
The idea of marking every single edit, or publishing a complete moderation log, feels like asking for trouble. I fear that it would lead to more objections of the litigious, bureaucratic, meta type. Even though it's a tiny minority of users who make such objections, they have a lot of energy for it and there are many more of them than us. That kind of thing could quickly burn us out, like an unintended DoS attack. On the other hand, maybe it would just work fine; it's hard to know.
Also, I'm skeptical that it would create more confidence in the site, because the users who want to feel that way basically already do, and the ones who don't probably wouldn't be persuaded by more data. There's always going to be something that's not included, or the suspicion that there is.
Because of this, the way we address concerns is to answer people's individual questions, here and by email. We're happy to do that, and there basically isn't anything we aren't willing to explain. That's by design. We try never to do anything that isn't defensible to the community. Even when there are genuine secrets that can't be spelled out, like how the anti-abuse software works, we can say what they are at a high level and why a secret is needed. Those cases are rare.
The idea of marking every single edit, or publishing a complete moderation log, feels like asking for trouble. I fear that it would lead to more objections of the litigious, bureaucratic, meta type. Even though it's a tiny minority of users who make such objections, they have a lot of energy for it and there are many more of them than us. That kind of thing could quickly burn us out, like an unintended DoS attack. On the other hand, maybe it would just work fine; it's hard to know.
Also, I'm skeptical that it would create more confidence in the site, because the users who want to feel that way basically already do, and the ones who don't probably wouldn't be persuaded by more data. There's always going to be something that's not included, or the suspicion that there is.
Because of this, the way we address concerns is to answer people's individual questions, here and by email. We're happy to do that, and there basically isn't anything we aren't willing to explain. That's by design. We try never to do anything that isn't defensible to the community. Even when there are genuine secrets that can't be spelled out, like how the anti-abuse software works, we can say what they are at a high level and why a secret is needed. Those cases are rare.
The accuracy of the adverb "silently" is debatable, as are other questions that arise the practices described in the article. Here are some debate questions and the way I'd answer them:
1) Is it fair to include the word "silently" in this post's title? [I think so, especially since it's part of the original article and reflects the author's emphasis.]
2) Does the word "silently" make Stripe look sneaky and bad? [Yes.]
3) Is Stripe's level of tracking invasive? [Yes.]
4) Should Stripe have been more forthcoming about the level of tracking they practice? [Most definitely! In this age of data breaches, users-as-the-product, and sneaky, untrustworthy online companies, Stripe should DEFINITELY have been more open about this, and should let its payment-service customers know what they're signing up for, in clear terms. Fraud prevention is a desirable feature, but potential customers should also be able to weigh that against the cost of invasive tracking. Furthermore, as a payment-processing company which can make loads of money in a very straightforward way (through commissions), Stripe should be content to be just that, and should get rid of any ideas, visions, or TOS language involving payment-service-tracking-derived advertising. If Stripe wants to take the high road, they could consider adding a "no data sold to advertisers" canary in its TOS that can assure the privacy-conscious of Stripe's pure intentions--or warn them when an undesirable corporate change happens that may prompt them to look for a service more aligned with their own priorities. Personally, I'm tired of companies that want to take over the world and seek profit in every area at any cost. Sheesh!]
1) Is it fair to include the word "silently" in this post's title? [I think so, especially since it's part of the original article and reflects the author's emphasis.]
2) Does the word "silently" make Stripe look sneaky and bad? [Yes.]
3) Is Stripe's level of tracking invasive? [Yes.]
4) Should Stripe have been more forthcoming about the level of tracking they practice? [Most definitely! In this age of data breaches, users-as-the-product, and sneaky, untrustworthy online companies, Stripe should DEFINITELY have been more open about this, and should let its payment-service customers know what they're signing up for, in clear terms. Fraud prevention is a desirable feature, but potential customers should also be able to weigh that against the cost of invasive tracking. Furthermore, as a payment-processing company which can make loads of money in a very straightforward way (through commissions), Stripe should be content to be just that, and should get rid of any ideas, visions, or TOS language involving payment-service-tracking-derived advertising. If Stripe wants to take the high road, they could consider adding a "no data sold to advertisers" canary in its TOS that can assure the privacy-conscious of Stripe's pure intentions--or warn them when an undesirable corporate change happens that may prompt them to look for a service more aligned with their own priorities. Personally, I'm tired of companies that want to take over the world and seek profit in every area at any cost. Sheesh!]
> How do you not know all the side effects you dependencies may have when before adding them?
Do you? You've audited 100% of the code you use? At best you're careful when choosing your dependencies and you have a reasonable degree of trust.
Do you? You've audited 100% of the code you use? At best you're careful when choosing your dependencies and you have a reasonable degree of trust.
[deleted]
Honestly, this looks very very standard. Having processed millions of $$$ through Stripe, most of this brings very welcome insight and information that prevented a significant amount of fraud, though sadly not catching all of it.
The only way for that to get better is through more tracking.
At the end of the day, many are paying for Stripe to protect them and their business, but you can build it yourself, in which case it is a capital investment for you that likely will cost you more than the % charges you have on each transaction.
If you don't want that insight, agreed that it likely could be done through a flag, but your suggestion I'd say is likely ideal.
The only way for that to get better is through more tracking.
At the end of the day, many are paying for Stripe to protect them and their business, but you can build it yourself, in which case it is a capital investment for you that likely will cost you more than the % charges you have on each transaction.
If you don't want that insight, agreed that it likely could be done through a flag, but your suggestion I'd say is likely ideal.
I once complained to a PM about tracker scripts that my company was placing on its own site. They said that the data from the scripts was bringing in $2 million a year and there was nothing they would do.
Whats with these ‘hit jobs’ on tech firms coming up every now and then?
How about Visa and MasterCard? I would be more surprised where these profiles didn’t exist.
hairy internet troll here.
What’s most interesting to me is that even an immortal software founder such as PC can find themselves in situations where their company has deeply rationalized actions that, to both the general and technically sophisticated public, appear to very plainly egregiously violate basic user privacy rights.
Venture Capital is a helluva drug.
What’s most interesting to me is that even an immortal software founder such as PC can find themselves in situations where their company has deeply rationalized actions that, to both the general and technically sophisticated public, appear to very plainly egregiously violate basic user privacy rights.
Venture Capital is a helluva drug.
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