Stripe records user movements on its customers' websites

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

Glad to hear you're going to clarify that language in the ToS.

I'm interested to know if you're open to implementing mechanisms that limit what data Stripe collects within my app. I'm happy to help Stripe prevent chargebacks against my app, but I'd like to be in control of what parts of my app's data I hand over to help achieve that rather the current situation which basically grants the library carte blanche to vacuum up whatever data it wants.

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?

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.

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

Ie, CCPA / GDPR says I have the right to see and correct it if I live in one of those jurisdictions.

Having this information up-front and center makes it easier to pass to our Infosec folks + another check in the transparency box.

As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already.

The JS package is really nifty and helpful though, we will be able to standup a one-off late payment page utilizing their checkout flow & one-time payments (server/client - couldn’t expose all the SKUs to folks so had to go that route instead of just client) but the fact we could use Stripe to send the emails with our branding & all we have to really do is pull the payment they owe & create a checkout session to hand-off to Stripe is pretty awesome.

You're right that, if you don't use Stripe.js, PCI compliance will be more work.

And, yes, you can definitely include Stripe.js only on a single page.

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.

Does this mean it "will not be shared with or rented to" advertisers?

Silent, given the lack of documentation or notification, is 100% appropriate here.

I fail to see how it's clickbait. "Silently" conveys to the readers that the recordings were done without the user's consent or knowledge.

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

Way to victim blame.

Are there ways for transparently communicating (verifiable) stats for this claim?

To be clear, I am not saying that your claim is not true but if one thing HN has taught me, it is to always ask for data backing up claims that are tall.

As far as PCI compliance, I was just saying your comment about more work is true depending on your setup w/o using Stripe.js.

In our business we already have our own proprietary fraud models and other PII we secure, so the level of effort to keep PCI compliance for the additional Stripe components is a wash whether or not we use Stripe.js

I totally agree if you're going to use Stripe and you don't have to deal with PCI already in your normal course of business it's a complex area to navigate & using stripe.js is a much smoother path to take.

Basically goes back to basic principles, don't add more stress or work for something outside your core competencies unless necessary & in many cases, I can see where companies should just leverage stripe.js plus the UI utilities as they're well done & save a lot of time.

Big fans of Stripe, even if your ACH rates are significantly more than Wells Fargo or others :P

EDIT: didn't expect this to be so controversial (6 downvotes!)

I also took out "your". That's a standard moderation trick since second-person pronouns in titles tend also to be clickbait: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.

Unless Stripe goes bankrupt, in which case it'll be liquidated along with all the other assets.

To your question about what the data actually includes and what the retention policies are -- we'll put together a summary of this on the page I mentioned in GP.

Is it not the case that sites using this would have to explicitly gain consent from visitors to capture data in advance?

It lets you use stripe.js (thus getting the PCI compliance benefits) without Stripe being able to spy on your visitors.

We more or less do this today, but if you need to setup a new workflow to take payments (one-time or recurring) there's a lot of work already done for you in the Stripe.js ecosystem.

So in our case, to take one-time payments it would've been more work to stand-up the checkout page itself and all of that work behind the scenes. It is much easier to just create a checkout session (basically just hitting the DB to pull the outstanding payment record and creating a stripe customer if one doesn't already exist) and redirect to Stripe's checkout.

The PCI part isn't overstated either, that checkout session lives on Stripe's domain not ours and that's where payment method is collected & stored within Stripe so you're not having to worry about it.

It's pretty nifty, give it a look - https://stripe.com/docs/payments/checkout/one-time

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

I'm normally against this sort of thing (even though everybody does it, it seems like) but in this case, it's clear that this really is "works as intended" at least to me, FWIW.

PECR is a different matter. That's more restrictive but I'm not sure about the exact contours of what's considered "essential."

But, yes, part of the intent here is to enable us to achieve better ROC[1] in our models and to block more fraud while also encumbering fewer false positives. From our testing, it's very clear that these bot-detection techniques do substantially improve the accuracy when compared to other, coarser heuristics.

[1] https://en.wikipedia.org/wiki/Receiver_operating_characteris...

Under both laws, if Stripe claims to be a Processor/Service Provider, then they have an obligation to facilitate sites using Stripe to respond to access requests. But they have no obligation to process those requests themselves. I think CCPA requires they direct you to the actual Controller, but that's one aspect of CCPA that has changed since December.

Until it is.

Google once said their motto was "Don't be evil", look at where they are now.

Careful about those promises.

We particularly edit titles that users have started complaining about: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... Experience has shown that to be the way to minimize off-topic title complaints (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...).

The meaning of the title in this case hasn't changed. Websites don't make noises when they record things.

Edit: out of curiosity, I looked for some other cases where we took out the word 'silently'. Here are some:

