
Stripe records user movements on its customers' websites - mtlynch
https://mtlynch.io/stripe-recording-its-customers/
======
pc
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)

~~~
threepio
Stripe customer here. The question raised is, more broadly, "Is Stripe
collecting this data in a legal and ethical way?" This too can be readily
answered in the negative.

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...](http://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?lawCode=BPC&division=8.&title=&part=&chapter=22.&article=)

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

~~~
Kalium
I am not an attorney. This is not legal advice.

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?

~~~
lucb1e
> Mouse movements are not a first or last name, physical or email address, [or
> one of a dozen other obvious examples]

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](https://www.privacy-regulation.eu/en/4.htm)

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

~~~
Kalium
> You misunderstand what personally identifiable information is.

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?

~~~
lucb1e
> [could one distinguish] human or inhuman without having to know which
> specific human an input pattern corresponds to?

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.

~~~
Kalium
> 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:

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?

~~~
lucb1e
You keep using that ridiculously apologetic tone that really rubs me the wrong
way while making constructive remarks. If you could lose the former without
the latter, I might actually appreciate your replies. But then, I'm reasonably
sure that it's meant to annoy.

> Seems to me you could not store things, you could require a signed and
> expiring token

That's actually a good idea.

~~~
Kalium
OK.

You didn't read the law I was talking about that was specifically and clearly
linked in the initial comment to which I responded. The comment in question
made a specific claim about a specific law in a specific jurisdiction to which
I responded narrowly and specifically. My comment referred clearly to the law
in question and summarized points from it.

All points about other laws in other locations are irrelevant to the specific
points I was offering discussion of.

> That's actually a good idea.

It is... provided that a handful of mouse movements actually qualify as PII.
Which, as claimed here under CalOPPA, seems like it might be doubtful. As
others have pointed out, there's room to doubt that a few mouse movements
would be considered PII under any current regulatory regime (there are
multiple notable ones, they don't agree on all points).

As an approach, it's useful for things like SAML and OAuth protocols when
you're dealing with different systems controlled by different parties and need
to delegate trust through an untrusted party. It's rarely the best way to move
data around inside a system, though, unless you have some compelling reason to
introduce this level of blinding.

------
khiner
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
Honest question, what exactly do people mean by fraud? How could someone
exploit a payment page?

~~~
amelius
Also, how would fraud detection work in Europe, where there is the GDPR?

~~~
carstenhag
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"

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

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

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

~~~
dylan604
There's a difference too between allowing self-hosted JS and 3rd party JS. As
a no-script user, if a site does not work with JS blocked, I will allow self-
hosted JS while still blocking 3rd party. If it still doesn't work, then I
consider if the site is something I'm really interested in or not. If not, tab
closes. If I am, then I'll look to see if there's 3rd party stuff I trust.

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.

~~~
RussianCow
I think most businesses would be more than happy to lose the tiny percentage
of customers who use NoScript in exchange for better fraud detection.

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

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

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

------
cordite
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
It being common practice doesn't make it okay.

~~~
cordite
To defend against credit card fraud in an automated world, it’s kinda the only
thing we got: an automated risk assessment.

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

------
voiper1
>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!

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

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

~~~
Ensorceled
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
What GDPR exemptions are you referring to?

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

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

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

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

~~~
falcolas
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
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)

------
uncletammy
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
no, they weren't.

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

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

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

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

------
WesolyKubeczek
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
Almost like a...services agreement
([https://stripe.com/legal#section_d](https://stripe.com/legal#section_d))?

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

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

------
lucb1e
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=CEL...](https://eur-
lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2838-1-1) (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.)

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

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

------
TechBro8615
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
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
Very interesting, especially the agent retention. I suppose feeling like less
of a robot boosts morale.

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

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

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

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

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

------
gonational
Time to add Stripe to uBlock Origin...

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

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

~~~
3pt14159
I love Stripe, but this type of feature should be made front and clear when
installing it. Some people use Stripe for a very small part of a very large
app. If it's an online store, then it's totally fine. If it's an app where 95%
of the routes are supposed to be private then it's not ok. So I appreciate
this post mtlynch.

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

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

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

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

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

