9 ms·

Stripe responded to my concerns about user tracking

233 points by mtlynch 7y ago

mtlynch 7y ago
Hi all. Author here. This is a follow-up from my post last week, "Stripe records user movements on its customers' websites": https://mtlynch.io/stripe-recording-its-customers/ https://mtlynch.io/stripe-recording-its-customers/ https://news.ycombinator.com/item?id=22936818 https://news.ycombinator.com/item?id=22936818 As always, feedback and questions are welcome.
- thoraway1010 7y ago
  Do you understand anything more yourself? The need for some of these steps for fraud control (vs your assume bad intentions initial approach).
  - mtlynch 7y ago
    Thanks for reading! I understood from the start that this data was for fraud protection. At the time of my initial article, Stripe had not clearly disclosed the extent of their tracking nor stated any limitations on how they would use the data. I tried hard to avoid accusing Stripe of nefarious behavior, so if there are specific sections in my post that failed to do this, please let me know. Regardless of Stripe's intentions, I believe there needs to be clear agreement about what data Stripe collects and what limits they'll observe in using that data. If we blindly allow Stripe to collect whatever data their JS library has access to as long as their intentions are good, we put ourselves at risk if that data falls into the wrong hands. I think Stripe shows a serious commitment to privacy and security, but there's always an inherent risk in storing copies of data with a third party. The more data that Stripe collects, the greater that risk, so clients should have a say in whether that increase in risk is worth the improvement they receive in the accuracy of Stripe's fraud protection.
    - gav 7y ago
      > [..] we put ourselves at risk if that data falls into the wrong hands. This argument confuses me. You you are willing to trust Stripe with your customers' address and credit card details. You trust that their Javascript doesn't send this to an attacker. What other data are you worried about falling into the wrong hands?
      - mtlynch 7y ago
        Thanks for reading! Oh, there's tons of sensitive data beyond just financial details. As an extreme example, suppose I ran a paid email service and allowed Stripe to collect any data they wanted, including page contents and keystrokes. That would give Stripe a massive amount of sensitive user data. As a more realistic example, suppose that I ran a dating site and the log of URLs that Stripe currently collects exposes which profiles users are viewing and whom they're communicating with. If a user's credit card details are stolen, that's a bummer, but it happens all the time. If a user's dating site behavior was published, many people would consider that a serious violation more severe than having to order a new credit card.
        gav 7y ago
        If you have ANY third-party scripts running on your site you have a risk that they are spying on your users by choice or they've been hacked, e.g. Ticketmaster/Magecart[1]. In both your examples, you'd want to restrict what third-party code lives on what part of the site. In a similar way, you don't want your adtech partners running code on your checkout pages. You want to remove the need to trust entirely. Your second scenario doesn't feel that realistic at all. You are worried that Stripe is going to have enough URLs logged to have a useful dating history for a user and then somebody is going to hack Stripe to gain access to this data (perhaps a nefarious employee), exfiltrate enough of it to reconstruct, then publish the history. If this is a concern, you should have total control over your entire infrastructure. If you are on AWS perhaps there's a chance that somebody will hack ELB so they can get a complete history of all your users too? [1] https://www.securityweek.com/ticketmaster-breach-tip-iceberg-major-ongoing-magecart-attacks https://www.securityweek.com/ticketmaster-breach-tip-iceberg...
adrr 7y ago
"We do not use, share, rent or sell the Personal Data of our Users’ Customers for interest-based advertising. " Better version would be all advertising instead of interest-based advertising Also "personal" data excludes lots of data. Personal data just means data that is attached an identified person. Lot of ad targeting is at an anonymous ID, they don't really know the person.
- stefan_ 7y ago
  This is not how any of this works. You don't write a privacy policy listing all the things you don't do; you write it listing and justifying the things that you do.
  - luckylion 7y ago
    They literally wrote what they won't do. They were just very specific with it, which suggests they may use, share, rent and sell the personal data for non-interest-based advertising, e.g. demographic-based advertising and want to keep the option on the table.
