26 ms·

Stripe records user movements on its customers' websites

1134 points by mtlynch 7y ago

somishere 7y ago
For those that are working with SPAs or similar and are not overly affected by fraud, I've put together a simple example showing how to sandbox Stripe.js code and unload it when you're done. No secondary domains, no reverse engineering of the Stripe.js library. It also maintains a reasonable level of trust in Stripe, who deserve it. https://codepen.io/theprojectsomething/full/ExVNEoZ https://codepen.io/theprojectsomething/full/ExVNEoZ
mtlynch 7y ago
Author here. Happy to answer any questions or hear feedback about this post.
- swyx 7y ago
  title is a little sensationalist, i find that a little hard to forgive :) it is well understood any anti fraud system records movement. how does your analysis fare on Google's reCAPTCHA v3? or rather the actual issue, the x00,000's of sites that actually record movement for product research and, yes, marketing? sensationalizing this issue on stripe, which is a probable good actor, doesn't help the sites and web users deal with the real bad actors. but its a well written article with solid recommendations so kudos for that.
  - mtlynch 7y ago
    > it is well understood any anti fraud system records movement. I don't think that's true of every anti-fraud system. I've integrated PayPal checkouts by pasting some HTML on a single page and that works fine. I'm sure it works better if you can record movement, but that doesn't necessarily mean I'm okay with handing over so much data to achieve those gains. > how does your analysis fare on Google's reCAPTCHA v3? I haven't looked too carefully at it, but my understanding is that reCAPTCHA 3 works if you place it on a single page. If reCAPTCHA is directing users to place it on every page of their app and not making it clear that Google's tracking it, I'd have a problem with that as well. From a cursory look at Google's documentation, they don't seem to be doing that.
  - falcolas 7y ago
    No, it’s not well understood. Perhaps you, and people in your direct field understand this, but does an average web developer who is reading Stripe’s documentation? Does a consumer? Silent, given the lack of documentation or notification, is 100% appropriate here.
    - lowan12 7y ago
      I mean, the docs literally spell this out, so I'm not sure how much you or the author of the article wants their hand held: > To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website. https://stripe.com/docs/js https://stripe.com/docs/js
  - deleted 7y ago
    [deleted]
  - dang 7y ago
    We've changed the title - see https://news.ycombinator.com/item?id=22937739 https://news.ycombinator.com/item?id=22937739
    - swyx 7y ago
      we love you dang
- TAForObvReasons 7y ago
  Have you tried sequestering the payment logistics to a separate domain or subdomain? If you had a pay._____.com that processed payments using Stripe.js, and that redirected back to app._____.com (which would not be using stripe.js), would tracking continue into your app pages? EDIT: didn't expect this to be so controversial (6 downvotes!)
  - mtlynch 7y ago
    That was one of the solutions I considered. I believe that would successfully limit Stripe's tracking, but it's just logistically complicated to stand up a whole second app just to serve one page and manage state between the payment app and my main app.
    - somishere 7y ago
      Could you simply use an iframe with a sandbox attribute? Idea being you dynamically create an iframe, fill it with content (styles, postmessage scripts, what have you), then dynamically set a semi-restrictive sandbox before loading Stripe's library. When you're done (i.e. have a payment token in the parent) just remove the iframe. This way everything Stripe related is sandboxed and the script is unloaded as soon as you're finished with it. Good chance I'm missing something, or there's some kind of protections in place around this. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
      - mtlynch 7y ago
        That was another solution I considered. I think that would work, but it seemed expensive to implement. I believe it would still require me to host a separate copy of my app or a standalone app that handles just payments. Stripe also creates its own child iframe for displaying payment UI, so at that point, my app would look like: Main app My sandboxed iframe Stripe's iframe So managing all the bubbling up and down of messages felt like it was going to be complicated. Limiting Stripe to a single page and forcing the new HTTP requests to unload it is a bit hackier, but is really simple to implement. You can see it in the blog post - I only had to add ~5 lines of extra code to my app to make it work.
- tomashertus 7y ago
  This is a common practice for anti-fraud detection systems. The whole article is sensationalistic. You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.).
  - mtlynch 7y ago
    Thanks for reading! > This is a common practice for anti-fraud detection systems... You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.). I respectfully disagree. My bank tracks my movement on their own website. They don't track movement on other businesses' websites. I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page. The fact that JS library runs on every page and sends data back to Stripe, even before the app calls the API, is unexpected. I believe that Stripe should, at the very least, make this more obvious to integrators and, ideally, give site owners the ability to limit what data Stripe collects.
    - brunoTbear 7y ago
      You may not be aware of how many banks/airlines/ticket websites have outsourced their fraud fighting to solutions like Shape Security, or Sift (Science). Web-wide tracking via cookies is a reasonable and widespread technique for fighting fraud. Given your background I'd imagine you'd be aware of this.
      - mtlynch 7y ago
        > You may not be aware of how many banks/airlines/ticket websites have outsourced their fraud fighting to solutions like Shape Security, or Sift (Science). Web-wide tracking via cookies is a reasonable and widespread technique for fighting fraud. I view that as a different situation. If a bank/airline/ticketer outsources fraud to a third party, there's presumably an informed exchange of "we'll let you run JS on every page on our website and suck up whatever information you want if you help us detect fraud." In the case of Stripe, I don't believe they're clear with client applications that they're collecting information from every page of an app. I think most developers integrate with Stripe so they can accept payment on one or two pages and probably don't expect Stripe to be collecting the level of data they're reporting back to Stripe servers.
