
Stripe responded to my concerns about user tracking - mtlynch
https://mtlynch.io/stripe-update/
======
akersten
I think this part is a little off:

> Perhaps you have no sympathy for web applications that store sensitive data
> in query strings, as that’s widely recognized as an insecure pattern. The
> URL fragment is more serious. That otherwise is a safe way to store
> sensitive information, so it’s alarming to see a third-party library sending
> a copy to an external server.

> Firefox Send and Mega.nz are both examples of popular web apps that use the
> URL fragment to store client-side encryption keys so that users can save
> end-to-end encrypted files to the cloud without the server ever having
> access to the underlying data.

The URL fragment is not designed to be any more secure than anything else in
the URL, it's just a funny quirk of how web browsers evolved that it doesn't
happen to be sent to the webserver. That popular platforms are (mis)using it
to pass information without that information hitting their webservers is
unfortunate. But it doesn't mean that the URL Fragment is somehow special or
should be thought of as "secure" \- that's not a guarantee that the URL scheme
makes.

For example, those fragments will easily appear in browser history for anyone
else who uses your same device...

~~~
mtlynch
Thanks for reading!

That's an interesting point. I did take it for granted that browsers guarantee
web apps that they don't send the URL fragment to the server. I've never
looked into it, but your comment sent me to read RFC 3986.

From my reading, the RFC does seem to prohibit browsers from sending the URL
fragment:

> _Fragment identifiers have a special role in information retrieval systems
> as the primary form of client-side indirect referencing... As such, the
> fragment identifier is not used in the scheme-specific processing of a URI;
> instead, the fragment identifier is separated from the rest of the URI prior
> to a dereference, and thus the identifying information within the fragment
> itself is dereferenced solely by the user agent, regardless of the URI
> scheme._

Granted, the wording isn't 100% clear, so maybe I'm imposing my own hopeful
interpretation on the RFC.

I agree that if I were storing, say, military secrets, I wouldn't choose the
URL fragment as a storage medium. But if the expectation is "this is a place
where I can put user data and the browser won't leak it to other places," then
the URL fragment seems to me a sensible place to store data, on par with
browser local storage.

This is in contrast with plain URLs which third party servers receive through
the HTTP referer header. The browser leaks query parameters to other places,
too, notably HTTP proxies. But Stripe's JS library was the first I'd seen of a
system that exposes URL fragments to an external service.

~~~
ucarion
Putting secret information in a URI is explicitly called out as a bad idea in
the very RFC you reference:

> URI producers should not provide a URI that contains a username or password
> that is intended to be secret. URIs are frequently displayed by browsers,
> stored in clear text bookmarks, and logged by user agent history and
> intermediary applications (proxies).

[https://tools.ietf.org/html/rfc3986#section-7.5](https://tools.ietf.org/html/rfc3986#section-7.5)

As an aside, if you're going to be making any security judgments from an RFC,
_every_ RFC since RFC2223 has a Security Considerations section. You usually
want to start there.

~~~
mehrdadn
It's fairly obvious that this is about keeping secrets from other users
_locally_ whereas the fragment discussion is about keeping secrets _from the
server_ and that these two are not the same thing. People reasonably see the
fragment as none of the server's business independently of whether it's any
other local user's business (the latter fact itself being no one else's
business to care about).

~~~
dzhiurgis
Seems like both Stripe and website author are misusing the browser feature.

Seems like core problem is lack of storage API that can only be accessed from
JS that's executes from same domain?

Edit: Seems localStorage does isolate per domain, but I am not sure whether
it's for page itself or for external JS too.

~~~
ppseafield
I've found some places say localStorage is insecure, but both OWASP [0] and
MDN [1] say it isolates by origin. Third party scripts from different origins
shouldn't be able to access it, but a successful XSS attack could have access.

[0]
[https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#the-
localstorage-api)

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/Web_Storage...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Storage_API/Local_storage#Compatibility_and_relation_with_globalStorage)