amelius 7y ago
Can someone explain what kind of fraud we're talking about?
- swanson 7y ago
  Bots that use stolen cards to make purchases (or use legitimate SaaS apps as a vector to test if a card number if valid) Stripe "tracks" user data that they run through some fancy ML thing to try to detect if the person is a bot or a real human -- based on, presumably, patterns in user mouse movement, delay in moving between inputs, interval between keystrokes, etc.
  - amelius 7y ago
    But we have other ways of testing for bots. See for example Google's Recaptcha (again, example, and not my main point). I don't see why we need to give away our personal information to yet another big company, especially if the information comes from web surfing behavior that has nothing to do with payment. And in case this is all still necessary, can't this be handled by some trusted party instead of the company that already knows about all our online payment transactions? Compartmentalization is a very important concept in user privacy. https://en.wikipedia.org/wiki/Compartmentalization_(information_security) https://en.wikipedia.org/wiki/Compartmentalization_(informat...
    - akersten 7y ago
      How do you think ReCaptcha (at least ReCaptchaV3) works? It's gathers the same kind of "personal" data (mouse movements, etc.) to feed an ML model to determine whether the client is a robot.
      - amelius 7y ago
        Yes, but only from the page the captcha is visible on. In contrast, Stripe collects also data from webpages that are not payment pages.
morpheuskafka 7y ago
> Stripe updated their JavaScript library to give clients the ability to opt-out of deep data collection. They can now load the <script> tag with the advancedFraudSignals=false parameter to disable this functionality: If this is set on the client-side, what stops an attacker from editing the page to disable the fraud detection sites that want to use it?
- jedberg 7y ago
  Sure, but that in and of itself would be a major fraud signal. If 99% of the traffic from a site is coming into their fraud system, and yours isn't, that would be an even bigger fraud signal that if it were on.
amrrs 7y ago
Icymi, Stripe CEO Patrick Collision's response to the original thread - https://news.ycombinator.com/item?id=22937303 https://news.ycombinator.com/item?id=22937303
akersten 7y ago
I think this part is a little off: > Perhaps you have no sympathy for web applications that store sensitive data in query strings, as that’s widely recognized as an insecure pattern. The URL fragment is more serious. That otherwise is a safe way to store sensitive information, so it’s alarming to see a third-party library sending a copy to an external server. > Firefox Send and Mega.nz are both examples of popular web apps that use the URL fragment to store client-side encryption keys so that users can save end-to-end encrypted files to the cloud without the server ever having access to the underlying data. The URL fragment is not designed to be any more secure than anything else in the URL, it's just a funny quirk of how web browsers evolved that it doesn't happen to be sent to the webserver. That popular platforms are (mis)using it to pass information without that information hitting their webservers is unfortunate. But it doesn't mean that the URL Fragment is somehow special or should be thought of as "secure" - that's not a guarantee that the URL scheme makes. For example, those fragments will easily appear in browser history for anyone else who uses your same device...
- tptacek 7y ago
  This is sort of fair as a statement of principles but I think OAuth2 gets you into the same kind of trouble with special security status for the fragment.
  - andy_ppp 7y ago
    Yes. I’m debating in my head who is correct here. Maybe Oauth2 is colouring my judgement a bit but I feel the fragment should NOT be sent to the server unless there are extremely good reasons. Let’s try to keep the understanding of what happens to certain things consistent even if we have the power to abuse them.
- mtlynch 7y ago
  Thanks for reading! That's an interesting point. I did take it for granted that browsers guarantee web apps that they don't send the URL fragment to the server. I've never looked into it, but your comment sent me to read RFC 3986. From my reading, the RFC does seem to prohibit browsers from sending the URL fragment: >Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing... As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. Granted, the wording isn't 100% clear, so maybe I'm imposing my own hopeful interpretation on the RFC. I agree that if I were storing, say, military secrets, I wouldn't choose the URL fragment as a storage medium. But if the expectation is "this is a place where I can put user data and the browser won't leak it to other places," then the URL fragment seems to me a sensible place to store data, on par with browser local storage. This is in contrast with plain URLs which third party servers receive through the HTTP referer header. The browser leaks query parameters to other places, too, notably HTTP proxies. But Stripe's JS library was the first I'd seen of a system that exposes URL fragments to an external service.