- brunoTbear 7y ago
  It's not super clear to me what harms you've identified here. Tracking mouse movements is a very common way to separate human users from automated fraud, and tracking page views is a relatively common way of identifying normal navigation of a website (homepage-->click on link to search-->click on search results-->click on product reviews-->click on buy) vs fraud navigation (open product page directly-->click on buy). This kind of anti-fraud has existed since the Silvertail days. Additionally, the Stripe cookie can reasonably be read as a way to reduce false positives: if you've purchased from a dozen stripe merchants with no chargebacks and they see you in the same browser with the same payment method, you're probably good to go. The user benefits from having fewer charges declined, and from their goods being less expensive (due to lower shrink for their merchant). One great thing about Stripe is their extraordinary transparency. The fact that the stripe.js payload is sent in ~cleartext is either a sign that their eng team was unwilling to roll their own encryption, didn't feel it was necessary, or consciously chose to make it visible so curious users can understand what's going on. I suspect their fraud solution doesn't rely on these being unobserved by bad guys. I am surprised that it's not necessary to include some tamper-evident field though. For what it's worth, a post to login to aa.com includes this spectacularly obscured blob of who knows what. Would be interesting to know how much of my personal data got hoovered up here, but you won't get clickbait upvotes on HN by going after someone _less_ reputable than Stripe. X-6LdxA4pr-a: 6eta-yIqpITGjyIefMI7BLhyY6Km5cM_Y7j0t6yyo4MA4ih7jsy8=4-9MsInBvm36VNvPpZQ1AT9BLMCIihQx7-bZONZNCkleLk76Wh9HOkBR5wuPvy1BcKvj8Imtik9BnZQRATho7TXrAgGrGZwcyZZr2TXtqYN5Dk01eoWRC3ZKxLzfpC_iXMvNselNmhvj6Kntco7rXkLMm-8t4AFYmnR5XgZoahho9_F6s-bMLT8NmQuNoYABsM7YnFU1e67YsxaPimKHcMF5Hk8o3Fuf_7NoAh6jCcf5oFxrXClB3zWBX9wBvhXaXt1fiNajnZvNnNSjy=ajQ_wNcFxiphY=Ak6PXQe_4ImRrNnRo5GgZ-pRczZkALsR_jwjX3NaXyCoAbFR=9WNsE3toTKo9rZrX_GjskvGMIPrZNNYsr6PXyhYQ_9t_ZmaMIGo2Im_s8PBZkul9k9RZAtPsMutcK1GoSWtrFCtHbbj8-S=HyhMs54R8Fl=2-WYSY9wcoZHLTak9_zfoku_5h2BFhzVgGhOgy9j4F9PVh6YhFFwobuh6tC6cM0Gs22Rg-P5Gt6oHBF=Ana6OQ1BQ8bf7y0rX2x1ACqg46Gbl6V5pK8rX=2=96Hrs6_TGQZBl-lrVhujp20=JGZPXTbYmrZBXMmGXI2NN5NPXY5BNmStph9M4PK4e-zqX_CGrh6iMMl32tCYL-2BcgYr4KFjmLWbZMK6OR1RqQ76mh1Bzt25X-9B_yaicyvbAMur9Y4c6B7rGqZBXMvcyIv6AqYbXjGOOhhr=tmtpC7RMIh=3FvRgk7repW5XIMhzoPBXEYBxMh54MxioTGMs3K-ZqPB4I6qkmWoAkXrUAmqQM2rcoFPsMVhsuZjyIFYskzRckQ6WhmSszZNaFP6QFCBXIk397PT4yF=4Izfuknf5NGMghGRAkz-gQl1xy8B4tC=QrZBsPwrWKhrLg3oA-lV7YZBnFqB36Z-pNG1qq7Rc_vBXkFtzFlBpN4YyosHNw9tQVWEsyU=3t9oJQf54GPjiy91x7ZtM==_xnZjyYatAhKiVKD-QgJbQIvPx8FHQ3FjQh86HmFr2IFSnmPRZT964Y7r2=PaLCvfoMs1XF_tph0-5Fn6c2Fwsy9HsMzBvNGo3mZPmRm5A6aNQ2XjnYN-X5KP7AWBnF1pAyCjnZNBA-wBsMlSQBFRX54tsF28zhvRDSWtfYNPeZ2j--2rQyaBsyeNeTnn02L6Cjaq437Ph-vM68sPWCWr4MuPXK8Rg-aYLkl_4ZvtiYZ6AOg6ahoNNIuBLMyjMTxtMCagHYNtVhCVQIojjkwjmlMqzya-HjuT4QLpzRwtphLxQjFPNkoBzTbrPbPvl-lSVhlRlhC=Akofr77Bs0C57N_r422gAqhON3PrXGsico7=AhlcL-6PLk26x3WPy8htgIvt5mF57Q_5esF6imK5gQZBXM8_vh1rXqLrcyCtOkPt83KfgxGo7kujOhkNLnWPNNwcmYZo2rYPZbh1xILrcx7HsM0N6katLTm6c9atX29fMrAYOLuxut8RGUWtikC9cy8o=hLPqta6vyahVICSo-eBQMkMNyarWhQtMChig-SKOh9p4MPHmn7YsCuTAgZ9VEZtM54YmkYBLkuqikzjQoZ-syFnHTmbXYKM3FKUcy7Hskm9vhGSoMbsekHYLocm7QZ1zN7MLZTgZtLR8ZNaQ0Ctc9ZBEuSrAO0NyMaKWFyPph8_4MvBzy9jNwwjLbSRokmYObPNLm7gEk_WZThhNAFjLTuqvsDrHN61eTFjyr1jLklG8-vb0-aybYPYOt5L465GXt2acM0jNNQOy=7=97V=skvtX-yHLTG6vhF59oP=s2viMIlQncWNpK9tXCCjsICr2r=YQM0ffkQ5gT9iiSWBsxGRiQhBQAXfrY=TonV66FhNs-9-ckC6sMCBN53suhqH62s6xIghsMWj7R_6cCRteTvn45aBcI9=43WT4F8RxtlbekQYs6ZRenFjskeNsyzYYNNjLMMPcIla-PZHmb7g9-0R9g_iQ-vrC8PBWhvB=UPBMrQr4klRrMCR5rRKnFCGsy91zFvOyhaPXqVo9oTrHLVpoMF6OY766kPtC=_tMhWHsn7BqyuB4IyPik9tMtpwcy8GXcW6vR_jL6AGCIuYVhajLhCbvk9imglHVVJjsM0547V5sbW=6G7PhMGBG6Zfc-lBO_gRrklRMIFRZTmB3FvRckw-LN7qoXWtqkCBVNZrx-gcV=QGo59PgK_T9BZ6x67NsxZj6_yoJYhfcM0HsKCtXgZ-omzYNN1PLkuB9_br4MGg96ZHm77BVZ_5qL76eMaioyFYmToiCIlo9y9RfkFrCC4MqNIH86ZPX-8GeZ6TcIVrXbNfjYvtikGhQMCo9KGHVPNGvQZRgjhHSbL-LyVjNjur4nstoYVjsML-mga69gaiMMa=sjWfMk7-LTGtrPw5ETYjo6ZaXokiiN7BAFa=aHWjOmZic-JhX=GR2Izhlt4jnGGPL-05J2FtVha-4-FRAm7rehFRq-ABS2PNsqWPeQgcAkb5ojo59MGccM1ruVN-x_hsLk7ez6mVeTxNcLLBQK4=7YVMsGoHszFPsGhjyIPTrmPc8FUBzQ2Ys2hGehxroonf7jCfXFCYssUYsgNRfkltimVo4=7c5gBtoha-WmZNc2zTOhuQsMCrvb-6qb7OIzLbFNZtQI9TcTltZU7eg3B-mkh6sM554MChNpWtsR9LjFCjWh1o4MMYyIyjpVWtsIRPWxQ1lFC=aNaMJh8YmywVeo7YQ7Po2ZlRAkFm4MuhmzatgM6SsCq5X-lYNh9HObWBsoFrXENNXyV6lhh6ATu6sWWR3WW6g=6oJhwqzY1r6CwtXoZHQCm58-aGyIoo9-7QLkCRfkCMs=Z68-2PlnVtpN76mkur96ZScC0fc22tMIC37b7BsoVtsQv5Lk2tqgl_Qg5jMICoGhk5GhqqZqgrxMwtXy2pNgZRpkojQGtYLbSB4C8PskCBA5vtMN7rehlBxLJtxMmo9eWB3FKo=YJNL-CreTIjNTCR9I9NSuYGsM9B9hz5GT9RqICBlz7jOhFVlB0-cyG5A-uTiyxI5J1PxeHMsPQnDmDts=nq6jut52MrCgV=7M2gxmyYsgYR51Qg7M6-WNaBs0C6LkaRX5ZTGzPBGmZ-cp5=4G_M49PjxG_=ZTCp6m7tihXfqkXtfOkgXQNBVhaR3z7rc7Wg9j8=s2_T0twtiYkhs-UH--a6sxOfOmVjQMCBcyWTMbktrb3GCkCRphlBzF9RcYQML-9tphyBWhFOXT9PWCC=aK_YsMpELkCjg3PRxMzNAbnOmTwfc3Yr4PZNXCgG8-m6x0_q-kpBsYVHLTvTM=NHnncLsLVqmkGtA-XbWCFjpmhYnmVToTg-LbFR9yltsMFBXF9rA5eqsgPR5LZOpZAtgNUSQ9=-g_GYLk0g967-=ZlaVh0icM2rs_FhG5N1s2-6s0LB43715MyNVxGBc9ZTGFXR7hkr7F9fcIloGh9YnF6Rih960LWYNjp_XIFP6FPjq=_tctL=4MKNOyetekCM3=PBeb7BcKgoah1jMIvjyFFBAT66gklrfk8PXI8o4G4rWEFM6gG5o5AyAZZNsKwYLbWfoYZB991BHymB4MqBLT8oJkOt4yaReFCtoTzMgnZNLNSYLTetAMgtcC-mvhbBsK66X9ZNOy0BS0w6Ow4NLqFtiwK5zNhbaz7o4_aaqj1jLykBeMVRgyxr4FRy7CwB4RhBahgjmklafkkrzbVpLFoM6TqgAMwyXeNBoYStVNZtcTh5XMlr=bPPLTl=4=hRc2xrsA-jX2Wfn-ltOVLrATCo2jijVh9BokuYmMaa4turX6iB6B5o3nPBcyhjsKbAphuYsFuNeqZrLMzTcM9BXTvR4LPTahCjLThfMh8t8CXMsFh=-wqta87BC3Ztcyv=45bSikeBihag92vB8FwfctK54IwPLb7BVBgjsyPYLklSo-x1L5vGBEKxyTw6LylPcIy=HLWj6UDNNhAjyI8b4e71XXsVqyFRXMp=_kaPH_0tSNL6QgEo4MzM4-vRrkKPrFho4kCPQj9NLkacntlBrNRo4wzrA5_6cyaByy9jy-6pAtCqgPwPNUbiLqaB9xDML5Y4sTC-cPvBsPZjsM9PxzZ=4gAY-BPPxM8jLxARGyR=9n7T4xZrXj8-4eKB977bHhopct9PoTaqoTCPX5IBLThNjjxR4_lhs7N
Lukesys 7y ago
I'm just waiting on Patrick Collison to respond to you and put you in your place!
- mtlynch 7y ago
  Me too!
  - rogerkirkness 7y ago
    See above.
- deleted 7y ago
  [deleted]
pc 7y ago
Stripe cofounder here. The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative. This data has never been, would never be, and will never be sold/rented/etc. to advertisers. Stripe.js collects this data only for fraud prevention -- it helps us detect bots who try to defraud businesses that use Stripe. (CAPTCHAs use similar techniques but result in more UI friction.) Stripe.js is part of the ML stack that helps us stop literally millions of fraudulent payments per day and techniques like this help us block fraud more effectively than almost anything else on the market. Businesses that use Stripe would lose a lot more money if it didn't exist. We see this directly: some businesses don't use Stripe.js and they are often suddenly and unpleasantly surprised when attacked by sophisticated fraud rings. If you don't want to use Stripe.js, you definitely don't have to (or you can include it only on a minimal checkout page) -- it just depends how much PCI burden and fraud risk you'd like to take on. We will immediately clarify the ToS language that makes this ambiguous. We'll also put up a clearer page about Stripe.js's fraud prevention. (Updated to add: further down in this thread, fillskills writes[1]: "As someone who saw this first hand, Stripe’s fraud detection really works. Fraudulent transactions went down from ~2% to under 0.5% on hundreds of thousands of transactions per month. And it very likely saved our business at a very critical phase." This is what we're aiming for (and up against) with Stripe Radar and Stripe.js, and why we work on these technologies.) [1] https://news.ycombinator.com/item?id=22938141 https://news.ycombinator.com/item?id=22938141
- kelvin0 7y ago
  From my naive perspective, if the CC or other provider validate the customer's credentials all is good and you get paid. Integration of a payment method seems fairly simple and straightforward (I'm not a web dev). I don't really know about the types of fraud that are possible and what a Saas should be prepared for. Question: what are the typical fraudulent activities and their symptoms?
- Lukesys 7y ago
  Dude, you are a machine!