------
tompic823
I read the initial post when it was trending on HN, and had previously noticed
that line in Stripe's Privacy Policy. I remember checking immediately
afterward that my company was only loading Stripe's js on our billing page.
I'm a skeptic by nature, so even after reading pc's response I still didn't
feel great.

Then I got to reading this new post:

> Amid the discussion on Hacker News, a user expressed concern that, despite
> Stripe’s current good intentions, user data could fall into the wrong hands
> in the event that another company purchased Stripe ... Perhaps in direct
> response to that exchange, the new privacy policy includes this clause:

> > Any other entity which buys us or part of our business will have the right
> to continue to use your Personal Data, but only in the manner set out in
> this Privacy Policy unless you agree otherwise.

This is fantastic. I've yet to see a requirement such as this in any Privacy
Policy I've read. In fact, I hadn't even considered the possibility of such
cleverness. This is now my new gold standard for the company sale terms of any
_practical_ privacy policy. I'm going to look into updating my company's
privacy policy to reflect this language.

~~~
barbegal
> Any other entity which buys us or part of our business will have the right
> to continue to use your Personal Data, but only in the manner set out in
> this Privacy Policy unless you agree otherwise.

I thought this was implied in any contract. A change of owner doesn't mean the
terms of the contract stop being applied.

~~~
tompic823
I can't speak to the implication, but I've yet to read a policy that didn't
explicitly outline how it handles business transfers. Some examples from
different industries (the first 3 random sites I thought of):

AirBnB [0]

> If Airbnb undertakes or is involved in any merger, acquisition,
> reorganization, sale of assets, bankruptcy, or insolvency event, then we may
> sell, transfer or share some or all of our assets, including your
> information in connection with such transaction or in contemplation of such
> transaction (e.g., due diligence). In this event, we will notify you before
> your personal information is transferred and becomes subject to a different
> privacy policy.

Segment [1]

> We may sell, transfer or otherwise share some or all of our business or
> assets, including your personal information, in connection with a business
> deal (or potential business deal) such as a merger, consolidation,
> acquisition, reorganization or sale of assets, or in the event of
> bankruptcy, in which case we will make reasonable efforts to require the
> recipient to honor this Privacy Policy.

Repl.it [2]

> We share or disclose information only in the following cases ... - As
> necessary in the event of a proposed or actual reorganization, merger, sale,
> joint venture, assignment, transfer, financing, or other disposition of all
> or any portion of our business, assets, or stock.