loeg 7y ago
I remain extremely impressed by Stripe and pc's handling of this; kudos for taking a somewhat hostile blog post and using it to inspire improvement.
- bryanmgreen 7y ago
  Generally speaking, it's pretty shocking how utterly abysmal crisis/damage-control PR is for companies. Rather than "never letting a good crisis go to waste", most companies/leaders just dig a deeper hole. A small part of me would love to just start a Crisis PR firm for tech companies. Regardless of who's right or wrong, it's really nice to see a leader come out and actually face criticisms with a cool head, and at least from my point of view, not bullshit legal language. Even better if it does encourage positive change. (Specifically about Stripe, I am positively biased because once I submitted some feedback and their product team immediately jumped to communicate with me as to how to best design and implement the feature.)
  - tmpz22 7y ago
    I don't think most companies have the capacity to handle it well in the first place. I think the outliers like Stripe are different because they have a very hands on CEO who can cut through all the tape, IIRC they also have a fairly learn and very technical organization with strong domain knowledge in areas where the tape is cut. Most orgs are non-engineering orgs, most CEOs are not technical, most large orgs have far too much bureaucracy to cut through it.
    - projektfu 7y ago
      I feel like many companies don’t want to commit to giving up a potential revenue stream, even if they’re not tapping it. So you get ignored or mealy mouth responses.
    - bryanmgreen 7y ago
      If you're a CEO or a senior executive, I personally would expect that you're 100% capable of responding to criticism without losing your mind or spending $5,000 for a lawyer to send you some copy-pasta of "We take your feedback very seriously and will consider your opinion." and then never doing anything. I'm not suggesting the leader be the one to personally go and fix the problem, but they certainly should have the communication skills to navigate it and organize a solution.
earpwald 7y ago
Personally I think this has been a good pointer that we need to be careful about what we trust third party libraries and frameworks to do. I in no way believe that Stripe had any intentions of doing anything wrong, however it is good to hold people accountable and ensure that what they do is above board. I have personal examples of companies caring very little about users data, except when they might be caught out for it. Thanks for the article.
- mtlynch 7y ago
  Thanks for reading! >I in no way believe that Stripe had any intentions of doing anything wrong, however it is good to hold people accountable and ensure that what they do is above board. I have personal examples of companies caring very little about users data, except when they might be caught out for it. Very much agree. I think Stripe is demonstrating responsible behavior here, and the best way to further encourage that is to show that people actually care what they do and will raise alarms when they overstep, even inadvertently.
geekpowa 7y ago
If only PayPal were as accessible and responsive as stripe. There is a serious regression in their API right now : it is so bad and obvious it shouldn't of even made it past their internal testing stage. Been there for 2 weeks now. You think I can get anyones attention at paypal? They don't even seem to have a decent issue ticketing system to track it.
- mtlynch 7y ago
  In fairness, Stripe also kind of brushed this off until it got more attention. There are StackOverflow posts going back to 2017[0] and Github issues with direct acknowledgement from Stripe employees with no solution offered.[1] I even reached out to Stripe support before publishing my first post, and they told me that the collection behavior was by design and in my users' best interest.[2] I've been very impressed by Stripe's response here, but it's demonstrably not the same response they deliver to customers who go through normal support channels. [0] https://stackoverflow.com/q/45718026/90388 https://stackoverflow.com/q/45718026/90388 [1] https://github.com/stripe/react-stripe-elements/issues/99#issuecomment-528987443 https://github.com/stripe/react-stripe-elements/issues/99#is... [2] https://mtlynch.io/stripe-recording-its-customers/#reporting-this-to-stripe https://mtlynch.io/stripe-recording-its-customers/#reporting...
  - brunoTbear 7y ago
    Stripe "brushed this off" until a sensationalist headline appeared on HN.
  - brogrammernot 7y ago
    I’m sure I’ll get downvoted but why should it be? Stripe has thousands of items in the backlog across many areas, and in a larger company there’s prioritization at many different levels. I’m happy that they addressed this but I often see on HN that folks expect that an email to support staff gets the same level of support/awareness as a highly viewed post on HN does. As a Stripe customer, there are several things that I’d love to see improved or modified but I don’t expect all, if any, of them to make it into the roadmap immediately as they’re trying to scale & fix really big issues that have already been identified. Do I wish it was possible for businesses to address every single customer/consumer complaint? Of course, but that’s not the reality we live in. Also - I’m not letting any company off the hook with this statement, there’s plenty of companies out there that intentionally neglect glaring issues because they don’t want to deal with the noise that comes along with it but Stripe hasn’t really even been one of those companies. Sometimes it is the best company policy to ignore items until they go away, and to deal with the ones that rise to the top naturally.