- sam1r 7y ago
  In other words, it’s useful data for them to collect as a whole..
voz_ 7y ago
"Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn? Also: `The Stripe library generates a new request like this every time a user views a new page in my app.` In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?
- mtlynch 7y ago
  Thanks for reading! > "Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn? I struggled a lot with the title, as I didn't want to project intention onto Stripe. That said, the behavior is pretty subtle. They don't disclose it in the npm package or the JS documentation. Other API calls initiated by your app show up in your Stripe dashboard, but these ones don't appear anywhere. You can only discover them by inspecting HTTP traffic. > In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael? I'm having trouble understanding this. Assuming you're being sincere: I can't possibly know the side effects of every piece of code in my app. Assuming you're being sarcastic: I'm not sure what your point is. Since I don't 100% understand every dependency in my app, I have no grounds to be bothered when one of my dependencies does something that violates my expectations?
  - voz_ 7y ago
    > I can't possibly know the side effects of every piece of code in my app. This is what i wrong with development today. Everyone just shoves a bunch of npm packages and libs into their bloated site and is then surprised when it behaves in ways you didnt expect? Imagine if everything was built with this level of carelessness!
    - gruez 7y ago
      Why derail this discussion into a rant about supply chain attacks in the javascript ecosystem?
cordite 7y ago
This is kinda common. Events with other anti-fraud providers are similar, it's a black box to the outside world that figures out what's normal and what is risky.
- notRobot 7y ago
  It being common practice doesn't make it okay.
  - cordite 7y ago
    To defend against credit card fraud in an automated world, it’s kinda the only thing we got: an automated risk assessment.
    - frei 7y ago
      That's true, but the data collection doesn't have to be this automated. It's a tradeoff for ease-of-use. Everyone used to use Paypal, right? That doesn't track anything on your site in the default flow, but it requires sending the user to paypal.com, where they will have to enter even more information. But at least it doesn't collect mouse movements on all users on non-payment pages.
tdy721 7y ago
How about Visa and MasterCard? I would be more surprised where these profiles didn’t exist.
ScoutOrgo 7y ago
I recently worked on a fraud detection POC with a few vendors in this space and it is common for them to require adding a js snippet to capture info like this. This isn't out of the ordinary behavior.
- neop1x 7y ago
  But this IS wrong!! What if my browser doesn't support javascript? It won't allow me to purchase anything! Why there HAS to be javascript to prevent fraud? That is simply an abuse of programmable functionality which was not made for such purposes. Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?!
  - Shank 7y ago
    > Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?! Whether or not the money is actually safe or not doesn't really matter when the card networks routinely assess penalties that affect the business. Running cards that have transactions that are later disputed, or for having too many disputed transactions in a certain period of time gets you penalized. The card networks do not make consumer protection programs free, and so fraud prevention happens at every layer. It is as much a battle between a vendor and the card network as it is a battle between a vendor and fraudsters.
  - MattGaiser 7y ago
    > What if my browser doesn't support javascript? It won't allow me to purchase anything! Unless you are Alex Jones, it is probably not worth it to redesign your website to accommodate doomsday preppers. I just disabled JS and you can't even sign in to Amazon or eBay without it. Most websites are now heavily built on JS frameworks, so most projects I have worked on would not be meaningfully functional without it. > Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?! No... The reversal doesn't prevent someone from buying something and taking the item. Sure you can reverse the transaction, but then the merchant takes the hit. Credit cards are safe for the consumer because transactions can be reversed and tracked. They are not safe for the merchant.
agwa 7y ago
This is a good reason to use a technique like cperciva's payment iframe: https://www.paymentiframe.com/ https://www.paymentiframe.com/ It lets you use stripe.js (thus getting the PCI compliance benefits) without Stripe being able to spy on your visitors.
- Znafon 7y ago
  While I trust him, how can we be sure that paymentiframe.com starts serving an iframe that steals the credit cards in the future?
  - Kaze404 7y ago
    From the page: > Why should I trust you? > [...] If you're worried about both, consider this a proof-of-concept which you should replicate on your own server (using a separate domain name from the rest of your site).
    - tgtweak 7y ago
      Yeah nobody should be embedding this verbatim to process payments that will fail any pci audit.
- ricardobeat 7y ago
  That is so ridiculously insecure I'm surprised the author has published it without a massive disclaimer. Do NOT use an unknown third-party, without PCI qualification, to whom you have no contractual relationship, in between you and your payment provider.
  - jedberg 7y ago
    It says at both the top and bottom of the page not to trust him, and at the bottom it says to implement it yourself if you care about security. Seems fairly "disclaimed" to me.
jsf01 7y ago
The most effective anti-fraud solution would be a major privacy violation just by the nature of anti-fraud itself. So, since the stripe user is the one being charged for disputes anyway, giving them control over how much more privacy to give up in exchange for better protection is completely obvious. Even if the default is to be extremely pervasive as Stripe’s anti-fraud measures are now, the option to reduce that tracking is a must.
- Ensorceled 7y ago
  Who do you mean as “the stripe user”? As a customer of a website using Stripe, I have very little concern for fraud, MasterCard and Visa protect me quite well. As a website operator who has somebody use a stolen credit card on my site, MC and Visa protect the owner of the stolen credit card quite well. Stripe is protecting both the website operator and the real owner of the credit card.
  - jsf01 7y ago
    The person responsible for paying for the dispute. The user who goes to create an account on stripe.com to allow them to sell stuff on their site.
    - deleted 7y ago
      [deleted]
    - Ensorceled 7y ago
      Having done some anti-fraud work in the past... that is Not something I would turn off for some over wrought privacy concerns. There is a reason for the GDPR exemptions for this.
      - luckylion 7y ago
        What GDPR exemptions are you referring to?
- bastawhiz 7y ago
voiper1 7y ago
>Stripe is getting free data to train its fraud-detection models and potentially selling that information to advertisers. That's ridiculous. It's not getting free data to train it's fraud model, it's getting data to _use_ the fraud model!
- deleted 7y ago
  [deleted]
WesolyKubeczek 7y ago
This is not the only thing that bothers me about Stripe. For example, if you run a Stripe Connect platform, and you set up webhooks to receive some events asynchronously, Stripe will send you all events of the types you select about the accounts connected to your platform, no matter if the events are related to your platform or not. There may be applications which might need to receive all the activity, but in a simple case of a marketplace which allows merchants to sell stuff and collect a small fee, this is a disturbing amount of information. If I were a bad actor, I could silently collect the information about my merchants' activity on the marketplaces of my competitors. Moreover, if your platform has enough merchants, you could track their buyers. Stripe will readily hand over all this information to you. In a charge.succeeded webhook alone, you get quite enough information to fingerprint a customer, and if you use some deduction, you can identify them, too. This sounds like putting a Ring of Power into the Gollum's hand all of a sudden. I'm wondering if the marketplaces should hang a big warning, for privacy reasons, that "this site uses Stripe for payments. Any payment information might be shared with an unknown number of third parties, and there's diddly we can do about this."
- ryneandal 7y ago
  Almost like a...services agreement (https://stripe.com/legal#section_d https://stripe.com/legal#section_d)?
  - WesolyKubeczek 7y ago
    Look, I'm just a random Joe who wants to buy a handmade mug on a marketplace with handmade mugs. I don't even know at any point that this is powered by Stripe. When I buy the mug, lots and lots of PII flies, via the webhook, not only to the marketplace through which I bought the mug, but also to that other place to which my particular seller is connected, maybe they sell handmade Bilbos. And that place which is an aggregator of spaces-to-let. You name it. It's not Stripe per se, it's the unknown number of unknown third parties. And at this point, a wild commenter appears and tells me, the random Joe, that Gotcha!, you should read all that legalese for Stripe! Dammit, should I also fire up the web inspector on each site I visit, just in case they use something I should be privy to the legal terms of? Listen, bub, at no point I (the buyer) and Stripe even enter a contract. I want to buy a fricking mug and I'd just be happy if that information stayed between me and whoever sold that to me.
uncletammy 7y ago
I use stripe.js in a number of my projects but I've never trusted it. Looks like my fears were justified. Instead of loading it on startup, I always load the library as the last step before the checkout flow is initiated. Here is a working example of how to do this for anyone who's curious. https://jsfiddle.net/167ajcbw/ https://jsfiddle.net/167ajcbw/
- mritchie712 7y ago
  no, they weren't. did you read pc's comment (top currently)?
  - uncletammy 7y ago
    "It's okay because 'fraud prevention' " isn't a good enough reason to horde my user's data without their consent. Furthermore, a heartfelt promise from a payment provider to never sell my data means about diddly squat to me.
thunkshift1 7y ago
Whats with these ‘hit jobs’ on tech firms coming up every now and then?
one2know 7y ago
I once complained to a PM about tracker scripts that my company was placing on its own site. They said that the data from the scripts was bringing in $2 million a year and there was nothing they would do.
deleted 7y ago
[deleted]
lasky 7y ago
hairy internet troll here. What’s most interesting to me is that even an immortal software founder such as PC can find themselves in situations where their company has deeply rationalized actions that, to both the general and technically sophisticated public, appear to very plainly egregiously violate basic user privacy rights. Venture Capital is a helluva drug.
TechBro8615 7y ago
Slightly off topic, but does anyone else find customer support emails that start like this to be particularly ingratiating? > Hi Michael, > Thanks for getting in touch. Faith here from Stripe support. > Jumping right in, ... Are those first sentences really necessary? It’s not like the customer expected to have a conversation and you need to apologize for moving directly to the point of the email. At some point I was taught that it’s best to put things like “hope you’re well” or “thanks for getting in touch” at the end of the email, because putting them at the beginning just makes whatever comes after seem extra disingenuous. Eg “Hope you’re well! Just wondering when you’re going to send the signed contract over.” Doesn’t really sound like you care about my well being, does it?Always better to get straight to the point. Anyway, pedantic rant over. Now back to the regularly scheduled pedantic rants.
- bearcobra 7y ago
  In a previous role all front line support were given instructions to add similar information at the start of conversations. Seemed silly until the data showed that customer satisfaction with the support team went up by something like 4% and agent retention went up closer to 10%. If there is an ongoing relationship, I can definitely see the pleasantries seeming fake but in a one time interaction I don't mind them.
  - TechBro8615 7y ago
    Very interesting, especially the agent retention. I suppose feeling like less of a robot boosts morale.
t0astbread 7y ago
There's two ethical questions here: 1) How much data should a payment services provider be allowed to capture for fraud-detection purposes? 2) What should middleware be allowed to do without the end developer's consent? The first one I'm not gonna answer because I'm pretty unhappy with the state of non-cash payments in general and this would turn into a rant. For 2) I think the answer is anything that leaves the process boundaries (or frame in the case of the web) should be explicitly requested by the developer and if it's a long-running task (like mouse movement tracking on a web page) the developer should be able to abort it at any time. If it's associated with any kind of storage that clearly belongs to the developer's app the developer should be able to clear that storage at any time.
- deleted 7y ago
  [deleted]
