Stripe responded to my concerns about user tracking
mtlynch.io
mtlynch.io
> 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...
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.
> URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies).
https://tools.ietf.org/html/rfc3986#section-7.5
As an aside, if you're going to be making any security judgments from an RFC, every RFC since RFC2223 has a Security Considerations section. You usually want to start there.
Seems like core problem is lack of storage API that can only be accessed from JS that's executes from same domain?
Edit: Seems localStorage does isolate per domain, but I am not sure whether it's for page itself or for external JS too.
[0] https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...
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.
Good on them, hope to see more of this everywhere.
I thought this was implied in any contract. A change of owner doesn't mean the terms of the contract stop being applied.
[1] https://www.freeprivacypolicy.com/blog/update-notices-change...
AirBnB [0]
> If Airbnb undertakes or is involved in any merger, acquisition, reorganization, sale of assets, bankruptcy, or insolvency event, then we may sell, transfer or share some or all of our assets, including your information in connection with such transaction or in contemplation of such transaction (e.g., due diligence). In this event, we will notify you before your personal information is transferred and becomes subject to a different privacy policy.
Segment [1]
> We may sell, transfer or otherwise share some or all of our business or assets, including your personal information, in connection with a business deal (or potential business deal) such as a merger, consolidation, acquisition, reorganization or sale of assets, or in the event of bankruptcy, in which case we will make reasonable efforts to require the recipient to honor this Privacy Policy.
Repl.it [2]
> We share or disclose information only in the following cases ... - As necessary in the event of a proposed or actual reorganization, merger, sale, joint venture, assignment, transfer, financing, or other disposition of all or any portion of our business, assets, or stock.
[0] https://www.airbnb.com/terms/privacy_policy
If e.g. Google would sell Google Analytics to Facebook, they cannot use the Analytics data to track users and send them emails, since it wasn't originally agreed upon with the GA-users. They very much can send an email to every GA user and offer them the new FBGA premium service.
It would be much harder for Stripe to do that transitively, though, and presumably the vendors, i.e. Stripe's customers, can't grant this on users' behalf.
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.)
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.
This is not how companies should deal with privacy.
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.
>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.
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
[1] https://github.com/stripe/react-stripe-elements/issues/99#is...
[2] https://mtlynch.io/stripe-recording-its-customers/#reporting...
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.
"Hey, you're doing something that may be illegal." - "Yeah, we know"
That's an issue. If they'd say "but the color of our signup button has a higher priority", that's an even larger issue.
>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.
I agree that Stripe of course can't give the same time and attention to every support request that they give to issues that bubble to the top of HN. The parent commenter was saying that PayPal didn't escalate as well as Stripe, and I was pointing out that Stripe didn't prioritize this either until it got attention.
But one point I'd like to add is that not all issues are equal. If there's an issue like an account takeover vulnerability, I think most people would agree that something is seriously wrong if a company only gives it top priority when it receives publicity. And then there are minor issues like "why don't you support dark mode?" I think it's fine if dark mode got regular priority and then got bumped up when there was a massive outcry where thousands of users said they were desperate for dark mode.
When people criticize a company for only addressing an issue when it reaches the front page of HN, the argument is that the company's internal process for prioritizing the issue failed. But this criticism is always going to be subjective because everyone has their own particular priorities of what should be fixed and at what priority. It's also limited in that commenters have no insight into the competing priorities within the company.
I think it is appropriate to criticize a company for failing to give issues proper priority until they get more attention, but I think you're right that we should be doing it with an appropriate degree of humility, recognizing that prioritization is subjective and we don't have all the information.
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.
https://mtlynch.io/stripe-recording-its-customers/
https://news.ycombinator.com/item?id=22936818
As always, feedback and questions are welcome.
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.
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?
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.
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...
>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.
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.
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.
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.
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?
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.
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.
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_(informat...
In contrast, Stripe collects also data from webpages that are not payment pages.
https://webmasters.googleblog.com/2018/10/introducing-recapt...
Like recaptcha, whether the Stripe code is included on a given page is solely up to the author of that page.
While I may tend to agree with OP's requests for increased transparency, that desire does not lend its support to other claims about how Stripe's code works. Putting it on every page is not required. Unless I am mistaken, putting it on every page is not even suggested by Stripe. Why anyone would put Stripe or any other third-party code on every page indiscriminately, without considering whether it was necessary, is beyond me.
https://stripe.com/docs/js/including
> Include the Stripe.js script on each page of your site—it should always be loaded directly from https://js.stripe.com, rather than included in a bundle or hosted yourself.
> To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect suspicious behavior that may be indicative of fraud as customers browse your website.
"reCAPTCHA works best when it has the most context about interactions with your site, which comes from seeing both legitimate and abusive behavior. For this reason, we recommend including reCAPTCHA verification on forms or actions as well as in the background of pages for analytics."
When you say reCaptcha doesn't capture user data are you lying? Have you actually implemented any of this and tried to fight fraud. I ask because you and the original author are making a lot of big claims and ill intent assumptions that literally ANYONE dealing with large scale fraud attempts would see through immediately.
Seriously, everyone else is sticking all sorts of beacons on websites for this - that's currently how it is being done.
That does not include:
- analytics by companies based on interest
- advertising based on monthly spend