jbverschoor 7y ago
“Interest based advertising” That does not include: - analytics by companies based on interest - advertising based on monthly spend
tompic823 7y ago
I read the initial post when it was trending on HN, and had previously noticed that line in Stripe's Privacy Policy. I remember checking immediately afterward that my company was only loading Stripe's js on our billing page. I'm a skeptic by nature, so even after reading pc's response I still didn't feel great. Then I got to reading this new post: > Amid the discussion on Hacker News, a user expressed concern that, despite Stripe’s current good intentions, user data could fall into the wrong hands in the event that another company purchased Stripe ... Perhaps in direct response to that exchange, the new privacy policy includes this clause: > > Any other entity which buys us or part of our business will have the right to continue to use your Personal Data, but only in the manner set out in this Privacy Policy unless you agree otherwise. This is fantastic. I've yet to see a requirement such as this in any Privacy Policy I've read. In fact, I hadn't even considered the possibility of such cleverness. This is now my new gold standard for the company sale terms of any practical privacy policy. I'm going to look into updating my company's privacy policy to reflect this language.
- barbegal 7y ago
  > Any other entity which buys us or part of our business will have the right to continue to use your Personal Data, but only in the manner set out in this Privacy Policy unless you agree otherwise. I thought this was implied in any contract. A change of owner doesn't mean the terms of the contract stop being applied.
  - saagarjha 7y ago
    Often contracts will include verbiage like “we may alter this at any time without notice and also if we are acquired we can give all our data”.
    - barbegal 7y ago
      Which may be deemed a "deceptive business practice" [1] [1] https://www.freeprivacypolicy.com/blog/update-notices-changes-privacy-policy/ https://www.freeprivacypolicy.com/blog/update-notices-change...
  - 7y ago
timvisee 7y ago
They mention the use of a script parameter. Can't bots just set this parameter on any website using stripe to bypass this detection, or is this enforced on Stripes end as well?
- warkdarrior 7y ago
  I am sure it is enforced on the Stripe backend. Basically it sounds like there are two options: 1. Do not set the script parameter, let Stripe collect the data, and have them do fraud detection, which will result in better risk scores and more transactions approved. 2. Do set the parameter, prevent Strip from collecting the data, and prevent them from doing the fraud detection (since they have no data to feed the detector). This may result in a higher risk score (meaning higher fees) and/or fewer transactions approved.

233 points by mtlynch 7y ago

Hi all. Author here. This is a follow-up from my post last week, "Stripe records user movements on its customers' websites": https://mtlynch.io/stripe-recording-its-customers/ https://mtlynch.io/stripe-recording-its-customers/ https://news.ycombinator.com/item?id=22936818 https://news.ycombinator.com/item?id=22936818 As always, feedback and questions are welcome.

thoraway1010 7y ago
Do you understand anything more yourself? The need for some of these steps for fraud control (vs your assume bad intentions initial approach).
- mtlynch 7y ago
  Thanks for reading! I understood from the start that this data was for fraud protection. At the time of my initial article, Stripe had not clearly disclosed the extent of their tracking nor stated any limitations on how they would use the data. I tried hard to avoid accusing Stripe of nefarious behavior, so if there are specific sections in my post that failed to do this, please let me know. Regardless of Stripe's intentions, I believe there needs to be clear agreement about what data Stripe collects and what limits they'll observe in using that data. If we blindly allow Stripe to collect whatever data their JS library has access to as long as their intentions are good, we put ourselves at risk if that data falls into the wrong hands. I think Stripe shows a serious commitment to privacy and security, but there's always an inherent risk in storing copies of data with a third party. The more data that Stripe collects, the greater that risk, so clients should have a say in whether that increase in risk is worth the improvement they receive in the accuracy of Stripe's fraud protection.
  - gav 7y ago
    > [..] we put ourselves at risk if that data falls into the wrong hands. This argument confuses me. You you are willing to trust Stripe with your customers' address and credit card details. You trust that their Javascript doesn't send this to an attacker. What other data are you worried about falling into the wrong hands?
    - mtlynch 7y ago
      Thanks for reading! Oh, there's tons of sensitive data beyond just financial details. As an extreme example, suppose I ran a paid email service and allowed Stripe to collect any data they wanted, including page contents and keystrokes. That would give Stripe a massive amount of sensitive user data. As a more realistic example, suppose that I ran a dating site and the log of URLs that Stripe currently collects exposes which profiles users are viewing and whom they're communicating with. If a user's credit card details are stolen, that's a bummer, but it happens all the time. If a user's dating site behavior was published, many people would consider that a serious violation more severe than having to order a new credit card.
      - gav 7y ago
        If you have ANY third-party scripts running on your site you have a risk that they are spying on your users by choice or they've been hacked, e.g. Ticketmaster/Magecart[1]. In both your examples, you'd want to restrict what third-party code lives on what part of the site. In a similar way, you don't want your adtech partners running code on your checkout pages. You want to remove the need to trust entirely. Your second scenario doesn't feel that realistic at all. You are worried that Stripe is going to have enough URLs logged to have a useful dating history for a user and then somebody is going to hack Stripe to gain access to this data (perhaps a nefarious employee), exfiltrate enough of it to reconstruct, then publish the history. If this is a concern, you should have total control over your entire infrastructure. If you are on AWS perhaps there's a chance that somebody will hack ELB so they can get a complete history of all your users too? [1] https://www.securityweek.com/ticketmaster-breach-tip-iceberg-major-ongoing-magecart-attacks https://www.securityweek.com/ticketmaster-breach-tip-iceberg...