lucb1e 7y ago
So it's being used for anti-fraud, let's say that's fair. But what if you're accidentally classified as bot or fraudulent? The GDPR allows automated individual decision making in general, but there must (legally) be an option to ask a human for a second opinion. How does that work with Stripe? Relevant text for those who want to know what GDPR says about this: "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2838-1-1 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL... (So one has to prove that it 'significantly' affects you, but I guess e-commerce is commonplace enough that being banned from a common platform could be argued to significantly impact you. But IANAJudge so this is up for interpretation by a real judge.)
dirtnugget 7y ago
As for SPAs it makes a lot of sense to inject the script at the exact page where it’s needed and then eject it after the payment is processed. At least that’s how I deal with these kinds of single-purpose-ja-files.
kabacha 7y ago
If you believe "this data is not going to be sold to anyone" then boy do I have a bridge to sell you. In my 20 years experience I've never heard anyone say "no, we can't sell this because that would be unethical!".
miguelmota 7y ago
> Stripe is getting free data to train its fraud-detection models and potentially selling that information to advertisers. Can the author back up the second claim with any non-speculative information that stripe will actually sell it to advertisers? advertising is not even stripe's business model. Hypothetically any site anywhere can "potentially" use any data they collect to sell to advertisers.
dbuder 7y ago
We promise to use it ethically...that's what everyone says and time and again my data leaks.
m3nu 7y ago
I wasn't very comfortable with integrating either Paypal or Stripe in my app for payments. So I ended up adding it only to the checkout page. Any user who isn't paying never loads their JS and shouldn't have to. Needs a tiny bit more work, but avoids tons of JS. You can also use CSP to only allow selected resources to load and e.g. block trackers, but allow bare-bones payment endpoints.
erynvorn 7y ago
this is really creepy. All these data being collected, analyzed and sold to third parties ...
nijave 7y ago
How is this any different than loss prevention watching you walk around in a store on cctv and taking note in a notebook if you look suspicious? Do people routinely avoid all B&M retail stores?
- mtlynch 7y ago
  If you hire a loss prevention officer to protect your store, you're directing them in how they collect information about your customers and how they handle that data. The closer equivalent would be if I purchased Square point of sale tablets to accept credit card payments in my store, and then Square sent their own loss prevention officers to my store to monitor my customers without telling me about it and kept the data for their own purposes.
  - nijave 7y ago
    What if you hire a 3rd party security contractor (also common)? i.e. rent-a-cop In this case Stripe does tell store owners what they're doing if they would have done due diligence and examined the service more. Either way, not sure why everyone's coming after Stripe instead of the stores that decided to use it
- lowan12 7y ago
  The HN crowd likes to freak out whenever data is being collected...
khiner 7y ago
I used to work for a company that transferred a huge amount of money from tenants to landlords. Fraud is a really big deal in that domain, and we were really excited to update our credit card entry forms to use the newer Stripe Elements forms that include this user behavior tracking, to feed into Stripe radar and in turn use Radar’s api to feed the fraud likelihood data in to our own fraud detection platform. This agent behavior tracking is proudly highlighted in Stripe’s documentation as the feature that it is - they’re not being sneaky about this in any way and this feature is incredibly useful to help companies stop fraudsters from doing serious financial harm. In other words, this is not news. If you could somehow prove that Stripe is selling this data, THAT would be a huge story. But as far as we know their explicit claims that they do not is true. Thanks for your awesome anti-fraud features, Stripe - they helped us help people to pay and accept rent safely.
- curiousgal 7y ago
  Honest question, what exactly do people mean by fraud? How could someone exploit a payment page?
  - amelius 7y ago
    Also, how would fraud detection work in Europe, where there is the GDPR?
    - carstenhag 7y ago
      The GDPR doesn't say "You can't do anything", the tldr of it rather is "the user must be informed and/or you must have their opt-in, then it's allowed"
abunner 7y ago
This is how other companies gather fraud signals as well. If you've ever clicked "I am not a robot", it also works on signals like mouse movements. Stripe is following industry best practices.
- mtlynch 7y ago
  I haven't used reCAPTCHA, but based on my understanding from Google's documentation[0], there are a few differences: 1. reCAPTCHA doesn't send information until you explicitly call their library. Stripe's library immediately begins reporting to data as soon as the script is loaded. 2. reCAPTCHA is explicit in its documentation that it's collecting behavior about your users. Its sole purpose is to track user behavior, so implementers understand that it does this. Stripe's main purpose is to accept payment information, and it is currently not transparent about how it collects user behavior to achieve that. I don't believe that most implementers understand the nature of Stripe's data collection. [0] https://developers.google.com/recaptcha/docs/v3 https://developers.google.com/recaptcha/docs/v3
paulcole 7y ago
> is in the best interests of the user This is why you hire people with empathy who can write to do support. Actually, just hire them for every position.
h3ckr 7y ago
Aren't literally all websites with Google Analytics doing this? I never saw anyone writing about it, lol
gonational 7y ago
Time to add Stripe to uBlock Origin...
sholladay 7y ago
As a Stripe customer, I have to say it is pretty easy to deduce this from their documentation. They recommend loading Stripe.js on every page of your website rather than just the payment form. The given reason is to detect fraud. [1] > To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website. There are also indications on the product page for Stripe Radar and other places where it is obvious they are doing device fingerprinting. I can accept Stripe's explanation given the nature of their product and the effectiveness of Stripe Radar. That said, I think they need to make some changes. First of all, they should lay it out clearly that the tracking is high-resolution and includes mouse movement. Second, the tracking should be disabled by default and more closely tied to the usage of Radar. Most businesses don't need Radar until they reach a certain scale. Stripe could encourage the use of Radar when the account transaction volume reaches a certain size and use that opportunity to explain the benefits of enabling the tracking system. It should be optional, even then, though. 1: https://stripe.com/docs/js https://stripe.com/docs/js
HABytes 7y ago
Honestly, this looks very very standard. Having processed millions of $$$ through Stripe, most of this brings very welcome insight and information that prevented a significant amount of fraud, though sadly not catching all of it. The only way for that to get better is through more tracking. At the end of the day, many are paying for Stripe to protect them and their business, but you can build it yourself, in which case it is a capital investment for you that likely will cost you more than the % charges you have on each transaction. If you don't want that insight, agreed that it likely could be done through a flag, but your suggestion I'd say is likely ideal.
ahupp 7y ago
The thing I don't get about the outrage in this thread is what the actual harm is. Is there any plausible way you could be harmed by someone tracking your mouse movements?
millstone 7y ago
I point at what I read, what I look at; this is just eye tracking. Is there a browser extension that can block this nonsense?
SergeAx 7y ago
Author uses python one-liner to pretty-print JSON struture. There is marvelous MIT-licensed tool "jq" just for that and ton more: https://github.com/stedolan/jq https://github.com/stedolan/jq
panpanna 7y ago
Some of you bringing up ethical and moral issues. But let me raise a totally different issue: what if I am a 100% keyboard person or use a phone with voice commands? Will most my purchases be marked as possibly fraudulent? Will my Amazon packages arrive a week later than anyone elses? And to the bigger question: will we soon live in a world where AI can discriminate against anyone who is slightly different and everyone are okay with that??
- random32840 7y ago
  Probably not, it's just more effort to verify you as legitimate and your baseline behaviour is closer to a robot, meaning when your account gets hijacked, it's more difficult to detect deviance.
latexr 7y ago
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers. What about to companies or people who are not advertisers?
- gonational 7y ago
  @pc - how about an answer to this question? @dang - is there a service or function that allows some kind of notification specifically based on @ mentions?

1134 points by mtlynch 7y ago

