4 ms·

Do you understand anything more yourself? The need for some of these steps for fraud control (vs your assume bad intentions initial approach).

mtlynch 6y 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 6y 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 6y 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 6y 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...
      - mtlynch 6y ago
        I think we're mostly in agreement. >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. Yes, I agree. I wrote my first post because I believed many users mistakenly thought that Stripe wouldn't execute until the user called loadStripe, as I found it unintuitive that Stripe actually loaded and began tracking before the app ever called the library. The post included steps for limiting Stripe to individual pages and using CSP to enforce protections. >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? To clarify, I don't believe that it's the most likely vector of attack. If I'm a small enough player that I need to rely on Stripe for payment processing, Stripe almost undoubtedly has a better security team than I do. I'm just saying that in line with your first point, the safest form of trust is no trust at all. If Stripe gives me the ability to limit how much data they collect from my site, it reduces the risk of the data being leaked in transit or in Stripe's storage. I agree those risks are low given Stripe's track record, but they're still higher than if Stripe wasn't collecting sensitive data at all.
- frakkingcylons 6y ago
  > I understood from the start that this data was for fraud protection. If we're being honest with ourselves, the title of your original blog post ("Stripe is Silently Recording Your Movements On its Customers' Websites") is worded like they're being being sneaky and have something to hide.
  - mtlynch 6y ago
    Thanks, that's fair. I gave a lot of thought to how to word it to not project intention onto Stripe. But I did think one of the most important parts of the story was Stripe's lack of disclosure about the behavior. I considered and rejected "secretly" and "surreptitiously" because they suggested intention. "Silently" was the best word I could think of to convey the lack of disclosure while minimizing judgmental undertones. I understand that it still does suggest something underhanded, so maybe it would have been better for me to omit the word entirely.
    - greatwhitenorth 6y ago
      How about "Stripe records Your Movements On its Customers Websites"? Does it still not convey the meaning? But yeah, click bait titles drive traffic to the blog and to your website (portfolio rebalancer) that you linked in your blog post. May be you will end up in page 1 of Google when some one searches "Stripe Privacy". Smart strategy and all in all a win :-)
      - anon102010 6y ago
        "Stripe records cursor movement on customer websites as part of its fraud control efforts" - that's probably the real title. But obviously doesn't get the traffic.
        barrkel 6y ago
        And also every URL you visit on the site

mtlynch 6y 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 6y 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 6y 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 6y 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...
    - mtlynch 6y ago
      I think we're mostly in agreement. >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. Yes, I agree. I wrote my first post because I believed many users mistakenly thought that Stripe wouldn't execute until the user called loadStripe, as I found it unintuitive that Stripe actually loaded and began tracking before the app ever called the library. The post included steps for limiting Stripe to individual pages and using CSP to enforce protections. >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? To clarify, I don't believe that it's the most likely vector of attack. If I'm a small enough player that I need to rely on Stripe for payment processing, Stripe almost undoubtedly has a better security team than I do. I'm just saying that in line with your first point, the safest form of trust is no trust at all. If Stripe gives me the ability to limit how much data they collect from my site, it reduces the risk of the data being leaked in transit or in Stripe's storage. I agree those risks are low given Stripe's track record, but they're still higher than if Stripe wasn't collecting sensitive data at all.
frakkingcylons 6y ago
> I understood from the start that this data was for fraud protection. If we're being honest with ourselves, the title of your original blog post ("Stripe is Silently Recording Your Movements On its Customers' Websites") is worded like they're being being sneaky and have something to hide.
- mtlynch 6y ago
  Thanks, that's fair. I gave a lot of thought to how to word it to not project intention onto Stripe. But I did think one of the most important parts of the story was Stripe's lack of disclosure about the behavior. I considered and rejected "secretly" and "surreptitiously" because they suggested intention. "Silently" was the best word I could think of to convey the lack of disclosure while minimizing judgmental undertones. I understand that it still does suggest something underhanded, so maybe it would have been better for me to omit the word entirely.
  - greatwhitenorth 6y ago
    How about "Stripe records Your Movements On its Customers Websites"? Does it still not convey the meaning? But yeah, click bait titles drive traffic to the blog and to your website (portfolio rebalancer) that you linked in your blog post. May be you will end up in page 1 of Google when some one searches "Stripe Privacy". Smart strategy and all in all a win :-)
    - anon102010 6y ago
      "Stripe records cursor movement on customer websites as part of its fraud control efforts" - that's probably the real title. But obviously doesn't get the traffic.
      - barrkel 6y ago
        And also every URL you visit on the site