adrr 7y ago

"We do not use, share, rent or sell the Personal Data of our Users’ Customers for interest-based advertising. " Better version would be all advertising instead of interest-based advertising Also "personal" data excludes lots of data. Personal data just means data that is attached an identified person. Lot of ad targeting is at an anonymous ID, they don't really know the person.

stefan_ 7y ago
This is not how any of this works. You don't write a privacy policy listing all the things you don't do; you write it listing and justifying the things that you do.
- luckylion 7y ago
  They literally wrote what they won't do. They were just very specific with it, which suggests they may use, share, rent and sell the personal data for non-interest-based advertising, e.g. demographic-based advertising and want to keep the option on the table.

amelius 7y ago

Can someone explain what kind of fraud we're talking about?

swanson 7y ago
Bots that use stolen cards to make purchases (or use legitimate SaaS apps as a vector to test if a card number if valid) Stripe "tracks" user data that they run through some fancy ML thing to try to detect if the person is a bot or a real human -- based on, presumably, patterns in user mouse movement, delay in moving between inputs, interval between keystrokes, etc.
- amelius 7y ago
  But we have other ways of testing for bots. See for example Google's Recaptcha (again, example, and not my main point). I don't see why we need to give away our personal information to yet another big company, especially if the information comes from web surfing behavior that has nothing to do with payment. And in case this is all still necessary, can't this be handled by some trusted party instead of the company that already knows about all our online payment transactions? Compartmentalization is a very important concept in user privacy. https://en.wikipedia.org/wiki/Compartmentalization_(information_security) https://en.wikipedia.org/wiki/Compartmentalization_(informat...
  - akersten 7y ago
    How do you think ReCaptcha (at least ReCaptchaV3) works? It's gathers the same kind of "personal" data (mouse movements, etc.) to feed an ML model to determine whether the client is a robot.
    - amelius 7y ago
      Yes, but only from the page the captcha is visible on. In contrast, Stripe collects also data from webpages that are not payment pages.

morpheuskafka 7y ago

> Stripe updated their JavaScript library to give clients the ability to opt-out of deep data collection. They can now load the <script> tag with the advancedFraudSignals=false parameter to disable this functionality: If this is set on the client-side, what stops an attacker from editing the page to disable the fraud detection sites that want to use it?

jedberg 7y ago
Sure, but that in and of itself would be a major fraud signal. If 99% of the traffic from a site is coming into their fraud system, and yours isn't, that would be an even bigger fraud signal that if it were on.

amrrs 7y ago

Icymi, Stripe CEO Patrick Collision's response to the original thread - https://news.ycombinator.com/item?id=22937303 https://news.ycombinator.com/item?id=22937303

akersten 7y ago

I think this part is a little off: > Perhaps you have no sympathy for web applications that store sensitive data in query strings, as that’s widely recognized as an insecure pattern. The URL fragment is more serious. That otherwise is a safe way to store sensitive information, so it’s alarming to see a third-party library sending a copy to an external server. > Firefox Send and Mega.nz are both examples of popular web apps that use the URL fragment to store client-side encryption keys so that users can save end-to-end encrypted files to the cloud without the server ever having access to the underlying data. The URL fragment is not designed to be any more secure than anything else in the URL, it's just a funny quirk of how web browsers evolved that it doesn't happen to be sent to the webserver. That popular platforms are (mis)using it to pass information without that information hitting their webservers is unfortunate. But it doesn't mean that the URL Fragment is somehow special or should be thought of as "secure" - that's not a guarantee that the URL scheme makes. For example, those fragments will easily appear in browser history for anyone else who uses your same device...