For those that are working with SPAs or similar and are not overly affected by fraud, I've put together a simple example showing how to sandbox Stripe.js code and unload it when you're done. No secondary domains, no reverse engineering of the Stripe.js library. It also maintains a reasonable level of trust in Stripe, who deserve it. https://codepen.io/theprojectsomething/full/ExVNEoZ https://codepen.io/theprojectsomething/full/ExVNEoZ

mtlynch 7y ago

Author here. Happy to answer any questions or hear feedback about this post.

swyx 7y ago
title is a little sensationalist, i find that a little hard to forgive :) it is well understood any anti fraud system records movement. how does your analysis fare on Google's reCAPTCHA v3? or rather the actual issue, the x00,000's of sites that actually record movement for product research and, yes, marketing? sensationalizing this issue on stripe, which is a probable good actor, doesn't help the sites and web users deal with the real bad actors. but its a well written article with solid recommendations so kudos for that.
- mtlynch 7y ago
  > it is well understood any anti fraud system records movement. I don't think that's true of every anti-fraud system. I've integrated PayPal checkouts by pasting some HTML on a single page and that works fine. I'm sure it works better if you can record movement, but that doesn't necessarily mean I'm okay with handing over so much data to achieve those gains. > how does your analysis fare on Google's reCAPTCHA v3? I haven't looked too carefully at it, but my understanding is that reCAPTCHA 3 works if you place it on a single page. If reCAPTCHA is directing users to place it on every page of their app and not making it clear that Google's tracking it, I'd have a problem with that as well. From a cursory look at Google's documentation, they don't seem to be doing that.
- falcolas 7y ago
  No, it’s not well understood. Perhaps you, and people in your direct field understand this, but does an average web developer who is reading Stripe’s documentation? Does a consumer? Silent, given the lack of documentation or notification, is 100% appropriate here.
  - lowan12 7y ago
    I mean, the docs literally spell this out, so I'm not sure how much you or the author of the article wants their hand held: > To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website. https://stripe.com/docs/js https://stripe.com/docs/js
- deleted 7y ago
  [deleted]
- dang 7y ago
  We've changed the title - see https://news.ycombinator.com/item?id=22937739 https://news.ycombinator.com/item?id=22937739
  - swyx 7y ago
    we love you dang
TAForObvReasons 7y ago
Have you tried sequestering the payment logistics to a separate domain or subdomain? If you had a pay._____.com that processed payments using Stripe.js, and that redirected back to app._____.com (which would not be using stripe.js), would tracking continue into your app pages? EDIT: didn't expect this to be so controversial (6 downvotes!)
- mtlynch 7y ago
  That was one of the solutions I considered. I believe that would successfully limit Stripe's tracking, but it's just logistically complicated to stand up a whole second app just to serve one page and manage state between the payment app and my main app.
  - somishere 7y ago
    Could you simply use an iframe with a sandbox attribute? Idea being you dynamically create an iframe, fill it with content (styles, postmessage scripts, what have you), then dynamically set a semi-restrictive sandbox before loading Stripe's library. When you're done (i.e. have a payment token in the parent) just remove the iframe. This way everything Stripe related is sandboxed and the script is unloaded as soon as you're finished with it. Good chance I'm missing something, or there's some kind of protections in place around this. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
    - mtlynch 7y ago
      That was another solution I considered. I think that would work, but it seemed expensive to implement. I believe it would still require me to host a separate copy of my app or a standalone app that handles just payments. Stripe also creates its own child iframe for displaying payment UI, so at that point, my app would look like: Main app My sandboxed iframe Stripe's iframe So managing all the bubbling up and down of messages felt like it was going to be complicated. Limiting Stripe to a single page and forcing the new HTTP requests to unload it is a bit hackier, but is really simple to implement. You can see it in the blog post - I only had to add ~5 lines of extra code to my app to make it work.
tomashertus 7y ago
This is a common practice for anti-fraud detection systems. The whole article is sensationalistic. You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.).
- mtlynch 7y ago
  Thanks for reading! > This is a common practice for anti-fraud detection systems... You will see similar techniques used all over the web (your bank website, Ticketmaster, airlines websites, etc.). I respectfully disagree. My bank tracks my movement on their own website. They don't track movement on other businesses' websites. I believe many developers integrate with Stripe expecting that their JS library executes and shares data only on the pages where Stripe UI elements appear on the page. The fact that JS library runs on every page and sends data back to Stripe, even before the app calls the API, is unexpected. I believe that Stripe should, at the very least, make this more obvious to integrators and, ideally, give site owners the ability to limit what data Stripe collects.
  - brunoTbear 7y ago
    You may not be aware of how many banks/airlines/ticket websites have outsourced their fraud fighting to solutions like Shape Security, or Sift (Science). Web-wide tracking via cookies is a reasonable and widespread technique for fighting fraud. Given your background I'd imagine you'd be aware of this.
    - mtlynch 7y ago
      > You may not be aware of how many banks/airlines/ticket websites have outsourced their fraud fighting to solutions like Shape Security, or Sift (Science). Web-wide tracking via cookies is a reasonable and widespread technique for fighting fraud. I view that as a different situation. If a bank/airline/ticketer outsources fraud to a third party, there's presumably an informed exchange of "we'll let you run JS on every page on our website and suck up whatever information you want if you help us detect fraud." In the case of Stripe, I don't believe they're clear with client applications that they're collecting information from every page of an app. I think most developers integrate with Stripe so they can accept payment on one or two pages and probably don't expect Stripe to be collecting the level of data they're reporting back to Stripe servers.
