Comment by mtlynch | Hacker News Reader

Comment by mtlynch | Hacker News Reader

Parent Full thread

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.

> 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.

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.

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 :-)

"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.

And also every URL you visit on the site

AS does almost all other fraud fighting tools (they all use beacons to try to get as broad a sample as they can of user click / browse trails).

That's not my beef; my beef is the abbreviation of the immediate parent of my comment.

> [..] 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?

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.

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...

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.

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.

Reply on news.ycombinator.com