tptacek 7y ago
This is sort of fair as a statement of principles but I think OAuth2 gets you into the same kind of trouble with special security status for the fragment.
- andy_ppp 7y ago
  Yes. I’m debating in my head who is correct here. Maybe Oauth2 is colouring my judgement a bit but I feel the fragment should NOT be sent to the server unless there are extremely good reasons. Let’s try to keep the understanding of what happens to certain things consistent even if we have the power to abuse them.
mtlynch 7y ago
Thanks for reading! That's an interesting point. I did take it for granted that browsers guarantee web apps that they don't send the URL fragment to the server. I've never looked into it, but your comment sent me to read RFC 3986. From my reading, the RFC does seem to prohibit browsers from sending the URL fragment: >Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing... As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. Granted, the wording isn't 100% clear, so maybe I'm imposing my own hopeful interpretation on the RFC. I agree that if I were storing, say, military secrets, I wouldn't choose the URL fragment as a storage medium. But if the expectation is "this is a place where I can put user data and the browser won't leak it to other places," then the URL fragment seems to me a sensible place to store data, on par with browser local storage. This is in contrast with plain URLs which third party servers receive through the HTTP referer header. The browser leaks query parameters to other places, too, notably HTTP proxies. But Stripe's JS library was the first I'd seen of a system that exposes URL fragments to an external service.

loeg 7y ago

I remain extremely impressed by Stripe and pc's handling of this; kudos for taking a somewhat hostile blog post and using it to inspire improvement.

bryanmgreen 7y ago
Generally speaking, it's pretty shocking how utterly abysmal crisis/damage-control PR is for companies. Rather than "never letting a good crisis go to waste", most companies/leaders just dig a deeper hole. A small part of me would love to just start a Crisis PR firm for tech companies. Regardless of who's right or wrong, it's really nice to see a leader come out and actually face criticisms with a cool head, and at least from my point of view, not bullshit legal language. Even better if it does encourage positive change. (Specifically about Stripe, I am positively biased because once I submitted some feedback and their product team immediately jumped to communicate with me as to how to best design and implement the feature.)
- tmpz22 7y ago
  I don't think most companies have the capacity to handle it well in the first place. I think the outliers like Stripe are different because they have a very hands on CEO who can cut through all the tape, IIRC they also have a fairly learn and very technical organization with strong domain knowledge in areas where the tape is cut. Most orgs are non-engineering orgs, most CEOs are not technical, most large orgs have far too much bureaucracy to cut through it.
  - projektfu 7y ago
    I feel like many companies don’t want to commit to giving up a potential revenue stream, even if they’re not tapping it. So you get ignored or mealy mouth responses.
  - bryanmgreen 7y ago
    If you're a CEO or a senior executive, I personally would expect that you're 100% capable of responding to criticism without losing your mind or spending $5,000 for a lawyer to send you some copy-pasta of "We take your feedback very seriously and will consider your opinion." and then never doing anything. I'm not suggesting the leader be the one to personally go and fix the problem, but they certainly should have the communication skills to navigate it and organize a solution.

earpwald 7y ago

Personally I think this has been a good pointer that we need to be careful about what we trust third party libraries and frameworks to do. I in no way believe that Stripe had any intentions of doing anything wrong, however it is good to hold people accountable and ensure that what they do is above board. I have personal examples of companies caring very little about users data, except when they might be caught out for it. Thanks for the article.

mtlynch 7y ago
Thanks for reading! >I in no way believe that Stripe had any intentions of doing anything wrong, however it is good to hold people accountable and ensure that what they do is above board. I have personal examples of companies caring very little about users data, except when they might be caught out for it. Very much agree. I think Stripe is demonstrating responsible behavior here, and the best way to further encourage that is to show that people actually care what they do and will raise alarms when they overstep, even inadvertently.

geekpowa 7y ago

If only PayPal were as accessible and responsive as stripe. There is a serious regression in their API right now : it is so bad and obvious it shouldn't of even made it past their internal testing stage. Been there for 2 weeks now. You think I can get anyones attention at paypal? They don't even seem to have a decent issue ticketing system to track it.