brunoTbear 7y ago
It's not super clear to me what harms you've identified here. Tracking mouse movements is a very common way to separate human users from automated fraud, and tracking page views is a relatively common way of identifying normal navigation of a website (homepage-->click on link to search-->click on search results-->click on product reviews-->click on buy) vs fraud navigation (open product page directly-->click on buy). This kind of anti-fraud has existed since the Silvertail days. Additionally, the Stripe cookie can reasonably be read as a way to reduce false positives: if you've purchased from a dozen stripe merchants with no chargebacks and they see you in the same browser with the same payment method, you're probably good to go. The user benefits from having fewer charges declined, and from their goods being less expensive (due to lower shrink for their merchant). One great thing about Stripe is their extraordinary transparency. The fact that the stripe.js payload is sent in ~cleartext is either a sign that their eng team was unwilling to roll their own encryption, didn't feel it was necessary, or consciously chose to make it visible so curious users can understand what's going on. I suspect their fraud solution doesn't rely on these being unobserved by bad guys. I am surprised that it's not necessary to include some tamper-evident field though. For what it's worth, a post to login to aa.com includes this spectacularly obscured blob of who knows what. Would be interesting to know how much of my personal data got hoovered up here, but you won't get clickbait upvotes on HN by going after someone _less_ reputable than Stripe. X-6LdxA4pr-a: 6eta-yIqpITGjyIefMI7BLhyY6Km5cM_Y7j0t6yyo4MA4ih7jsy8=4-9MsInBvm36VNvPpZQ1AT9BLMCIihQx7-bZONZNCkleLk76Wh9HOkBR5wuPvy1BcKvj8Imtik9BnZQRATho7TXrAgGrGZwcyZZr2TXtqYN5Dk01eoWRC3ZKxLzfpC_iXMvNselNmhvj6Kntco7rXkLMm-8t4AFYmnR5XgZoahho9_F6s-bMLT8NmQuNoYABsM7YnFU1e67YsxaPimKHcMF5Hk8o3Fuf_7NoAh6jCcf5oFxrXClB3zWBX9wBvhXaXt1fiNajnZvNnNSjy=ajQ_wNcFxiphY=Ak6PXQe_4ImRrNnRo5GgZ-pRczZkALsR_jwjX3NaXyCoAbFR=9WNsE3toTKo9rZrX_GjskvGMIPrZNNYsr6PXyhYQ_9t_ZmaMIGo2Im_s8PBZkul9k9RZAtPsMutcK1GoSWtrFCtHbbj8-S=HyhMs54R8Fl=2-WYSY9wcoZHLTak9_zfoku_5h2BFhzVgGhOgy9j4F9PVh6YhFFwobuh6tC6cM0Gs22Rg-P5Gt6oHBF=Ana6OQ1BQ8bf7y0rX2x1ACqg46Gbl6V5pK8rX=2=96Hrs6_TGQZBl-lrVhujp20=JGZPXTbYmrZBXMmGXI2NN5NPXY5BNmStph9M4PK4e-zqX_CGrh6iMMl32tCYL-2BcgYr4KFjmLWbZMK6OR1RqQ76mh1Bzt25X-9B_yaicyvbAMur9Y4c6B7rGqZBXMvcyIv6AqYbXjGOOhhr=tmtpC7RMIh=3FvRgk7repW5XIMhzoPBXEYBxMh54MxioTGMs3K-ZqPB4I6qkmWoAkXrUAmqQM2rcoFPsMVhsuZjyIFYskzRckQ6WhmSszZNaFP6QFCBXIk397PT4yF=4Izfuknf5NGMghGRAkz-gQl1xy8B4tC=QrZBsPwrWKhrLg3oA-lV7YZBnFqB36Z-pNG1qq7Rc_vBXkFtzFlBpN4YyosHNw9tQVWEsyU=3t9oJQf54GPjiy91x7ZtM==_xnZjyYatAhKiVKD-QgJbQIvPx8FHQ3FjQh86HmFr2IFSnmPRZT964Y7r2=PaLCvfoMs1XF_tph0-5Fn6c2Fwsy9HsMzBvNGo3mZPmRm5A6aNQ2XjnYN-X5KP7AWBnF1pAyCjnZNBA-wBsMlSQBFRX54tsF28zhvRDSWtfYNPeZ2j--2rQyaBsyeNeTnn02L6Cjaq437Ph-vM68sPWCWr4MuPXK8Rg-aYLkl_4ZvtiYZ6AOg6ahoNNIuBLMyjMTxtMCagHYNtVhCVQIojjkwjmlMqzya-HjuT4QLpzRwtphLxQjFPNkoBzTbrPbPvl-lSVhlRlhC=Akofr77Bs0C57N_r422gAqhON3PrXGsico7=AhlcL-6PLk26x3WPy8htgIvt5mF57Q_5esF6imK5gQZBXM8_vh1rXqLrcyCtOkPt83KfgxGo7kujOhkNLnWPNNwcmYZo2rYPZbh1xILrcx7HsM0N6katLTm6c9atX29fMrAYOLuxut8RGUWtikC9cy8o=hLPqta6vyahVICSo-eBQMkMNyarWhQtMChig-SKOh9p4MPHmn7YsCuTAgZ9VEZtM54YmkYBLkuqikzjQoZ-syFnHTmbXYKM3FKUcy7Hskm9vhGSoMbsekHYLocm7QZ1zN7MLZTgZtLR8ZNaQ0Ctc9ZBEuSrAO0NyMaKWFyPph8_4MvBzy9jNwwjLbSRokmYObPNLm7gEk_WZThhNAFjLTuqvsDrHN61eTFjyr1jLklG8-vb0-aybYPYOt5L465GXt2acM0jNNQOy=7=97V=skvtX-yHLTG6vhF59oP=s2viMIlQncWNpK9tXCCjsICr2r=YQM0ffkQ5gT9iiSWBsxGRiQhBQAXfrY=TonV66FhNs-9-ckC6sMCBN53suhqH62s6xIghsMWj7R_6cCRteTvn45aBcI9=43WT4F8RxtlbekQYs6ZRenFjskeNsyzYYNNjLMMPcIla-PZHmb7g9-0R9g_iQ-vrC8PBWhvB=UPBMrQr4klRrMCR5rRKnFCGsy91zFvOyhaPXqVo9oTrHLVpoMF6OY766kPtC=_tMhWHsn7BqyuB4IyPik9tMtpwcy8GXcW6vR_jL6AGCIuYVhajLhCbvk9imglHVVJjsM0547V5sbW=6G7PhMGBG6Zfc-lBO_gRrklRMIFRZTmB3FvRckw-LN7qoXWtqkCBVNZrx-gcV=QGo59PgK_T9BZ6x67NsxZj6_yoJYhfcM0HsKCtXgZ-omzYNN1PLkuB9_br4MGg96ZHm77BVZ_5qL76eMaioyFYmToiCIlo9y9RfkFrCC4MqNIH86ZPX-8GeZ6TcIVrXbNfjYvtikGhQMCo9KGHVPNGvQZRgjhHSbL-LyVjNjur4nstoYVjsML-mga69gaiMMa=sjWfMk7-LTGtrPw5ETYjo6ZaXokiiN7BAFa=aHWjOmZic-JhX=GR2Izhlt4jnGGPL-05J2FtVha-4-FRAm7rehFRq-ABS2PNsqWPeQgcAkb5ojo59MGccM1ruVN-x_hsLk7ez6mVeTxNcLLBQK4=7YVMsGoHszFPsGhjyIPTrmPc8FUBzQ2Ys2hGehxroonf7jCfXFCYssUYsgNRfkltimVo4=7c5gBtoha-WmZNc2zTOhuQsMCrvb-6qb7OIzLbFNZtQI9TcTltZU7eg3B-mkh6sM554MChNpWtsR9LjFCjWh1o4MMYyIyjpVWtsIRPWxQ1lFC=aNaMJh8YmywVeo7YQ7Po2ZlRAkFm4MuhmzatgM6SsCq5X-lYNh9HObWBsoFrXENNXyV6lhh6ATu6sWWR3WW6g=6oJhwqzY1r6CwtXoZHQCm58-aGyIoo9-7QLkCRfkCMs=Z68-2PlnVtpN76mkur96ZScC0fc22tMIC37b7BsoVtsQv5Lk2tqgl_Qg5jMICoGhk5GhqqZqgrxMwtXy2pNgZRpkojQGtYLbSB4C8PskCBA5vtMN7rehlBxLJtxMmo9eWB3FKo=YJNL-CreTIjNTCR9I9NSuYGsM9B9hz5GT9RqICBlz7jOhFVlB0-cyG5A-uTiyxI5J1PxeHMsPQnDmDts=nq6jut52MrCgV=7M2gxmyYsgYR51Qg7M6-WNaBs0C6LkaRX5ZTGzPBGmZ-cp5=4G_M49PjxG_=ZTCp6m7tihXfqkXtfOkgXQNBVhaR3z7rc7Wg9j8=s2_T0twtiYkhs-UH--a6sxOfOmVjQMCBcyWTMbktrb3GCkCRphlBzF9RcYQML-9tphyBWhFOXT9PWCC=aK_YsMpELkCjg3PRxMzNAbnOmTwfc3Yr4PZNXCgG8-m6x0_q-kpBsYVHLTvTM=NHnncLsLVqmkGtA-XbWCFjpmhYnmVToTg-LbFR9yltsMFBXF9rA5eqsgPR5LZOpZAtgNUSQ9=-g_GYLk0g967-=ZlaVh0icM2rs_FhG5N1s2-6s0LB43715MyNVxGBc9ZTGFXR7hkr7F9fcIloGh9YnF6Rih960LWYNjp_XIFP6FPjq=_tctL=4MKNOyetekCM3=PBeb7BcKgoah1jMIvjyFFBAT66gklrfk8PXI8o4G4rWEFM6gG5o5AyAZZNsKwYLbWfoYZB991BHymB4MqBLT8oJkOt4yaReFCtoTzMgnZNLNSYLTetAMgtcC-mvhbBsK66X9ZNOy0BS0w6Ow4NLqFtiwK5zNhbaz7o4_aaqj1jLykBeMVRgyxr4FRy7CwB4RhBahgjmklafkkrzbVpLFoM6TqgAMwyXeNBoYStVNZtcTh5XMlr=bPPLTl=4=hRc2xrsA-jX2Wfn-ltOVLrATCo2jijVh9BokuYmMaa4turX6iB6B5o3nPBcyhjsKbAphuYsFuNeqZrLMzTcM9BXTvR4LPTahCjLThfMh8t8CXMsFh=-wqta87BC3Ztcyv=45bSikeBihag92vB8FwfctK54IwPLb7BVBgjsyPYLklSo-x1L5vGBEKxyTw6LylPcIy=HLWj6UDNNhAjyI8b4e71XXsVqyFRXMp=_kaPH_0tSNL6QgEo4MzM4-vRrkKPrFho4kCPQj9NLkacntlBrNRo4wzrA5_6cyaByy9jy-6pAtCqgPwPNUbiLqaB9xDML5Y4sTC-cPvBsPZjsM9PxzZ=4gAY-BPPxM8jLxARGyR=9n7T4xZrXj8-4eKB977bHhopct9PoTaqoTCPX5IBLThNjjxR4_lhs7N

Lukesys 7y ago

I'm just waiting on Patrick Collison to respond to you and put you in your place!

mtlynch 7y ago
Me too!
- rogerkirkness 7y ago
  See above.
deleted 7y ago
[deleted]

pc 7y ago

Stripe cofounder here. The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative. This data has never been, would never be, and will never be sold/rented/etc. to advertisers. Stripe.js collects this data only for fraud prevention -- it helps us detect bots who try to defraud businesses that use Stripe. (CAPTCHAs use similar techniques but result in more UI friction.) Stripe.js is part of the ML stack that helps us stop literally millions of fraudulent payments per day and techniques like this help us block fraud more effectively than almost anything else on the market. Businesses that use Stripe would lose a lot more money if it didn't exist. We see this directly: some businesses don't use Stripe.js and they are often suddenly and unpleasantly surprised when attacked by sophisticated fraud rings. If you don't want to use Stripe.js, you definitely don't have to (or you can include it only on a minimal checkout page) -- it just depends how much PCI burden and fraud risk you'd like to take on. We will immediately clarify the ToS language that makes this ambiguous. We'll also put up a clearer page about Stripe.js's fraud prevention. (Updated to add: further down in this thread, fillskills writes[1]: "As someone who saw this first hand, Stripe’s fraud detection really works. Fraudulent transactions went down from ~2% to under 0.5% on hundreds of thousands of transactions per month. And it very likely saved our business at a very critical phase." This is what we're aiming for (and up against) with Stripe Radar and Stripe.js, and why we work on these technologies.) [1] https://news.ycombinator.com/item?id=22938141 https://news.ycombinator.com/item?id=22938141

kelvin0 7y ago
From my naive perspective, if the CC or other provider validate the customer's credentials all is good and you get paid. Integration of a payment method seems fairly simple and straightforward (I'm not a web dev). I don't really know about the types of fraud that are possible and what a Saas should be prepared for. Question: what are the typical fraudulent activities and their symptoms?
Lukesys 7y ago
Dude, you are a machine!
sam1r 7y ago
In other words, it’s useful data for them to collect as a whole..

voz_ 7y ago

"Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn? Also: `The Stripe library generates a new request like this every time a user views a new page in my app.` In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael?

mtlynch 7y ago
Thanks for reading! > "Stripe is Silently" - can I just say how much I detest clickbait with "silently" in the title? It is purposefully negative, meant to make Stripe look bad. What did you want? A foghorn? I struggled a lot with the title, as I didn't want to project intention onto Stripe. That said, the behavior is pretty subtle. They don't disclose it in the npm package or the JS documentation. Other API calls initiated by your app show up in your Stripe dashboard, but these ones don't appear anywhere. You can only discover them by inspecting HTTP traffic. > In "your" app! How do you not know all the side effects you dependencies may have when before adding them? What else is going in that site, Michael? I'm having trouble understanding this. Assuming you're being sincere: I can't possibly know the side effects of every piece of code in my app. Assuming you're being sarcastic: I'm not sure what your point is. Since I don't 100% understand every dependency in my app, I have no grounds to be bothered when one of my dependencies does something that violates my expectations?
- voz_ 7y ago
  > I can't possibly know the side effects of every piece of code in my app. This is what i wrong with development today. Everyone just shoves a bunch of npm packages and libs into their bloated site and is then surprised when it behaves in ways you didnt expect? Imagine if everything was built with this level of carelessness!
  - gruez 7y ago
    Why derail this discussion into a rant about supply chain attacks in the javascript ecosystem?

cordite 7y ago

This is kinda common. Events with other anti-fraud providers are similar, it's a black box to the outside world that figures out what's normal and what is risky.

notRobot 7y ago
It being common practice doesn't make it okay.
- cordite 7y ago
  To defend against credit card fraud in an automated world, it’s kinda the only thing we got: an automated risk assessment.
  - frei 7y ago
    That's true, but the data collection doesn't have to be this automated. It's a tradeoff for ease-of-use. Everyone used to use Paypal, right? That doesn't track anything on your site in the default flow, but it requires sending the user to paypal.com, where they will have to enter even more information. But at least it doesn't collect mouse movements on all users on non-payment pages.

tdy721 7y ago

How about Visa and MasterCard? I would be more surprised where these profiles didn’t exist.

ScoutOrgo 7y ago

I recently worked on a fraud detection POC with a few vendors in this space and it is common for them to require adding a js snippet to capture info like this. This isn't out of the ordinary behavior.

neop1x 7y ago
But this IS wrong!! What if my browser doesn't support javascript? It won't allow me to purchase anything! Why there HAS to be javascript to prevent fraud? That is simply an abuse of programmable functionality which was not made for such purposes. Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?!
- Shank 7y ago
  > Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?! Whether or not the money is actually safe or not doesn't really matter when the card networks routinely assess penalties that affect the business. Running cards that have transactions that are later disputed, or for having too many disputed transactions in a certain period of time gets you penalized. The card networks do not make consumer protection programs free, and so fraud prevention happens at every layer. It is as much a battle between a vendor and the card network as it is a battle between a vendor and fraudsters.
- MattGaiser 7y ago
  > What if my browser doesn't support javascript? It won't allow me to purchase anything! Unless you are Alex Jones, it is probably not worth it to redesign your website to accommodate doomsday preppers. I just disabled JS and you can't even sign in to Amazon or eBay without it. Most websites are now heavily built on JS frameworks, so most projects I have worked on would not be meaningfully functional without it. > Aren't those credit cards safe because they are electronic and todays transactions can be reversed, tracked and that fiat money are just database rows?! No... The reversal doesn't prevent someone from buying something and taking the item. Sure you can reverse the transaction, but then the merchant takes the hit. Credit cards are safe for the consumer because transactions can be reversed and tracked. They are not safe for the merchant.

agwa 7y ago

This is a good reason to use a technique like cperciva's payment iframe: https://www.paymentiframe.com/ https://www.paymentiframe.com/ It lets you use stripe.js (thus getting the PCI compliance benefits) without Stripe being able to spy on your visitors.

Znafon 7y ago
While I trust him, how can we be sure that paymentiframe.com starts serving an iframe that steals the credit cards in the future?
- Kaze404 7y ago
  From the page: > Why should I trust you? > [...] If you're worried about both, consider this a proof-of-concept which you should replicate on your own server (using a separate domain name from the rest of your site).
  - tgtweak 7y ago
    Yeah nobody should be embedding this verbatim to process payments that will fail any pci audit.
ricardobeat 7y ago
That is so ridiculously insecure I'm surprised the author has published it without a massive disclaimer. Do NOT use an unknown third-party, without PCI qualification, to whom you have no contractual relationship, in between you and your payment provider.
- jedberg 7y ago
  It says at both the top and bottom of the page not to trust him, and at the bottom it says to implement it yourself if you care about security. Seems fairly "disclaimed" to me.

jsf01 7y ago

The most effective anti-fraud solution would be a major privacy violation just by the nature of anti-fraud itself. So, since the stripe user is the one being charged for disputes anyway, giving them control over how much more privacy to give up in exchange for better protection is completely obvious. Even if the default is to be extremely pervasive as Stripe’s anti-fraud measures are now, the option to reduce that tracking is a must.

Ensorceled 7y ago
Who do you mean as “the stripe user”? As a customer of a website using Stripe, I have very little concern for fraud, MasterCard and Visa protect me quite well. As a website operator who has somebody use a stolen credit card on my site, MC and Visa protect the owner of the stolen credit card quite well. Stripe is protecting both the website operator and the real owner of the credit card.
- jsf01 7y ago
  The person responsible for paying for the dispute. The user who goes to create an account on stripe.com to allow them to sell stuff on their site.
  - deleted 7y ago
    [deleted]
  - Ensorceled 7y ago
    Having done some anti-fraud work in the past... that is Not something I would turn off for some over wrought privacy concerns. There is a reason for the GDPR exemptions for this.
    - luckylion 7y ago
      What GDPR exemptions are you referring to?
bastawhiz 7y ago

voiper1 7y ago

>Stripe is getting free data to train its fraud-detection models and potentially selling that information to advertisers. That's ridiculous. It's not getting free data to train it's fraud model, it's getting data to _use_ the fraud model!

deleted 7y ago
[deleted]

WesolyKubeczek 7y ago

This is not the only thing that bothers me about Stripe. For example, if you run a Stripe Connect platform, and you set up webhooks to receive some events asynchronously, Stripe will send you all events of the types you select about the accounts connected to your platform, no matter if the events are related to your platform or not. There may be applications which might need to receive all the activity, but in a simple case of a marketplace which allows merchants to sell stuff and collect a small fee, this is a disturbing amount of information. If I were a bad actor, I could silently collect the information about my merchants' activity on the marketplaces of my competitors. Moreover, if your platform has enough merchants, you could track their buyers. Stripe will readily hand over all this information to you. In a charge.succeeded webhook alone, you get quite enough information to fingerprint a customer, and if you use some deduction, you can identify them, too. This sounds like putting a Ring of Power into the Gollum's hand all of a sudden. I'm wondering if the marketplaces should hang a big warning, for privacy reasons, that "this site uses Stripe for payments. Any payment information might be shared with an unknown number of third parties, and there's diddly we can do about this."

ryneandal 7y ago
Almost like a...services agreement (https://stripe.com/legal#section_d https://stripe.com/legal#section_d)?
- WesolyKubeczek 7y ago
  Look, I'm just a random Joe who wants to buy a handmade mug on a marketplace with handmade mugs. I don't even know at any point that this is powered by Stripe. When I buy the mug, lots and lots of PII flies, via the webhook, not only to the marketplace through which I bought the mug, but also to that other place to which my particular seller is connected, maybe they sell handmade Bilbos. And that place which is an aggregator of spaces-to-let. You name it. It's not Stripe per se, it's the unknown number of unknown third parties. And at this point, a wild commenter appears and tells me, the random Joe, that Gotcha!, you should read all that legalese for Stripe! Dammit, should I also fire up the web inspector on each site I visit, just in case they use something I should be privy to the legal terms of? Listen, bub, at no point I (the buyer) and Stripe even enter a contract. I want to buy a fricking mug and I'd just be happy if that information stayed between me and whoever sold that to me.

uncletammy 7y ago

I use stripe.js in a number of my projects but I've never trusted it. Looks like my fears were justified. Instead of loading it on startup, I always load the library as the last step before the checkout flow is initiated. Here is a working example of how to do this for anyone who's curious. https://jsfiddle.net/167ajcbw/ https://jsfiddle.net/167ajcbw/

mritchie712 7y ago
no, they weren't. did you read pc's comment (top currently)?
- uncletammy 7y ago
  "It's okay because 'fraud prevention' " isn't a good enough reason to horde my user's data without their consent. Furthermore, a heartfelt promise from a payment provider to never sell my data means about diddly squat to me.

thunkshift1 7y ago

Whats with these ‘hit jobs’ on tech firms coming up every now and then?

one2know 7y ago

I once complained to a PM about tracker scripts that my company was placing on its own site. They said that the data from the scripts was bringing in $2 million a year and there was nothing they would do.

deleted 7y ago

[deleted]

lasky 7y ago

hairy internet troll here. What’s most interesting to me is that even an immortal software founder such as PC can find themselves in situations where their company has deeply rationalized actions that, to both the general and technically sophisticated public, appear to very plainly egregiously violate basic user privacy rights. Venture Capital is a helluva drug.

TechBro8615 7y ago

Slightly off topic, but does anyone else find customer support emails that start like this to be particularly ingratiating? > Hi Michael, > Thanks for getting in touch. Faith here from Stripe support. > Jumping right in, ... Are those first sentences really necessary? It’s not like the customer expected to have a conversation and you need to apologize for moving directly to the point of the email. At some point I was taught that it’s best to put things like “hope you’re well” or “thanks for getting in touch” at the end of the email, because putting them at the beginning just makes whatever comes after seem extra disingenuous. Eg “Hope you’re well! Just wondering when you’re going to send the signed contract over.” Doesn’t really sound like you care about my well being, does it?Always better to get straight to the point. Anyway, pedantic rant over. Now back to the regularly scheduled pedantic rants.

bearcobra 7y ago
In a previous role all front line support were given instructions to add similar information at the start of conversations. Seemed silly until the data showed that customer satisfaction with the support team went up by something like 4% and agent retention went up closer to 10%. If there is an ongoing relationship, I can definitely see the pleasantries seeming fake but in a one time interaction I don't mind them.
- TechBro8615 7y ago
  Very interesting, especially the agent retention. I suppose feeling like less of a robot boosts morale.

t0astbread 7y ago

There's two ethical questions here: 1) How much data should a payment services provider be allowed to capture for fraud-detection purposes? 2) What should middleware be allowed to do without the end developer's consent? The first one I'm not gonna answer because I'm pretty unhappy with the state of non-cash payments in general and this would turn into a rant. For 2) I think the answer is anything that leaves the process boundaries (or frame in the case of the web) should be explicitly requested by the developer and if it's a long-running task (like mouse movement tracking on a web page) the developer should be able to abort it at any time. If it's associated with any kind of storage that clearly belongs to the developer's app the developer should be able to clear that storage at any time.

