[HN Gopher] Stripe responded to my concerns about user tracking
___________________________________________________________________
Stripe responded to my concerns about user tracking
Author : mtlynch
Score : 83 points
Date : 2020-04-30 19:17 UTC (3 hours ago)
(HTM) web link (mtlynch.io)
(TXT) w3m dump (mtlynch.io)
| earpwald wrote:
| Personally I think this has been a good pointer that we need to
| be careful about what we trust third party libraries and
| frameworks to do.
|
| 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.
| amrrs wrote:
| Icymi, Stripe CEO Patrick Collision's response to the original
| thread - https://news.ycombinator.com/item?id=22937303
| adrr wrote:
| "We do not use, share, rent or sell the Personal Data of our
| Users' Customers for interest-based advertising. "
|
| 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.
| mtlynch wrote:
| Hi all. Author here. This is a follow-up from my post last week,
| "Stripe records user movements on its customers' websites":
|
| https://mtlynch.io/stripe-recording-its-customers/
|
| https://news.ycombinator.com/item?id=22936818
|
| As always, feedback and questions are welcome.
| thoraway1010 wrote:
| Do you understand anything more yourself? The need for some of
| these steps for fraud control (vs your assume bad intentions
| initial approach).
| mtlynch wrote:
| 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 wrote:
| > [..] 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 wrote:
| 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 wrote:
| 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...
| akersten wrote:
| I think this part is a little off:
|
| > 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...
| mtlynch wrote:
| Thanks for reading!
|
| 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.
| tptacek wrote:
| This is sort of fair as a statement of principles but I think
| OAuth2 gets you into the same kind of trouble with special
| security status for the fragment.
| amelius wrote:
| Can someone explain what kind of fraud we're talking about?
| draw_down wrote:
| The credit card kind?
| swanson wrote:
| Bots that use stolen cards to make purchases (or use legitimate
| SaaS apps as a vector to test if a card number if valid)
|
| 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.
| amelius wrote:
| But we have other ways of testing for bots. See for example
| Google's Recaptcha (again, example, and not my main point). I
| don't see why we need to give away our personal information
| to yet another big company, especially if the information
| comes from web surfing behavior that has nothing to do with
| payment.
|
| 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.
| ..
| akersten wrote:
| How do you think ReCaptcha (at least ReCaptchaV3) works?
| It's gathers the same kind of "personal" data (mouse
| movements, etc.) to feed an ML model to determine whether
| the client is a robot.
| amelius wrote:
| Yes, but only from the page the captcha is visible on.
|
| In contrast, Stripe collects also data from webpages that
| are not payment pages.
| gpm wrote:
| I don't think this is true anymore?
|
| https://webmasters.googleblog.com/2018/10/introducing-
| recapt...
| loeg wrote:
| And it adds much more user friction, essentially requires
| having a logged in Google account, and may not be as
| accurate. Nevermind that it is outsourcing that
| protection to Google, who _will definitely use your
| personal data to sell targeted ads_. I don 't think
| Stripe's fraud detection behavior is unreasonable here,
| and if you're willing to accept fraud liability, you're
| given the option to disable it (and run your own
| recaptcha, if you like).
| jmull3n wrote:
| I'm not sure Google's Recaptcha is a good example. They use
| the same methods and their business model is using your
| personal data to target ads to you.
| loeg wrote:
| I remain extremely impressed by Stripe and pc's handling of this;
| kudos for taking a somewhat hostile blog post and using it to
| inspire improvement.
| morpheuskafka wrote:
| > Stripe updated their JavaScript library to give clients the
| ability to opt-out of deep data collection. They can now load the
| <script> tag with the advancedFraudSignals=false parameter to
| disable this functionality:
|
| 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?
| jedberg wrote:
| Sure, but that in and of itself would be a major fraud signal.
| If 99% of the traffic from a site is coming into their fraud
| system, and yours isn't, that would be an even bigger fraud
| signal that if it were on.
___________________________________________________________________
(page generated 2020-04-30 23:00 UTC)