[0]
[https://www.airbnb.com/terms/privacy_policy](https://www.airbnb.com/terms/privacy_policy)

[1] [https://segment.com/legal/privacy/](https://segment.com/legal/privacy/)

[2] [https://repl.it/site/privacy](https://repl.it/site/privacy)

~~~
luckylion
Those are about _your data_ as a customer though. It's obvious that if a
company is acquired, the new owner also takes the customer list, and active
customers have very different rights regarding data protection than the
customer's customers that visit their website and do not know that data is
being collected about them.

If e.g. Google would sell Google Analytics to Facebook, they cannot use the
Analytics data to track users and send them emails, since it wasn't originally
agreed upon with the GA-users. They very much can send an email to every GA
user and offer them the new FBGA premium service.

------
loeg
I remain extremely impressed by Stripe and pc's handling of this; kudos for
taking a somewhat hostile blog post and using it to inspire improvement.

~~~
bryanmgreen
Generally speaking, it's pretty shocking how utterly abysmal crisis/damage-
control PR is for companies. Rather than "never letting a good crisis go to
waste", most companies/leaders just dig a deeper hole.

A small part of me would love to just start a Crisis PR firm for tech
companies.

Regardless of who's right or wrong, it's really nice to see a leader come out
and actually face criticisms with a cool head, and at least from my point of
view, not bullshit legal language. Even better if it does encourage positive
change.

(Specifically about Stripe, I am positively biased because once I submitted
some feedback and their product team immediately jumped to communicate with me
as to how to best design and implement the feature.)

~~~
tmpz22
I don't think most companies have the capacity to handle it well in the first
place. I think the outliers like Stripe are different because they have a very
hands on CEO who can cut through all the tape, IIRC they also have a fairly
learn and very technical organization with strong domain knowledge in areas
where the tape is cut. Most orgs are non-engineering orgs, most CEOs are not
technical, most large orgs have far too much bureaucracy to cut through it.

~~~
bryanmgreen
If you're a CEO or a senior executive, I personally would expect that you're
100% capable of responding to criticism without losing your mind or spending
$5,000 for a lawyer to send you some copy-pasta of "We take your feedback very
seriously and will consider your opinion." and then never doing anything.

I'm not suggesting the leader be the one to personally go and fix the problem,
but they certainly should have the communication skills to navigate it and
organize a solution.

------
earpwald
Personally I think this has been a good pointer that we need to be careful
about what we trust third party libraries and frameworks to do.

I in no way believe that Stripe had any intentions of doing anything wrong,
however it is good to hold people accountable and ensure that what they do is
above board. I have personal examples of companies caring very little about
users data, except when they might be caught out for it.

Thanks for the article.

~~~
mtlynch
Thanks for reading!

> _I in no way believe that Stripe had any intentions of doing anything wrong,
> however it is good to hold people accountable and ensure that what they do
> is above board. I have personal examples of companies caring very little
> about users data, except when they might be caught out for it._

Very much agree. I think Stripe is demonstrating responsible behavior here,
and the best way to further encourage that is to show that people actually
care what they do and will raise alarms when they overstep, even
inadvertently.

------
geekpowa
If only PayPal were as accessible and responsive as stripe. There is a serious
regression in their API right now : it is so bad and obvious it shouldn't of
even made it past their internal testing stage. Been there for 2 weeks now.
You think I can get anyones attention at paypal? They don't even seem to have
a decent issue ticketing system to track it.

~~~
mtlynch
In fairness, Stripe also kind of brushed this off until it got more attention.

There are StackOverflow posts going back to 2017[0] and Github issues with
direct acknowledgement from Stripe employees with no solution offered.[1]

I even reached out to Stripe support before publishing my first post, and they
told me that the collection behavior was by design and in my users' best
interest.[2]

I've been very impressed by Stripe's response here, but it's demonstrably not
the same response they deliver to customers who go through normal support
channels.

[0]
[https://stackoverflow.com/q/45718026/90388](https://stackoverflow.com/q/45718026/90388)

[1] [https://github.com/stripe/react-stripe-
elements/issues/99#is...](https://github.com/stripe/react-stripe-
elements/issues/99#issuecomment-528987443)

[2] [https://mtlynch.io/stripe-recording-its-
customers/#reporting...](https://mtlynch.io/stripe-recording-its-
customers/#reporting-this-to-stripe)

~~~
brogrammernot
I’m sure I’ll get downvoted but why should it be? Stripe has thousands of
items in the backlog across many areas, and in a larger company there’s
prioritization at many different levels.

I’m happy that they addressed this but I often see on HN that folks expect
that an email to support staff gets the same level of support/awareness as a
highly viewed post on HN does.

As a Stripe customer, there are several things that I’d love to see improved
or modified but I don’t expect all, if any, of them to make it into the
roadmap immediately as they’re trying to scale & fix really big issues that
have already been identified.

Do I wish it was possible for businesses to address every single
customer/consumer complaint? Of course, but that’s not the reality we live in.

Also - I’m not letting any company off the hook with this statement, there’s
plenty of companies out there that intentionally neglect glaring issues
because they don’t want to deal with the noise that comes along with it but
Stripe hasn’t really even been one of those companies.

Sometimes it is the best company policy to ignore items until they go away,
and to deal with the ones that rise to the top naturally.

~~~
luckylion
> Stripe has thousands of items in the backlog across many areas, and in a
> larger company there’s prioritization at many different levels.

"Hey, you're doing something that may be illegal." \- "Yeah, we know"

That's an issue. If they'd say "but the color of our signup button has a
higher priority", that's an even larger issue.

------
adrr
"We do not use, share, rent or sell the Personal Data of our Users’ Customers
for interest-based advertising. "

Better version would be all advertising instead of interest-based advertising
Also "personal" data excludes lots of data. Personal data just means data that
is attached an identified person. Lot of ad targeting is at an anonymous ID,
they don't really know the person.

~~~
stefan_
This is not how any of this works. You don't write a privacy policy listing
all the things you _don 't do_; you write it listing and justifying the things
that you _do_.

~~~
luckylion
They literally wrote what they _won 't do_. They were just very specific with
it, which suggests they _may_ use, share, rent and sell the personal data for
non-interest-based advertising, e.g. demographic-based advertising and want to
keep the option on the table.

------
mtlynch
Hi all. Author here. This is a follow-up from my post last week, "Stripe
records user movements on its customers' websites":

[https://mtlynch.io/stripe-recording-its-
customers/](https://mtlynch.io/stripe-recording-its-customers/)

[https://news.ycombinator.com/item?id=22936818](https://news.ycombinator.com/item?id=22936818)

As always, feedback and questions are welcome.

~~~
thoraway1010
Do you understand anything more yourself? The need for some of these steps for
fraud control (vs your assume bad intentions initial approach).

~~~
mtlynch
Thanks for reading!

I understood from the start that this data was for fraud protection. At the
time of my initial article, Stripe had not clearly disclosed the extent of
their tracking nor stated any limitations on how they would use the data. I
tried hard to avoid accusing Stripe of nefarious behavior, so if there are
specific sections in my post that failed to do this, please let me know.

Regardless of Stripe's intentions, I believe there needs to be clear agreement
about what data Stripe collects and what limits they'll observe in using that
data. If we blindly allow Stripe to collect whatever data their JS library has
access to as long as their intentions are good, we put ourselves at risk if
that data falls into the wrong hands.

I think Stripe shows a serious commitment to privacy and security, but there's
always an inherent risk in storing copies of data with a third party. The more
data that Stripe collects, the greater that risk, so clients should have a say
in whether that increase in risk is worth the improvement they receive in the
accuracy of Stripe's fraud protection.

~~~
frakkingcylons
> I understood from the start that this data was for fraud protection.

If we're being honest with ourselves, the title of your original blog post
("Stripe is Silently Recording Your Movements On its Customers' Websites") is
worded like they're being being sneaky and have something to hide.

~~~
mtlynch
Thanks, that's fair.

I gave a lot of thought to how to word it to not project intention onto
Stripe. But I did think one of the most important parts of the story was
Stripe's lack of disclosure about the behavior.

I considered and rejected "secretly" and "surreptitiously" because they
suggested intention. "Silently" was the best word I could think of to convey
the lack of disclosure while minimizing judgmental undertones. I understand
that it still does suggest something underhanded, so maybe it would have been
better for me to omit the word entirely.

~~~
greatwhitenorth
How about "Stripe records Your Movements On its Customers Websites"? Does it
still not convey the meaning? But yeah, click bait titles drive traffic to the
blog and to your website (portfolio rebalancer) that you linked in your blog
post. May be you will end up in page 1 of Google when some one searches
"Stripe Privacy". Smart strategy and all in all a win :-)

~~~
anon102010
"Stripe records cursor movement on customer websites as part of its fraud
control efforts" \- that's probably the real title. But obviously doesn't get
the traffic.

~~~
barrkel
And also every URL you visit on the site

~~~
thoraway1010
AS does almost all other fraud fighting tools (they all use beacons to try to
get as broad a sample as they can of user click / browse trails).

~~~
barrkel
That's not my beef; my beef is the abbreviation of the immediate parent of my
comment.

------
amrrs
Icymi, Stripe CEO Patrick Collision's response to the original thread -
[https://news.ycombinator.com/item?id=22937303](https://news.ycombinator.com/item?id=22937303)

------
morpheuskafka
> Stripe updated their JavaScript library to give clients the ability to opt-
> out of deep data collection. They can now load the <script> tag with the
> advancedFraudSignals=false parameter to disable this functionality:

If this is set on the client-side, what stops an attacker from editing the
page to disable the fraud detection sites that want to use it?

~~~
jedberg
Sure, but that in and of itself would be a major fraud signal. If 99% of the
traffic from a site is coming into their fraud system, and yours isn't, that
would be an even bigger fraud signal that if it were on.

------
timvisee
They mention the use of a script parameter. Can't bots just set this parameter
on any website using stripe to bypass this detection, or is this enforced on
Stripes end as well?

~~~
warkdarrior
I am sure it is enforced on the Stripe backend. Basically it sounds like there
are two options:

1\. Do not set the script parameter, let Stripe collect the data, and have
them do fraud detection, which will result in better risk scores and more
transactions approved.

2\. Do set the parameter, prevent Strip from collecting the data, and prevent
them from doing the fraud detection (since they have no data to feed the
detector). This may result in a higher risk score (meaning higher fees) and/or
fewer transactions approved.

------
amelius
Can someone explain what kind of fraud we're talking about?

~~~
swanson
Bots that use stolen cards to make purchases (or use legitimate SaaS apps as a
vector to test if a card number if valid)

Stripe "tracks" user data that they run through some fancy ML thing to try to
detect if the person is a bot or a real human -- based on, presumably,
patterns in user mouse movement, delay in moving between inputs, interval
between keystrokes, etc.

~~~
amelius
But we have other ways of testing for bots. See for example Google's Recaptcha
(again, example, and not my main point). I don't see why we need to give away
our personal information to yet another big company, especially if the
information comes from web surfing behavior that has nothing to do with
payment.

And in case this is all still necessary, can't this be handled by some trusted
party instead of the company that already knows about all our online payment
transactions? Compartmentalization is a very important concept in user
privacy.

[https://en.wikipedia.org/wiki/Compartmentalization_(informat...](https://en.wikipedia.org/wiki/Compartmentalization_\(information_security\))

~~~
akersten
How do you think ReCaptcha (at least ReCaptchaV3) works? It's gathers the same
kind of "personal" data (mouse movements, etc.) to feed an ML model to
determine whether the client is a robot.

~~~
amelius
Yes, but only from the page the captcha is visible on.

In contrast, Stripe collects also data from webpages that are not payment
pages.

~~~
nulbyte
> In contrast, Stripe collects also data from webpages that are not payment
> pages.

Like recaptcha, whether the Stripe code is included on a given page is solely
up to the author of that page.

While I may tend to agree with OP's requests for increased transparency, that
desire does not lend its support to other claims about how Stripe's code
works. Putting it on every page is not required. Unless I am mistaken, putting
it on every page is not even suggested by Stripe. Why anyone would put Stripe
or any other third-party code on every page indiscriminately, without
considering whether it was necessary, is beyond me.

~~~
quelltext
> Unless I am mistaken, putting it on every page is not even suggested by
> Stripe.

[https://stripe.com/docs/js/including](https://stripe.com/docs/js/including)

> Include the Stripe.js script on each page of your site—it should always be
> loaded directly from [https://js.stripe.com](https://js.stripe.com), rather
> than included in a bundle or hosted yourself.

> To best leverage Stripe’s advanced fraud functionality, include this script
> on every page, not just the checkout page. This allows Stripe to detect
> suspicious behavior that may be indicative of fraud as customers browse your
> website.

~~~
nulbyte
Oh wow. I stand corrected. They should really nix that; well intended, I'm
sure, but fairly egregious.

------
jbverschoor
“Interest based advertising”

That does not include:

\- analytics by companies based on interest

\- advertising based on monthly spend