deleted 7y ago
[deleted]

lucb1e 7y ago

So it's being used for anti-fraud, let's say that's fair. But what if you're accidentally classified as bot or fraudulent? The GDPR allows automated individual decision making in general, but there must (legally) be an option to ask a human for a second opinion. How does that work with Stripe? Relevant text for those who want to know what GDPR says about this: "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2838-1-1 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL... (So one has to prove that it 'significantly' affects you, but I guess e-commerce is commonplace enough that being banned from a common platform could be argued to significantly impact you. But IANAJudge so this is up for interpretation by a real judge.)

dirtnugget 7y ago

As for SPAs it makes a lot of sense to inject the script at the exact page where it’s needed and then eject it after the payment is processed. At least that’s how I deal with these kinds of single-purpose-ja-files.

kabacha 7y ago

If you believe "this data is not going to be sold to anyone" then boy do I have a bridge to sell you. In my 20 years experience I've never heard anyone say "no, we can't sell this because that would be unethical!".

miguelmota 7y ago

> Stripe is getting free data to train its fraud-detection models and potentially selling that information to advertisers. Can the author back up the second claim with any non-speculative information that stripe will actually sell it to advertisers? advertising is not even stripe's business model. Hypothetically any site anywhere can "potentially" use any data they collect to sell to advertisers.

dbuder 7y ago

We promise to use it ethically...that's what everyone says and time and again my data leaks.

m3nu 7y ago

I wasn't very comfortable with integrating either Paypal or Stripe in my app for payments. So I ended up adding it only to the checkout page. Any user who isn't paying never loads their JS and shouldn't have to. Needs a tiny bit more work, but avoids tons of JS. You can also use CSP to only allow selected resources to load and e.g. block trackers, but allow bare-bones payment endpoints.

erynvorn 7y ago

this is really creepy. All these data being collected, analyzed and sold to third parties ...

nijave 7y ago

How is this any different than loss prevention watching you walk around in a store on cctv and taking note in a notebook if you look suspicious? Do people routinely avoid all B&M retail stores?

mtlynch 7y ago
If you hire a loss prevention officer to protect your store, you're directing them in how they collect information about your customers and how they handle that data. The closer equivalent would be if I purchased Square point of sale tablets to accept credit card payments in my store, and then Square sent their own loss prevention officers to my store to monitor my customers without telling me about it and kept the data for their own purposes.
- nijave 7y ago
  What if you hire a 3rd party security contractor (also common)? i.e. rent-a-cop In this case Stripe does tell store owners what they're doing if they would have done due diligence and examined the service more. Either way, not sure why everyone's coming after Stripe instead of the stores that decided to use it
lowan12 7y ago
The HN crowd likes to freak out whenever data is being collected...

khiner 7y ago

I used to work for a company that transferred a huge amount of money from tenants to landlords. Fraud is a really big deal in that domain, and we were really excited to update our credit card entry forms to use the newer Stripe Elements forms that include this user behavior tracking, to feed into Stripe radar and in turn use Radar’s api to feed the fraud likelihood data in to our own fraud detection platform. This agent behavior tracking is proudly highlighted in Stripe’s documentation as the feature that it is - they’re not being sneaky about this in any way and this feature is incredibly useful to help companies stop fraudsters from doing serious financial harm. In other words, this is not news. If you could somehow prove that Stripe is selling this data, THAT would be a huge story. But as far as we know their explicit claims that they do not is true. Thanks for your awesome anti-fraud features, Stripe - they helped us help people to pay and accept rent safely.

curiousgal 7y ago
Honest question, what exactly do people mean by fraud? How could someone exploit a payment page?
- amelius 7y ago
  Also, how would fraud detection work in Europe, where there is the GDPR?
  - carstenhag 7y ago
    The GDPR doesn't say "You can't do anything", the tldr of it rather is "the user must be informed and/or you must have their opt-in, then it's allowed"

abunner 7y ago

This is how other companies gather fraud signals as well. If you've ever clicked "I am not a robot", it also works on signals like mouse movements. Stripe is following industry best practices.

mtlynch 7y ago
I haven't used reCAPTCHA, but based on my understanding from Google's documentation[0], there are a few differences: 1. reCAPTCHA doesn't send information until you explicitly call their library. Stripe's library immediately begins reporting to data as soon as the script is loaded. 2. reCAPTCHA is explicit in its documentation that it's collecting behavior about your users. Its sole purpose is to track user behavior, so implementers understand that it does this. Stripe's main purpose is to accept payment information, and it is currently not transparent about how it collects user behavior to achieve that. I don't believe that most implementers understand the nature of Stripe's data collection. [0] https://developers.google.com/recaptcha/docs/v3 https://developers.google.com/recaptcha/docs/v3

paulcole 7y ago

> is in the best interests of the user This is why you hire people with empathy who can write to do support. Actually, just hire them for every position.

h3ckr 7y ago

Aren't literally all websites with Google Analytics doing this? I never saw anyone writing about it, lol

gonational 7y ago

Time to add Stripe to uBlock Origin...

sholladay 7y ago

As a Stripe customer, I have to say it is pretty easy to deduce this from their documentation. They recommend loading Stripe.js on every page of your website rather than just the payment form. The given reason is to detect fraud. [1] > To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website. There are also indications on the product page for Stripe Radar and other places where it is obvious they are doing device fingerprinting. I can accept Stripe's explanation given the nature of their product and the effectiveness of Stripe Radar. That said, I think they need to make some changes. First of all, they should lay it out clearly that the tracking is high-resolution and includes mouse movement. Second, the tracking should be disabled by default and more closely tied to the usage of Radar. Most businesses don't need Radar until they reach a certain scale. Stripe could encourage the use of Radar when the account transaction volume reaches a certain size and use that opportunity to explain the benefits of enabling the tracking system. It should be optional, even then, though. 1: https://stripe.com/docs/js https://stripe.com/docs/js

HABytes 7y ago

Honestly, this looks very very standard. Having processed millions of $$$ through Stripe, most of this brings very welcome insight and information that prevented a significant amount of fraud, though sadly not catching all of it. The only way for that to get better is through more tracking. At the end of the day, many are paying for Stripe to protect them and their business, but you can build it yourself, in which case it is a capital investment for you that likely will cost you more than the % charges you have on each transaction. If you don't want that insight, agreed that it likely could be done through a flag, but your suggestion I'd say is likely ideal.

ahupp 7y ago

The thing I don't get about the outrage in this thread is what the actual harm is. Is there any plausible way you could be harmed by someone tracking your mouse movements?

millstone 7y ago

I point at what I read, what I look at; this is just eye tracking. Is there a browser extension that can block this nonsense?

SergeAx 7y ago

Author uses python one-liner to pretty-print JSON struture. There is marvelous MIT-licensed tool "jq" just for that and ton more: https://github.com/stedolan/jq https://github.com/stedolan/jq

panpanna 7y ago

Some of you bringing up ethical and moral issues. But let me raise a totally different issue: what if I am a 100% keyboard person or use a phone with voice commands? Will most my purchases be marked as possibly fraudulent? Will my Amazon packages arrive a week later than anyone elses? And to the bigger question: will we soon live in a world where AI can discriminate against anyone who is slightly different and everyone are okay with that??

random32840 7y ago
Probably not, it's just more effort to verify you as legitimate and your baseline behaviour is closer to a robot, meaning when your account gets hijacked, it's more difficult to detect deviance.

latexr 7y ago

> This data has never been, would never be, and will never be sold/rented/etc. to advertisers. What about to companies or people who are not advertisers?

gonational 7y ago
@pc - how about an answer to this question? @dang - is there a service or function that allows some kind of notification specifically based on @ mentions?