4 ms·

> [..] 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' ad

by 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.
  - dannyw 6y ago
    I think this is a strawman argument here. Script makers have a an implicit (and explicit mandate in the EU) responsibility to be upfront with what they do. No one will be happy if stripe or Google Analytics started including a bitcoin miner. In this example, stripe did not exactly disclose what they collected or how they use it at first. They did not provide a way to opt out. Now they do. It seems a diversion to compare this to someone hacking ELB and stealing data. Yes, all data can be hacked, just like how governments CAN warrantlessly wiretap you through FISA. It doesn’t mean we shouldn’t fight for 4th amendment when the government raids your house without a search warrant.

by gav 6y ago

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.
- dannyw 6y ago
  I think this is a strawman argument here. Script makers have a an implicit (and explicit mandate in the EU) responsibility to be upfront with what they do. No one will be happy if stripe or Google Analytics started including a bitcoin miner. In this example, stripe did not exactly disclose what they collected or how they use it at first. They did not provide a way to opt out. Now they do. It seems a diversion to compare this to someone hacking ELB and stealing data. Yes, all data can be hacked, just like how governments CAN warrantlessly wiretap you through FISA. It doesn’t mean we shouldn’t fight for 4th amendment when the government raids your house without a search warrant.