https://news.ycombinator.com/item?id=22678471 (changed from "~30% of Android apps silently inspect other apps installed on your smartphone")

https://news.ycombinator.com/item?id=20453115 (changed from "Apple is silently updating Macs * again* to remove Zoom's insecure software")

https://news.ycombinator.com/item?id=16715835 (changed from "Giraffes Silently Slip onto the Endangered Species List")

People have made HN title trackers over the years. My favorite is https://hackernewstitles.netlify.app/ (via https://news.ycombinator.com/item?id=21617016). It's not perfect because it can't distinguish what submitters did from what moderators did, doesn't know what the software changed, etc. But it gives the basic picture.

Given your background I'd imagine you'd be aware of this.

What makes you believe that exactly?

If you include stripe.js on your About page, all bets are off for that page. You can believe all you want here, but you have explicitly included some 3rd js code, so feigning surprise that it gets executed is shallow.

> What makes you believe that exactly?

I've read all the StackOverflow and Github issue posts I can find related to this issue.[0,1,2,3,4] The overall sentiment from developers is that they're surprised and don't want Stripe to send this information. That said, there's obviously a selection bias because the ones who consider it expected behavior don't post.

> If you include stripe.js on your About page, all bets are off for that page. You can believe all you want here, but you have explicitly included some 3rd js code, so feigning surprise that it gets executed is shallow.

Sure, I'm ultimately responsibility for what runs on my site. I believe Stripe is also responsible for clearly disclosing the behavior of their library, and I feel like open critique is an appropriate way to encourage that.

[0] https://github.com/stripe/react-stripe-elements/issues/257

[1] https://github.com/stripe/react-stripe-elements/issues/99

[2] https://stackoverflow.com/questions/45718026/stripe-js-makin...

[3] https://stackoverflow.com/questions/56481458/why-does-stripe...

[4] https://stackoverflow.com/questions/55904278/reduce-network-...

I am always curious about/collecting patterns successful teams leverage for solving problems that I consider important.

Being able to communicate fraudulent payments that Stripe blocks is definitely one of them.

I was being a bit selfish when I asked that, my thought process was like; "Going forward data-collection is going to be scrutinized much more than now and rightfully so. If I ever run a business where we collect data for a very important use case I would want to make sure that we are able to communicate what, why, and how with utmost level of transparency)."

Hope that puts some context to my question, it was a good-faith question. :)

But it turns out to be a pretty good tool for bot detection. That’s why you can now just check a box to verify you’re human (Something about that sentence feels quite dystopian).

I just don’t see the issue with Stripe’s practice here. They have a clear business model, and selling user data could severely undermine that model.

Even if they're blog posts from eng/prod teams that would be a huge favor.

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

I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though.

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.

We're not transparent about enterprise pricing since our costs on any given user are so country/business model/implementation-dependent. It's less that our sales team isn't willing to share the details and more that the models themselves are very complicated and change frequently. (Visa and Mastercard are both making big changes to their pricing this year, for example, and that will change almost all of them.)

Heck, I have a friend who's working on a non-finance web app with <20k MRR, and even at that size he's starting to encounter fraud problems that require tooling to mitigate.

If your app stores any data that may be sellable on the dark web, you are a target.

Then shortly after, Stripe raised pricing on a model I'd just been told was grandfathered in.

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

Can someone give an example of the kind of fraud schemes involving bots that this would stop? What are the bots programmed to do, how does it benefit the owner of the bots and how do you detect it?

Note that collecting consent still doesn't give you carte blanche to collect all the datas. The principle of data minimization still restricts you to only the data you need for the purpose you state when gathering consent.

Hypothetically: I tell a dev to drop a piece of JS on every page that seems related to payments. That dev probably isn’t doing their job super well if they don’t ask me why or wonder why and find out.

I think you imagine HN readers to be dumb. Nothing here is surprising.

I know it’s covid era and we felt good as a community wagging our fingers at Zoom’s naughty FB tracking inclusion. Legitimate concerns there given the advertising business model, and no good reason for zoom to be doing it. This is fundamentally different: the data is for a good purpose with a narrow scope to a good company with a user-positive value creation model.

I believe your princess is in another castle.

We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases.

Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.

Testing for what? That the card hasn't been cancelled or has zero money on it? Can they test for how much money is on the card or anything else useful?

And they need bots because they might have say 1000s of cards from a database hack and most of the cards won't be useful?

What kind of large dollar purchases would someone try to make once a card has been confirmed? Why not let bots attempt lots of large dollar purchases?

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/

Unfortunately, I was not alerted by Stripe, but by a "customer" whose credit card number had been stolen somewhere and who saw on his statement our company name (I'm not sure how, since the attackers don't complete the transaction).

