3 ms·

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/

by 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

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.