mtlynch 7y ago
In fairness, Stripe also kind of brushed this off until it got more attention. There are StackOverflow posts going back to 2017[0] and Github issues with direct acknowledgement from Stripe employees with no solution offered.[1] I even reached out to Stripe support before publishing my first post, and they told me that the collection behavior was by design and in my users' best interest.[2] I've been very impressed by Stripe's response here, but it's demonstrably not the same response they deliver to customers who go through normal support channels. [0] https://stackoverflow.com/q/45718026/90388 https://stackoverflow.com/q/45718026/90388 [1] https://github.com/stripe/react-stripe-elements/issues/99#issuecomment-528987443 https://github.com/stripe/react-stripe-elements/issues/99#is... [2] https://mtlynch.io/stripe-recording-its-customers/#reporting-this-to-stripe https://mtlynch.io/stripe-recording-its-customers/#reporting...
- brunoTbear 7y ago
  Stripe "brushed this off" until a sensationalist headline appeared on HN.
- brogrammernot 7y ago
  I’m sure I’ll get downvoted but why should it be? Stripe has thousands of items in the backlog across many areas, and in a larger company there’s prioritization at many different levels. I’m happy that they addressed this but I often see on HN that folks expect that an email to support staff gets the same level of support/awareness as a highly viewed post on HN does. As a Stripe customer, there are several things that I’d love to see improved or modified but I don’t expect all, if any, of them to make it into the roadmap immediately as they’re trying to scale & fix really big issues that have already been identified. Do I wish it was possible for businesses to address every single customer/consumer complaint? Of course, but that’s not the reality we live in. Also - I’m not letting any company off the hook with this statement, there’s plenty of companies out there that intentionally neglect glaring issues because they don’t want to deal with the noise that comes along with it but Stripe hasn’t really even been one of those companies. Sometimes it is the best company policy to ignore items until they go away, and to deal with the ones that rise to the top naturally.

jbverschoor 7y ago

“Interest based advertising” That does not include: - analytics by companies based on interest - advertising based on monthly spend

tompic823 7y ago

I read the initial post when it was trending on HN, and had previously noticed that line in Stripe's Privacy Policy. I remember checking immediately afterward that my company was only loading Stripe's js on our billing page. I'm a skeptic by nature, so even after reading pc's response I still didn't feel great. Then I got to reading this new post: > Amid the discussion on Hacker News, a user expressed concern that, despite Stripe’s current good intentions, user data could fall into the wrong hands in the event that another company purchased Stripe ... Perhaps in direct response to that exchange, the new privacy policy includes this clause: > > Any other entity which buys us or part of our business will have the right to continue to use your Personal Data, but only in the manner set out in this Privacy Policy unless you agree otherwise. This is fantastic. I've yet to see a requirement such as this in any Privacy Policy I've read. In fact, I hadn't even considered the possibility of such cleverness. This is now my new gold standard for the company sale terms of any practical privacy policy. I'm going to look into updating my company's privacy policy to reflect this language.

barbegal 7y ago
> Any other entity which buys us or part of our business will have the right to continue to use your Personal Data, but only in the manner set out in this Privacy Policy unless you agree otherwise. I thought this was implied in any contract. A change of owner doesn't mean the terms of the contract stop being applied.
- saagarjha 7y ago
  Often contracts will include verbiage like “we may alter this at any time without notice and also if we are acquired we can give all our data”.
  - barbegal 7y ago
    Which may be deemed a "deceptive business practice" [1] [1] https://www.freeprivacypolicy.com/blog/update-notices-changes-privacy-policy/ https://www.freeprivacypolicy.com/blog/update-notices-change...
- 7y ago

timvisee 7y ago

They mention the use of a script parameter. Can't bots just set this parameter on any website using stripe to bypass this detection, or is this enforced on Stripes end as well?

warkdarrior 7y ago
I am sure it is enforced on the Stripe backend. Basically it sounds like there are two options: 1. Do not set the script parameter, let Stripe collect the data, and have them do fraud detection, which will result in better risk scores and more transactions approved. 2. Do set the parameter, prevent Strip from collecting the data, and prevent them from doing the fraud detection (since they have no data to feed the detector). This may result in a higher risk score (meaning higher fees) and/or fewer transactions approved.