The startup is dormant, so checking the Stripe dashboard isn't part of my daily routine. Or even my monthly routine. Even when it was active, we had only a handful of transactions - it's a niche market.

I contact Stripe customer support only because I thought the email from the "customer" could be a phishing attempt. Stripe customer support saw the logs and helped me roll a new public key. When I asked why I wasn't informed of such impossibly high token creation, the answer was that it wasn't a feature. When I checked the dashboard logs, I found that there had been 75k tokens created in the last 28 days (100% card testing). That's 75k stolen credit cards that my website (and Stripe) have helped to validate - and just in the last 4 weeks.

For all the promise of AI, I'd be happy just to get an alert that 75k tokens were created in four weeks, while exactly 0 (zero) completed transactions in the same period.

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

Perhaps we all have a natural unconscious bias against being "edited" ("you're not in control of me [or the OP]!!"). But seeing the edits over time in the open really makes one appreciate the moderation work. Maybe it's worth making this more official somehow (e.g., adding a footnote in the submission page or to the FAQ) - because like you say, it must surely minimize off-topic discussions as well.

Anyway, thanks for your work!

did you read pc's comment (top currently)?

Consent, as you point out, is only one aspect of this.

It doesn't matter whether "Stripe.js collects this data only for fraud prevention" or if it works in practice. Under CalOPPA [1], Stripe still has to disclose the collection of the data, and (among other things) allow customers to opt out of collection of this data, and allow customers to inspect the data collected. Stripe's privacy policy refers to opt-out and inspection rights about certain data, but AFAICT not this.

[This is not legal advice]

[1] http://leginfo.legislature.ca.gov/faces/codes_displayText.xh...

[2] https://stripe.com/privacy#your-rights-and-choices

These brokers don't want to get involved in any significant fraudulent charges for various reasons.

Is this view conditional on the type of data Stripe is currently collecting or would it apply to any data Stripe collects? Would this be true if Stripe began recording every keystroke in the app and hooked every XHR request to my backend server and sent copies to Stripe?

I agree that Stripe has a sensible reason for using this data. If I started seeing a high rate of chargebacks, I'd consider enabling Stripe on more parts of my site so that Stripe could consume user behavior earlier on to detect fraud.

My issue is that if there's no agreement about what data Stripe is allowed to collect and what their retention policies are, then the implicit agreement is that Stripe can just collect anything it has access to and hold it forever.

As JavaScript running on my page, Stripe.js has access to basically all user data in my app. There are certain types of user data I would not be comfortable sharing with Stripe, even if it improved fraud detection, so I'd like there to be clear limits on what they're gathering.

Its called "pre-auth" or "pre-authorization". It will show up on your statement for up to 48 hours but then will disappear since transaction is not "settled". During this period you would see a descriptor of transaction like NIKE NEW YORK 310XXXX, or if its dynamic/soft descriptor and merchant is utilizing it, it may say your order number and store like NIKE.COM 11-3939329.

More broadly, I assure you that Stripe.js and our fraud prevention technologies are very carefully designed with full compliance with the relevant California (and other) statutes in mind. I’d be happy to connect you with our legal team if you’d like to discuss this in more detail. (I'm patrick@stripe.com.)

I detected a hacked database this way. My credit card (a burner from privacy.com) notifies me of any transaction, including pre-authorizations.

Most likely your customer saw the pre-auth show up.

Can you comment on this part as well? If you collect sensitive data unbeknownst to website owners and users you are most likely in for some trouble (i.e. gdpr)

I think the real issue is that in the U.S. most people's views on things like basic analytics software aren't shaped by reading books on digital privacy or taking classes on privacy law, but rather by some vague cultural memory of the holocaust. It makes it very difficult to have a rational discussion with people.

Responding after being caught is… good, but not as good as not needing to be caught.

https://news.ycombinator.com/item?id=20429573

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

[1] https://stripe.com/privacy

[2] https://stripe.com/cookies-policy/legal

Also, if not advertisers, who will get this information? Make it any “third party”.

One of those can be factual and the other is clearly subjective.

(I have no idea if this is even true, this was just my reading.)

Yep. Also: sale, acquisition, merger, as well as government requests for data, and third party access. Speaking from experience selling a company, it’s difficult to plan for unknown eventualities, and even more difficult to keep any promises about what happens to data you have. The only effective way I know of to guarantee data you have doesn’t get shared is to delete it.

Imagine I mailed you an unsolicited letter and you were legally required to burn it and never say or benefit from what was inside just because I said so. That's the insanity of these "privacy" laws.

The main issue here is that this behavior is enabled by default and hidden. If API would be used like this, I would see no problem:

``` import { ensureUsersAreTrackedForFraudPrevention, loadStripe, } from '@stripe/stripe-js';

ensureUsersAreTrackedForFraudPrevention() ```

Of course, they will never do that, because then many developers would opt-out, and they need the masses to make fraud prevention work.

Based on a plain reading of the law, several things about CalOPPA stand out to me. For one, it's not clear to me that the mouse movements in question qualify as "personally identifiable information". Mouse movements are not a first or last name, physical or email address, SSN, telephone number, or any contact method I am familiar with (maybe you know a way?).

Second, it seems to me that opt-out, right to inspect and update, and more are all contingent upon the data being PII within the scope of CalOPPA. Perhaps you can help me with something I've overlooked that would show me where I've erred?

Further, what do you think the correct legal and ethical way for Stripe to use mouse movement data would be? From your comment I can guess that you believe it should be treated as PII. Is that correct?

My browser is setup to record no history or cookies.

It can be annoying to always have to dismiss the same popups you've dismissed before, but I've never had any issues with online payments or unnecessary captchas, including using stripe.

What am I missing?

Sure! You just have to also handle PCI-DSS.

One of the nasty things I've had to accept about PCI-DSS is that if you think you have a clever hack for getting around it, you probably don't. It's really a remarkable work of standards authoring.

Do NOT use an unknown third-party, without PCI qualification, to whom you have no contractual relationship, in between you and your payment provider.

If I were negotiating for a vendor to collect such an invasive level of personal data about me or my customers, I would insist on accordingly strong protections.

At a minimum there should be clause in your ToS making our consent expressly contingent on you upholding your protection commitments, particularly around what data is collected, who it's shared with, and when it is destroyed or 100% anonymized. It should insist you have contracts containing terms of equal strength in place with any of your vendors, subcontractors, partners, etc. who might conceivably gain access to the sensitive data.

The clause should be written such that the liability follows along to any assigns, heirs, successors, etc, and it should be excluded from any loopholes in other portions of the contract (particularly any blanket ones which allow you to change the ToS without gaining fresh, explicit consent) and preferably free from any limitations of liability.

I'm glad Stripe is taking a responsive approach to the matter and I hope you'll consider this feedback when you revisit your legal agreements.

Not only are they inconvenient, but they're often inaccessible for some users. So I just wanted to say thanks for not going that way, even if the cost we must pay is some theoretical compromise in privacy.

Edit: On thinking about this some more, it occurred to me that by using a user's activities on a web page to determine whether they're a bot committing fraud, you might be inadvertently penalizing users that use assistive technologies, such as a screen reader, voice input, eye-tracking, etc. I haven't had a problem with this when doing a Stripe checkout with a screen reader, but I just wonder if this possible pitfall is something that your team has kept in mind.

What about a face? Fingerprints? Voice? Aren't those identifiable information even though it didn't make your (common sensical) short list? Mouse movements are on the same order of specificity.

Edit: Also not giving legal advice.

Edit2: Please see https://news.ycombinator.com/item?id=22939145

Of course, that also provides an easy way to comply. Don't store mouse movements in a way that ties them to PII under CalOPPA, and you don't meet any criteria.

https://www.researchgate.net/publication/221325920_User_re-a...

https://medium.com/stanford-magazine/your-computer-may-know-...

And this is regarding website owners adding a script that may run on every page of their site; the consent is for the website owners who are using Stripe and deciding how/if to add their script to their pages.

I find it interesting that the one that contemplates authentication requires supervised machine learning and goes on to explicitly state that "analyzing mouse movements alone is not sufficient for a stand-alone user re-authentication system". Taken together, this suggests that a sizable corpus of mouse movement data known to be associated with one user may qualify as PII under some definitions.

Again, thank you for sharing this timely information.

The law in question also requires data to be maintained in personally identifiable form. I am uncertain if a small number of mouse movements is likely to reach this. I do not see how, but that's not a reason why it cannot be so.

If I never see another damned cookie popup I'd be thrilled.

I think I'd find it very easy to like this. Honestly, these aspects of GDPR are great. Things I don't like:

* Not allowed to do "no service without data"

* Consent must be opt-in

Bloody exasperating as a user. At least if they'd set it in my user agent. But the browser guys just sit there like fools pontificating on third-party cookies instead of innovating for once and placing the opt-in / opt-out in the browser.

"Stripe.js collects this data only for fraud prevention -- it helps us detect bots who try to defraud businesses that use Stripe."

The language of the revised ToS could go something like "Stripe shall only use the data for fraud prevention. Stripe shall not permit the data to be used for any other purpose, inlcuding, without limitation, any use that aims to increase customer acquisition or sales of products or services."

The problem with statements like "We only use the data for X" is that this is not a limitation. It is perhaps a representation of what Stripe is doing as of the date of the ToS, however it does not mean Stripe does not have permission to use the data for any other purpose. Further, it only applies to Stripe. Another party could be using the data for some other purpose besides fraud prevention and the statement would still be true. Nothing requires that there be a sale or "rental" for another party to make use of the data.

The problem with statements like "We will never sell/rent/etc. the data to Y" is that it does not prevent Stripe from using the data to help Stripe or other parties to sell products and services. Stripe does not need to sell or rent the data to provide that assistance.

To recap, a ToS should limit how the data can be used. Stating how a company currently uses the data is not a limitation. Stating that a company will not sell or rent the data does not necessarily limit how the data can be used by that company or anyone else.

Facebook does not sell or rent data but their collection of data ultimately results in more advertising on the web, and on Facebook-owned websites. How does that happen. The first problem is the collection of data above and beyond what is needed to fulfill a user's request, i.e., the purpose for which it was collected. Ideally we could stop the unnecessary collection of user data, e.g., through law and regulation, and this would reduce the amount of data we need to worry about. The second problem is that after users "agree" to the collection of data, there are no contractual obligations on the collector over how the data can be used, other than not sharing it.

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.

It's not unexpected when they tell you to include it on every page:

As was in their docs ages ago and still now: https://stripe.com/docs/js

>Including Stripe.js >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 anomalous behavior that may be indicative of fraud as customers browse your website.

... they are asking you to enable them to track your user's interaction with your entire website.

That's ridiculous. It's not getting free data to train it's fraud model, it's getting data to _use_ the fraud model!

Mastercard and Visa see all the transactions processed for the cards and so does the institution that issued your card (your bank). Unlike Stripe, they do a lot of non-fraud-related analysis on that information.

But putting fintech aside, GCP and AWS have access to everything on their customers' platforms, unless it's E2EE. They could (very illegally, and very stupidly) access all that data. There is no concrete difference between this and what you're talking about.

No matter how much encryption you put on it, your ISP has access to a history of a the IPs you directly connect to. To all the connections you make through them.

It's the nature of a middleman service provider to have access to these things. We can push to improve the status quo (more E2EE, decentralized designs and what not) but a better alternative has to exist before you can cry wolf about those that follow the norm.

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

Seems fairly "disclaimed" to me.

It's a library everyone can technically analyze, yes, but by 1) using ever-changing obfuscation that requires a lot of work to RE, and 2) constantly changing the client-side logic itself, it makes the work of the adversaries a lot harder and more tedious, and means either fewer of them will consistently succeed, or more of them will be forced to become more centralized around solutions/services that've successfully solved it, which means Stripe can focus-fire their efforts a bit more.

Of course there's also a lot going on on the backend that'll never be seen, but the adversary is trying to mimic a legitimate user as much as they can, so if the JavaScript is totally unobfuscated and stays the same for a while, it's a lot easier for them to consistently trace exactly what data is being sent and compare it against what their system or altered browser is sending.

It's cat-and-mouse across many dimensions. In such adversarial games, obscurity actually can and often does add some security. "Security by obscurity is no security at all" isn't exactly a fallacy, but it is a fallacy to apply it universally and with a very liberal definition of "security". It's generally meant for things that are more formal or provable, like an encryption or hashing algorithm or other cryptography. It's still totally reasonable to use obscurity as a minor practical measure. I'd agree with this part of https://en.wikipedia.org/wiki/Security_through_obscurity: "Knowledge of how the system is built differs from concealment and camouflage. The efficacy of obscurity in operations security depends by whether the obscurity lives on top of other good security practices, or if it is being used alone. When used as an independent layer, obscurity is considered a valid security tool."

For example, configuring your web server to not display its version on headers or pages is "security by obscurity", and certainly will not save you if you're running a vulnerable version, but may buy you some time if a 0-day comes out for your version and people search Shodan for the vulnerable version numbers - your site won't appear in the list. These kinds of obscurity measures of course never guarantee security and should be the very last line of defense in front of true security measures, but they can still potentially help you a little.

In the "malware vs. anti-virus" and "game cheat vs. game cheat detection software" fights that play out every day, both sides of each heavily obfuscate their code and the actions they perform. No, this never ensures it won't be fully reverse engineered. And the developers all know that. Given enough time and dedication, it'll eventually happen. But it requires more time and effort, and each time it's altered, it requires a re-investment of that time and effort.

Obfuscation and obscurity is arguably the defining feature and "value proposition" of each of those four types of software. A lot of that remains totally hidden on the backend (e.g. a botnet C2 web server only responding with malware binaries if they analyze the connection and believe it really is a regular infected computer and not a security researcher or sandbox), but a lot is also present in the client.

If what is collected is not linked to an individual and does not allow to identify an individual then these are not personal data and the legal point is moot.

Are Stripe co-founders paid by the word, or did that message get through about two dozen lawyers before being posted?

1) Is it fair to include the word "silently" in this post's title? [I think so, especially since it's part of the original article and reflects the author's emphasis.]

2) Does the word "silently" make Stripe look sneaky and bad? [Yes.]

3) Is Stripe's level of tracking invasive? [Yes.]

4) Should Stripe have been more forthcoming about the level of tracking they practice? [Most definitely! In this age of data breaches, users-as-the-product, and sneaky, untrustworthy online companies, Stripe should DEFINITELY have been more open about this, and should let its payment-service customers know what they're signing up for, in clear terms. Fraud prevention is a desirable feature, but potential customers should also be able to weigh that against the cost of invasive tracking. Furthermore, as a payment-processing company which can make loads of money in a very straightforward way (through commissions), Stripe should be content to be just that, and should get rid of any ideas, visions, or TOS language involving payment-service-tracking-derived advertising. If Stripe wants to take the high road, they could consider adding a "no data sold to advertisers" canary in its TOS that can assure the privacy-conscious of Stripe's pure intentions--or warn them when an undesirable corporate change happens that may prompt them to look for a service more aligned with their own priorities. Personally, I'm tired of companies that want to take over the world and seek profit in every area at any cost. Sheesh!]

Is there a reliable, independent way your customers can verify this statement is true?

Or is it perhaps your position that there is no legitimate reason for people to want this?

And let me add that "Nobody else does this" is not a suitable answer.

Ah, right, bad guys use privacy-enhancing tech, so we'd better undermine it, even if it screws over legitimate users. You know what fraudsters also tend to use? Chrome. Let's block that, shall we?

My outsider understanding was that credit card companies happily sell your purchase history or at least aggregate it for marketing, in addition to using your purchase history model to predict if a purchase is fraudulent.

The problem is that there's not much reason left to trust tech companies by default.

When used with other technographic data it can be used to fingerprint a user, but without any PII, you don't know who that user is.

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.

Most of your examples are quite low-level, but it's much harder to keep things hidden within the constraints of the browser sandbox when you have to interface with standard APIs which can be easily instrumented.

You misunderstand what personally identifiable information is. Each individual letter of my name is also not identifiable, the letters of the alphabet are not PII, but when stored in in the same database row, the separate letters do form PII no matter that you stored them separately or even hashed or encrypted them. My phone number is also not something that just anyone could trace to my name, but since my carrier stores my personal data together with the number (not to mention the CIOT database where law enforcement can look it up at will), there exists a way to link the number to my person, making it PII. Everything about me is PII, unless you make it no longer about me.

Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person.

Another example[1] mentioned on a website that the Dutch DPA links to (from [2]) is location data. Coordinates that point to somewhere in a forest aren't personal data, but if you store them with a user ID...

[1] (English) https://www.privacy-regulation.eu/en/4.htm

[2] (Dutch) https://autoriteitpersoonsgegevens.nl/nl/over-privacy/persoo...

This idea that the only viable business model on the web is spyware-backed advertising is baloney, and it always has been. There is little reason to assume the Web is a better place because the likes of Google and Facebook have led us down this path, nor that anything of value would be lost if they were prohibited from continuing in the same way.

For example, in my experience: user pays, website gets money, website releases product. It's the user that could be defrauded, not the website. I never heard of fraud issues from the website owners' perspective in the Netherlands where credit cards are just not the main method to pay online. Fraudulent Paypal chargebacks, sure, but iDeal.nl or a regular SEPA transfer just doesn't have chargebacks. It would appear that there is a way to solve this without tracking.

Not to belabor a point discussed elsewhere, but those were not arbitrarily chosen types of PII. They are how PII is defined in the specific law that was cited - CalOPPA. The comment to which I responded contains a link. The text of the law contains its definition of PII.

Please accept my apologies. I can see I failed to communicate clearly and readers interpreted my statements as broad comment about what is or isn't PII across a union of all potentially relevant laws and jurisdictions. This was in no way, shape, form, or manner my intended meaning. Again, please accept my apologies for failing to be clear.

> Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person.

Maybe it's just me, but I was under the distinction impression that some patterns of input are characteristic of humans and others of inhuman actors. Is it possible that a user could be identifiable as human or inhuman without having to know which specific human an input pattern corresponds to? Have I misunderstood something?

We appreciate that you are intent on fixing this, it helps us know that there are honest people working at Stripe and helps clear the fog that what seem to be a lot of us believing you are doing malicious things.

I hope you and your family stay healthy during this pandemic.

So, in order of Stripe to make more money (1.5% less fraud), you chose to track everybody.

Probably me too. Thanks for that.

Do you? You've audited 100% of the code you use? At best you're careful when choosing your dependencies and you have a reasonable degree of trust.

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

You can't rely on the client asking the server anonymously and adhering to the response. If you want to avoid a connection to a "specific human", it would go like this:

Fraudulent lient: POST /are/these/mouse_movements/human HTTP/1.0 \r\n Content-Type: JSON \r\n [{"x":13,"y":148},...]

Server: that's a robot

Fraudulent client: discards server response and submits transaction anyway

To make sure the server knows to block the transaction, it has to tie the mouse movements to the transaction, and thereby to a credit card number (afaik Stripe does only credit cards as payment option), at least during the processing of the submission before discarding the mouse movement data.

I'm not arguing this is evil or mistrusting Stripe or anything, just that this is considered PII in my part of the world.

Stripe.js is an API -- developers use this API to build something used by their customers. The customer is the one who's data is being collected, and the developers are the one's facilitating that collection via their service. The fact that it got sent to Stripe is not really relevant to who bears responsibility on clarifying data rights to the customer.

I get that one can object to any form of monetization of user data on principle, but pointing to Google as some kind of precedence doesn't seem sound.

Which is absolutely fine by the law if it isn't stored tied to PII.

I'm afraid I don't understand. Maybe you can help me? Seems to me you could not store things, you could require a signed and expiring token from the /are/these/mouse_movements/human service, or you could treat the request as super risky without that signed token. I'm sure there are others, I am known to suffer failures of imagination at times.

> To make sure the server knows to block the transaction, it has to tie the mouse movements to the transaction, and thereby to a credit card number (afaik Stripe does only credit cards as payment option), at least during the processing of the submission before discarding the mouse movement data.

I'm clearly wrong, but doesn't the logic here only work if the mouse movements are identifiable in the same sort of way that a phone number is? What happens if that's not accurate and mouse movements from a session are not so personally identifiable? What have I failed to understand? Wouldn't this logic also make transaction timestamps PII?

[1] https://en.wikipedia.org/wiki/History_of_advertising#16th%E2...

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.

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.

Stripe does not sell or rent Personal Data to marketers or unaffiliated third parties. We share your Personal Data with trusted entities, as outlined below.

From that and my reading of the rest, I think the answer is clearly no. Also I doubt the data of consumer purchases on Stripe integrated websites is even that valuable to begin with. At least compared to Stripe’s margins.

Adyen?

You are SOL. If enough people are SOL and care, then maybe things will change. If not, then you’ll change. Or you won’t.

"The simplest way for you to be PCI compliant is to never see (or have access to) card data at all. Stripe makes this easy for you as we can do the heavy lifting to protect your customers’ card information." [1]

Interesting question whether Stripe incurs statutory privacy duties to the web vendor and the buyer separately. I would imagine so, because given the "triangular" nature of this kind of Stripe transaction, Stripe ends up collecting data from two parties.

[This is not legal advice]

[1] https://stripe.com/docs/security

I don't think first-order data access is really the problem here, but rather where that data is going in general and who is authorized to access it, for how long, etc., and the volume of data any one person has access to at one time.

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.

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

Furthermore, a heartfelt promise from a payment provider to never sell my data means about diddly squat to me.

This is kind of a straw man. These valuable data sets are typically kept by tech companies to keep a competitive edge. For example, not even Google sells or rents user data.

The more relevant question is "is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?"

My guess is that the answer to this is likely yes. Fraud prevention is the current product built on this data. But it would be shocking if the company never put the data set to additional uses.

No, it's not. This telemetry is useful for helping businesses avoid crippling fraud losses and we don't use or plan to use it for anything else. I don't think investors even know about it.

We're perfectly happy with the business model we currently have!

  Main app
    My sandboxed iframe
      Stripe's iframe

https://developers.google.com/authorized-buyers/rtb/download...

I'll take this moment to say I appreciate how active you've been on HN responding to questions every time a Stripe article pops up.

I realize this can't be very fun for you to have this as the top result for the last however many hours.

If Stripe is ever purchased or goes bankrupt, can you provide any reasonable assurances that this data won't be sold?

If your company ever receives a search warrant for those records, how will you respond?

Not really looking for in-depth answers! Thanks!

They get the burden, but they wouldn't be able to know about evil activities from the third party provider.

In the unlikely case where Stripe was a bad player, the customer would sue the website, the website would countersue Stripe

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.

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.

As far as the cookie popups go the majority of them are not actually GDPR compliant. Tracking should be off by default and consent should be freely given, which means it should be just as easy to opt-in as it is to opt-out. If it's more difficult to say no than yes then the consent is invalid and they might as well just do away with the prompt completely since they're breaking the regulation either way.

I don't know if that's how Stripe is doing it, but you could do it that way.

Facebook and Google are still around. There is absolutely zero risk of any significant GDPR fine as long as the biggest offenders are allowed to run freely.

If I'm able to shop online without issues, why does everyone else 'need' an evercookie?

I'm sure it's helpful, it's the idea that it's necessary is what I take issue with.

Do people routinely avoid all B&M retail stores?

It is indeed not necessary when you can just use HTTPS.

Let's be honest here. Stripe.js may be about fraud prevention, but what that means is that you'll use every method available to gather data about that individual to build an identity. Then in 3 years when someone changes positions, that system will end up getting compromised, sold to the highest bidder, shared with some government agency, or used for nefarious purposes.

This will be tied to all their IP, OS information, transactions, etc. Just like they are using facial recognition at several retail stores. They make you use a chip reader now for credit/debit transactions, but it has no use online. I'd rather see an open-source universal effort towards decentralized currency, voting, identity, etc.

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.

This is why you hire people with empathy who can write to do support. Actually, just hire them for every position.

In your example, allowing Amazon's JS allows the site to work at least as far as AWS Console behaves. I don't really use eBay, so I can't speak to what JS is required.

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

We have two possible options here:

1. Client sends mouse-data + card info to a server, server checks the mouse data, turns it into a fraudPercent, and only stores that percent. That seems to be what they're doing now.

2. Client sends mouse data, gets back a unique nonce, and then sends that nonce to the server with card info. The server could have either stored or discarded the mouse info. It's perfectly possible the nonce was stored with the mouse info.

Those two things seem totally identical. The nonce by necessity must be unique (or else one person could wiggle their mouse, and then use that one nonce to try 1000 cards at once), and you can't know that they don't store the full mouse movement info with the nonce.

You gain nothing by adding that extra step other than some illusion of security.

Note, cloudflare + tor has a similar problem that they tried to solve with blind signatures (see https://blog.cloudflare.com/the-trouble-with-tor/), but that hasn't gone anywhere and requires a browser plugin anyway. It's not a viable solution yet.

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

However, sure, I'll humour you. A "signed and expiring token" is not sufficient because then a single attacker could use that token to try 1000s of cards before it expires.

Thus, you need a unique token, and wherever you store that unique token (to invalidate it, akin to a database session), you can optionally store the mouse movements or not. The association still exists. A unique token isn't functionally different from just sending the data along in the first place.

I haven't analyzed it and can't say this with any certainty, but my guess is that you're probably right: they're focusing primarily on backend analysis and ML comparing activity across a massive array of customers. This is different from smaller security firms who have a lot less data due to fewer customers, and a kind of sampling bias of customers who are particularly worried about or inundated by fraud.

They may be less interested in suspicious activity or fingerprinting at the device level and more interested in it at the payment and personal information level (which is suggested by articles like https://stripe.com/radar/guide).

Pure, uninformed speculation, but it's possible that if they get deeper into anti-fraud in the future (perhaps if fraudsters get smarter about this higher layer of evasion), they might supplement the data science / finance / payment oriented stuff with more lower-level device and browser analysis, in which case I wouldn't be surprised if they eventually separate out some of the anti-fraud/security parts into an obfuscated portion. (Or, more likely, have Stripe.js load that portion dynamically. Maybe they're already doing this, even? Dunno.)

If visa/mc/amex are so much better, people can use them.

Stripe uses visa/mc/amex, it is not a competitor. You completely missed my point. Stripe uses visa/mc/amex to process credit card transactions, then when a refund is issued the CC companies return the charged amount to Stripe, but Stripe does not return the full amount back to the customer. They keep a percentage. This is what I consider "borderline fraudulent".

Charging a flat fee for a service doesn't seem that fraudulent to me.

But it is not a flat fee. They keep a percentage of the refunded amount. So if a customer bought a $1000 item, then changed their mind and cancelled the order 5 min later, Stripe would still keep $40 just for the fun of it. A small flat fee to cover network expenses would be more appropriate, not a percentage of the amount.

> This data has never been, would never be, and will never be sold/rented/etc. to advertisers

I think it would be unsafe to assume that there is zero risk of significant GDPR fines on the basis that the regulatory bodies have not picked a battle with google and Facebook.

Smaller organisations that seem to be doing less to respect GDPR are probably an easier starting point for regulators to begin enforcing the law.

Tracking mouse clicks and URLs is auxiliary imo would not move the needle for them right now, unless they move into advertising (not impossible long term, if they go public).

> 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

> If you want to avoid a connection to a "specific human", it would go like this:

doesn't work either. It's perfectly possible that the server stored that info with the IP address and session information, since it also has access to those, and that could then be connected up with the transaction. I don't understand at this point what standard you're trying to meet, because it sounds like by what you're saying, literally any data sent to a server is "PII" if at some point that server also can, in principle, know your name.

> 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