Stripe Is Silently Recording Your Movements On Its Customers' Websites (mtlynch.io) 116
Michael Lynch, blogger and former software engineer at Microsoft and Google, discovered that the payment processing platform Stripe and its official JavaScript library records all browsing activity on its customers' websites and reports it back to the company. Lynch says this data includes the following:
1. Every URL the user visits on my site, including pages that never display Stripe payment forms
2. Telemetry about how the user moves their mouse cursor while browsing my site
3. Unique identifiers that allow Stripe to correlate visitors to my site against other sites that accept payment via Stripe
In his blog post, Lynch shares what he found, who else it affects, and how you can limit Stripe's data collection in your web applications. Here's how he says he made the discovery: I discovered this by accident while adding paid plans to my portfolio rebalancer. As part of development, I was using an HTTP proxy that allows me to inspect HTTP traffic from my browser. After successfully implementing my app's payment flow with Stripe, I noticed that every page navigation generated a new HTTP POST request to a Stripe URL. This was strange because none of the pages I visited contained any calls to Stripe's library. In fact, my app doesn't collect payment information from users until they create an account, but Stripe was making HTTP requests when I landed on my app's homepage as a brand new user with no cookies or stored credentials. "I looked around for an official disclosure from Stripe about this behavior, but I couldn't find anything," adds Lynch. "The closest I found is this vague paragraph on their npm package description, which the Stripe support rep quoted to me: 'To best leverage Stripe's advanced fraud functionality, ensure that Stripe.js is loaded on every page, not just your checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.'"
"The privacy policy is a bit more specific about the data they collect, but it implies that they're collecting this data on stripe.com rather than on customer sites," writes Lynch. "Worryingly, the privacy policy also includes loose wording that allows Stripe to sell this data to advertisers: 'When you visit our Sites or online services, both we and certain third parties collect information about your online activities over time and across different sites to provide you with advertising about products and services tailored to your individual interests.'"
1. Every URL the user visits on my site, including pages that never display Stripe payment forms
2. Telemetry about how the user moves their mouse cursor while browsing my site
3. Unique identifiers that allow Stripe to correlate visitors to my site against other sites that accept payment via Stripe
In his blog post, Lynch shares what he found, who else it affects, and how you can limit Stripe's data collection in your web applications. Here's how he says he made the discovery: I discovered this by accident while adding paid plans to my portfolio rebalancer. As part of development, I was using an HTTP proxy that allows me to inspect HTTP traffic from my browser. After successfully implementing my app's payment flow with Stripe, I noticed that every page navigation generated a new HTTP POST request to a Stripe URL. This was strange because none of the pages I visited contained any calls to Stripe's library. In fact, my app doesn't collect payment information from users until they create an account, but Stripe was making HTTP requests when I landed on my app's homepage as a brand new user with no cookies or stored credentials. "I looked around for an official disclosure from Stripe about this behavior, but I couldn't find anything," adds Lynch. "The closest I found is this vague paragraph on their npm package description, which the Stripe support rep quoted to me: 'To best leverage Stripe's advanced fraud functionality, ensure that Stripe.js is loaded on every page, not just your checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.'"
"The privacy policy is a bit more specific about the data they collect, but it implies that they're collecting this data on stripe.com rather than on customer sites," writes Lynch. "Worryingly, the privacy policy also includes loose wording that allows Stripe to sell this data to advertisers: 'When you visit our Sites or online services, both we and certain third parties collect information about your online activities over time and across different sites to provide you with advertising about products and services tailored to your individual interests.'"
Maybe it's anti-fraud (Score:5, Interesting)
Maybe it's anti-fraud in the same way as the "I'm not a robot" captcha.
ie. It's not the action of clicking the checkbox that counts, it's how you do it.
PS: I assumed that all major web sites do this stuff these days. Shrug.
Re:Maybe it's anti-fraud (Score:5, Informative)
That's what the cofounder of Stripe is claiming: https://news.ycombinator.com/i... [ycombinator.com]
(see the first comment)
Best option for now is to add Strip.js to your ad blocker. uBlock with default filters already kills it. It's not needed for payment processing.
Re: (Score:2)
Best option for now is to add Strip.js to your ad blocker. uBlock with default filters already kills it. It's not needed for payment processing.
Is a single claim in that quote actually correct here?
Re: (Score:2)
Yes, there are multiple claims. I am questioning them all. Stripe's JS certainly is part of the normal flow on a lot of sites using Stripe to collect the payment details, and as such it's probably not helpful advice to block it completely, nor is it likely that any reputable browser plug-in is doing so by default.
Re: Maybe it's anti-fraud (Score:2)
I think most plugins rely on a very simple heuristic for defaults. That is: is it a third party script? If you're hosting the Stripe code yourself, it will probably be allowed by default. If you're using a public CDN, it will probably be blocked by default.
Re: (Score:2)
It is explicitly stated in Stripe's documentation that the script in question should be loaded direct from Stripe's servers. (And there are multiple good reasons for them to give that advice, in relation to security and compliance.)
Re: Maybe it's anti-fraud (Score:2)
There's a good chance this guy was self-hosted. He mentions the Stripe npm package. It's very common to use something like webpack to bundle up all your npm dependencies. Unless told otherwise, this typically results in code being included in your own hosted bundles. It's not optimal, but it's the path of least resistance.
Re: (Score:2)
The Stripe NPM package is for the back-end API/webhooks integration.
Stripe.js is a client-side library, which as mentioned above, you must load direct from Stripe's servers for security and compliance reasons.
If someone is self-hosting stripe.js, they are doing it wrong, end of story.
this ain't your father's zuck-a-duck (Score:4, Informative)
The cofounder you are talking about is Patrick Collison, who is highly respected in elite circles.
In Eric Weinstein's interview of Tyler Cowen on The Portal, around the 1h18m mark, they mutually agree that Patrick Collison has one of the most impressive minds now in high tech, and neither of those two guys involved in that conversation are slouches on their own terms.
Because I've heard good things about Patrick (and not just here) I dug much further into that HN thread than I would have otherwise.
Patrick (posting as "pc") is broadly and sincerely engaged all the way through the thread.
Here:
Here:
Here:
Here:
Here:
Legend has it that Slashdot, too, once had people of this caliber showing up on a daily basis.
Now we just have old farts such as myself moaning to the smart, young whippersnappers: "Hey, you! Get back on my lawn!"
———
[*] The zuck-a-duck is an autistic-hipster modernization of the good old-fashioned rope-a-dope.
Why Zuckerberg's 14-Year Apology Tour Hasn't Fixed Facebook [wired.com] — 6 April 2018
Re: (Score:2)
I agree it's not malicious, but I'm blocking it anyway.
Re: (Score:2)
Re:Maybe it's anti-fraud (Score:4, Interesting)
I think it may just also be for product research. How are people using the product? How are they using it?
Tracking mouse movements is useful even to test to see how good your UI is.
Early in my career, I took a good amount of time making a search ahead select box in HTML. At the time, that was pushing the capabilities of HTML. So it was a text box, a button, and a positioned DIV mixed with some Javascript with the finally widely supported AJAX methods.
I got it to work wonderfully, it looked just like a normal select box on windows forms, and functioned just like it. Until I gave it to someone else to take a look at. Within 5 minutes of releasing it to be tested, they came back to me saying it didn't work. I was flabbergasted I tested the heck out of it, for it to just not work seemed out of the left field.
So I watched the tester use is. He tried to scroll down the options using the scroll bar with his mouse. (which the click caused a loss focus to my master control and the search box to disappear) I almost never scroll down using the scroll bar. I would use the mouse wheel or my arrow keys. So I missed a test case, mostly because I never thought of it.
Watching someone use the system gives you insight on where the problems are to be fixed.
Re:Maybe it's anti-fraud (Score:4, Informative)
Nobody is questioning that it's valuable information, just that Stripe is (more or less) silently doing this research on your customers.
It doesn't have to be this way (Score:5, Insightful)
Tell me again why browsers default to blindly executing every bit of javascript that they see?
NoScript should be the first plugin you add to your browser.
Re: (Score:2)
Re:It doesn't have to be this way (Score:5, Insightful)
Because money.
***Always follow the money.***
Not just money (Score:2)
You don't get that without a programming language running in your browser.
Re: (Score:3, Insightful)
> Tell me again why browsers default to blindly executing every bit of javascript that they see?
One is owned by an ad company, the other by a Foundation that sold out to an ad company in 2003.
Or just, yanno, install Brave.
Re: (Score:2)
Tell me again why browsers default to blindly executing every bit of javascript that they see?
It is by design. It allows people to use remote javascript libraries to build user interfaces to their remote applications rather than creating a secure stand alone remote application interface that the user downloads once.
The questions should be:
Tell me again why people are using web browsers as general purpose application user interfaces that get repeatedly downloaded every time one clicks on a link.
Tell me again why people are blindly using javascript libraries.
Re: (Score:3)
Tell me again why people are using web browsers as general purpose application user interfaces that get repeatedly downloaded every time one clicks on a link.
Please try to keep up:
a) No install needed.
b) Works on all platforms
c) Nobody using old/obsolete versions of your program.
d) Browser caches together with CDNs mean you don't have to download it every time
Re:It doesn't have to be this way (Score:4, Informative)
Exactly. Look at what it takes to make a decent single page web application today. Now look what it takes to build a native equivalent on every major platform. Now looks at what it costs to do that, not just in development effort but also in all the fees for buying the right equipment and registering with the right gatekeepers and giving the marketplaces their cuts and so on.
It's pretty obvious why developers are making web apps. It's because the native app development experience is awful. And since most of their customers are satisfied enough with those web applications to use them, if anyone reading this wants to change that situation, they need to convince organisations like Apple to do better by developers, because the browsers and the developers aren't going to give up those advantages any time soon and they also aren't going to shed any tears for the 0.01% of possible customers who care enough about these issues to block them.
Publish a protocol (Score:2)
Exactly. Look at what it takes to make a decent single page web application today. Now look what it takes to build a native equivalent on every major platform. Now looks at what it costs to do that, not just in development effort but also in all the fees for buying the right equipment and registering with the right gatekeepers and giving the marketplaces their cuts and so on.
To a vocal minority of highly-technical readers, many of whom hang out on Slashdot or SoylentNews, these costs are worth it. They prefer to use a service that has paid the cost of developing five front-ends, each perfectly tailored to the desktop or mobile operating system on which it runs, over the competing service whose usability is inferior on account of not having paid this cost. Better yet, they prefer to use a service that has a published protocol, such as IRC or XMPP or Matrix for chat, so that memb
Re: (Score:3)
To a vocal minority of highly-technical readers, many of whom hang out on Slashdot or SoylentNews, these costs are worth it.
Sure, but probably few if any of those people is actually running a business where this is relevant. It's mostly just the usual wishful thinking from people who benefit from but do not bear the cost of what they are advocating.
Also, you can do a lot to improve usability when your baseline development cost is only ~20% of the cost your competitor is paying to be in the game at all.
Re: (Score:2)
One usability issue involves getting files in and out of a web application. Last I checked, an HTML+JavaScript app could upload a folder full of files but could download only one file at a time. And even if a user chose to upload a file, there was no way for a web application to write out changes to the same file in the file system. Getting data in and out of the clipboard also tends to be heavily restricted for security reasons, ostensibly so that web applications can't eavesdrop copied passwords or copied
Re: (Score:2)
It's certainly not perfect, I agree. But then uploading and downloading files in bulk is relatively unusual for a web application, and as you say, there are good security reasons to limit what browsers allow untrusted code to do with local resources like files or the clipboard. This is arguably a superior position to what you get by default with native applications on the main desktop operating systems, where even in 2020 they still have application security models that are decades past their sell-by dates
Adobe, WoW, and Ripcord (Score:2)
Do you know any slashdotters or soylents that have donated the hundreds of thousands of dollars to a company to pay for desktop/native front ends?
Anyone who subscribes to a paid service with a native client has done this. This includes every Adobe Creative Cloud subscriber, every subscriber to World of Warcraft or any other paid MMO, and everyone who has paid $20 for Ripcord (Slack and Discord client).
Re: (Score:2)
Is Adobe Creative Cloud available on Linux now?
Can I play WoW on my phone?
If not, then I respectfully suggest that your examples here are missing the point of the original discussion.
Re: (Score:2)
a) No install needed.
True, one just has to download the entire thing multiple times every usage
b) Works on all platforms
Platforms? In this case, platform means web browsers so Brave, Chrome, Edge, Firefox, IE, Opera, and Safari.
c) Nobody using old/obsolete versions of your program.
Many people are using old/obsolete versions of browsers, which means not only is one writing for multiple platforms but one is also writing for multiple versions of multiple platforms some of which may be insecure and if you don't allow people to use their preferred platform, they may not use your service.
d) Browser caches together with CDNs mean you don't have to download it every time
Browser cache is contro
Re: (Score:2)
You know very well that he meant Windows, macOS, Linux, iOS and Android.
Brave is just Chromium so you don't have to even worry about it. Firefox has so few users that most devs don't even test for it anymore. The latest version of Edge is also just Chromium. Internet Explorer was declared dead by Microsoft themselves years ago. Opera was bought by a Chinese company and has so few users that most devs
Re: (Score:2)
You're partly right. Chrome and Safari make up 80% of web traffic.
The problem is, even though Firefox hovers at just under 10% of desktop web traffic, that's still a LOT of users. Developers not testing for those millions and millions of users are morons.
You didn't even mention the fourth most popular browser in the world: UC Browser
Re: (Score:2)
Firefox is keeping up with the standards just fine. The chances of writing something that works on Chrome but doesn't work on Firefox is quite slim (and probably means you aren't following the standards anyway).
Re: (Score:2)
You know very well that he meant Windows, macOS, Linux, iOS and Android.
[...]
Firefox has so few users that most devs don't even test for it anymore.
I was going to reply that Firefox's usage share is still over twice IE's, and popular distributions of "Linux" (by which you probably mean X11/Linux) ship with Firefox as the default browser, not something built on Chromium. But then X11/Linux itself "has so few users that most devs don't even test for it anymore." macOS also has few users, but devs test for it because its user base tends to have more disposable income per capita.
Opera was bought by a Chinese company and has so few users that most devs don't even test for it anymore.
For simplicity, I'd just say "Recent Opera is Chromium."
Re: (Score:2)
You know very well that he meant Windows, macOS, Linux, iOS and Android.
No, I meant 'platforms'.
No matter what computing device you own there's probably a combination of OS+Browser that lets you run my HTML5 application.
Native applications can offer too many updates too (Score:2)
True, one just has to download the entire thing multiple times every usage
Not for a web application that follows caching best practices. Web application publishers have an incentive to implement best practices in order to reduce their CDN bill.
Platforms? In this case, platform means web browsers so Brave, Chrome, Edge, Firefox, IE, Opera, and Safari.
Respectively, these are built on Chromium, Chromium, Chromium, Firefox, deprecated by its publisher in favor of Chromium, Chromium, and the engine from which Chromium forked.
In theory, it costs less to support web applications on Chromium, Firefox, and Safari than native applications on Windows, macOS, X11/Linux, iOS, and Android.
Browser cache is controlled partially by the pages.
A web appl
Re: (Score:2)
A web application can offer too-frequent updates. A native application can also offer too-frequent updates.
But one of those is:
a) Invisible to users, and
b) Guaranteed to happen.
Re: (Score:2)
Several native applications also have background updaters that are all but invisible to users. And when a native application fails to update, that doesn't mean you can still use the old version, especially if the application's purpose is communication. Continuing to use the old version of the client with the new version of the server can give a "server uses protocol version" error, as the Quake III Arena client calls it.
Say a service offered a web-based client without charge but required a subscription to u
Re: (Score:2)
Many people are using old/obsolete versions of browsers, which means not only is one writing for multiple platforms but one is also writing for multiple versions of multiple platforms some of which may be insecure and if you don't allow people to use their preferred platform, they may not use your service
Modern practice seems to be to write to Chrome, using Google's Special Features, and if you choose to use something else f***u. Sounds sort of like IE in the bad olde dayze. Feels like there should be some attention by anti-monopoly people to the situation. Especially considering that to a first approximation everybody uses Chromium (if not Chrome itself) except for those few who like FF or one of the Webkits.
Or, you know, make it like the bad olde dayze and the others (basically, Firefox and Webkit) have t
Re: (Score:2)
>
I've yelled at a couple of companies whose web site simply says, in effect, "use Chrome or f***u" - to which I've replied: "you don't need my business."
What are you asking them to support? Internet Explorer 6.0? Firefox and Safari will probably work just fine (unless they use WebGL in which case Safari won't work)
You're 100% correct when you say they don't need your business. They'll do just fine without people like you.
Re: (Score:2)
Many people are using old/obsolete versions of browsers.
Not true. Browsers have been auto-updating themselves for many years now.
Re: (Score:2)
CDNs just mean one doesn't have to go half way around the world to get the content. One still has to get data from the CDN
Not true. If everybody uses the same two or three CDNs then there's a high probability of already having the files in your browser cache.
Re: (Score:2)
Re: (Score:2)
Tell me again why people are blindly using javascript libraries.
The problem is the "blind" part but that wouldn't be cured by having old-fashioned download/install apps.
Re: (Score:2)
Re: (Score:2)
Why would it? Blindly using a library that's compiled into your program wouldn't fix anything.
Don't turn away clients for using wrong OS (Score:2)
Tell me again why people are using web browsers as general purpose application user interfaces
I can think of several reasons:
- To let one application serve users of Windows, macOS, X11/Linux, Android, and iOS. Turning away most of your prospective clientele with "We're sorry; we only support macOS at this time" is a poor choice for most applications.
- To circumvent operating system publishers' application approval mechanisms and policies. For example, a lot of applications used by iPhone and iPad users have to be web applications in order to circumvent App Store Review Guidelines and/or change faste
Web browsers work great (Score:2)
It's worth it to download your entire UI every time when it's a) almost free to do so and b) cuts your support costs by 2/3rds.
People are blindly using JavaScript libraries because that's where the app developers went. They went there because most of the cost of an app is support,
Re: (Score:2)
Re: (Score:2)
Because that is the browsers job.
I am sorry, the modern web browser is no longer a graphical terminal emulator like it was in the mid-1990s but an Application Engine/Language Interpreter
A lot of Apps today is just the browser wrapped in a custom UI to prevent generic web browsing (with perhaps with some necessary security features turned off)
We can be Mr. Grumpy and say how the web is now so corrupted today. However, your browser is now the interface layer on a multi-tier application. Needing to run its o
Desktops no longer majority of web clients (Score:2)
If you remember pre-JS days (with your low ID you probably do) Web Sites forms use to have to reload and resend all the data and refresh the full screen for anything that needed logic checking.
It was progressive enhancement. And we liked it. There were fewer necessary client-side moving parts, which meant less opportunity for something to silently fail with just a throbber spinning indefinitely. There was less opportunity for pervasive third-party surveillance of viewers' interests. There was less opportunity for nonfree software to run automatically on a machine [gnu.org].
Most people desktops are overpowered
Even if all desktops were overpowered, most people aren't using desktops anymore. The majority of web use occurs on laptops and smartph
Speed of rebooting on conventional HDD (Score:2)
What annoys me is that I can't buy a notebook with a rotating drive unless I look at some really high-end models. In a notebook, I'm more interested in drive capacity than speed of access.
Then I guess my use patterns must differ from yours. I bought a Dell Inspiron 11 3000 series notebook with a rotating drive a couple years ago. Rebooting from my primary operating system (Xubuntu) to Windows 10 to use one application, and then rebooting back when done, took minutes each way. It took a Samsung SSD to make dual booting not unbearably slow.
Re: (Score:2)
I got my start writing javascript to dynamically update select boxes back before AJAX, back before libraries, back before everything. You still see these around - I mean in general, not the ones I made. Car parts sites still have them. Select boxes for make, year and model - as you select each one, the options in the next box changes. That was a nightmare - no two browsers implemented javascript in the same way.
But you are answering the wrong question. I know why javascript exists. I don't know why br
Re: It doesn't have to be this way (Score:2)
Momentum. Initially, they didn't know better. Then, just as we were starting to see some traction to reverse this, Web 2.0 hit and everybody started using third party libraries and CDNs. Now, much of the web is broken without it, so anyone who disables it has a painful experience.
Is it so hard to write a javascript implementation (Score:2)
that allows disabling every mouse event and it is enabled by default?
Re: (Score:1)
Who cares, use the dang 'a' tag ya dingus.
Re: (Score:2)
Re: Is it so hard to write a javascript implementa (Score:2)
Well, you're gonna get stuck at "I am not a robot" captchas. And navigation will be spotty. For example, lots of links in AWS aren't real links, they're click handlers. It's not consistent even within a single site.
By disabling mouse handlers, you're not providing a usable experience for non-technical users, and for technical users, you're better off just turning off JS (third party or even all of it) entirely.
link is broken (Score:3, Informative)
It is for fraud prevention so shut up & send d (Score:3)
"ensure that Stripe.js is loaded on every page" (Score:5, Insightful)
The author noticed the extra data flow, but why did he load Stripe.js on any page other than his payment page? This is part of the disease of modern web development: 5kb of content, 5mb of extraneous JS libraries.
Stripe claims they are monitoring for fraud, but it's frankly hard to see how tracking viewed web-pages is going to help them do that. The lack of clear disclosure is worrying. Bet: it's all about gathering and selling customer data. Since they are active in Europe, I wonder if they've thought about the GDPR consequences of this?
Re:"ensure that Stripe.js is loaded on every page" (Score:4)
That's how google's current recaptcha implementation works. If you only include it in one page, it is supposed to be less reliable than letting it monitor how the user/bot browsed to get to that page.
So, if you wanted to detect a scammer, you would get much more data on their behaviour if you tracked them through their browsing, not just a checkout page. A scammer with a stolen card will probably have different browsing habits than the average person, while they can't really do very much different on the actual payment page.
I am not saying whether it is a good thing to have that js all over your site (I actually dislike almost any js on any page), or whether Stripe does not use the captured data in different ways, just that it makes perfect sense IF you are offering fraud detection by user patterns to require patterns across an entire browsing session.
Re: (Score:3, Interesting)
Re: (Score:2)
Huh.... Here is a snippet that you may not of thought of...
window.parent
Re: (Score:2)
Re:"ensure that Stripe.js is loaded on every page" (Score:5, Interesting)
Keeping to Hanlon's Razor, my bet is one of two things:
1. It really is intended for fraud prevention, and the incompetence lies primarily in the lack of communication to customers how & why it is built the way it is; or
2. It's just really shitty code that calls home all the time just because the dev team didn't think through what they were doing, were just doing the quickest thing that met a requirement, and the company has no mechanism/staffing to truly vet the implementation.
Based on my experience in corporate applications, I suspect #2 might be closest to reality. Could also be a combination of the two.
Re: (Score:2)
At this point, is there any other explanation than 2?
Unless you're writing completely original code that doesn't use more than long-existing standard library for your programming language most places are using many libraries and cut and pasted code none of them understand well.
Re: (Score:2)
At this point, is there any other explanation than 2?
Sure. asylumx helpfully explained it in a comment above. It was labelled "1.".
Re: (Score:2)
A big issue is that there is this tracking of users, ostensibly for anti-fraud reasons, that isn't declared. Throw in the data reselling for ad purposes and under GDPR law, the site owners can be prosecuted and fined for this, and they wouldn't even know it had happened in the first place.
Re: (Score:2)
Re: (Score:2)
The assumption that the data *is* being resold is what I take issue with. There is no evidence that is the case, and it requires the assumption of malice where the situation can adequately be explained by incompetence.
If you've learned nothing about the internet in the past 20 years, it should have been that you can assume your data is being sold or rented unless it can be proven otherwise. Yes - I said "guilty until proven innocent"
Re: (Score:2)
Yes - I said "guilty until proven innocent"
"Your paranoia is not our problem."
My businesses don't sell any customer data. We have no reason to; our business model is the terribly old-fashioned "make something useful and charge real money for it". Various services we in turn use also operate on that basis and also have no reason to sell customer data, nor does anything in their terms or privacy policy suggest that any of them wants to.
I think you are mistaking the hostile actions of a relatively small number of relatively high-profile businesses for
Re: (Score:2)
My businesses don't sell any customer data. We have no reason to; our business model is the terribly old-fashioned "make something useful and charge real money for it". Various services we in turn use also operate on that basis and also have no reason to sell customer data, nor does anything in their terms or privacy policy suggest that any of them wants to.
If you explicitly describe this lack of surveillance in your own privacy policy, you're fine. Stripe, on the other hand, states in its privacy policy that it allows third-party adtech to surveil viewers of covered websites.
Re: (Score:2)
If you explicitly describe this lack of surveillance in your own privacy policy, you're fine.
Well, no, we don't. We consider it the default, and since we aren't disclosing selling that data to third parties, isn't that how it should be if nothing else is stated?
Stripe, on the other hand, states in its privacy policy that it allows third-party adtech to surveil viewers of covered websites.
It does? I've never noticed anything like that. The relevant section seems to be here [stripe.com] in their main privacy policy, and currently contains no mention of sharing data with adtech businesses that I can see. There is mention of using that sort of technology on their own sites in this section [stripe.com], but that seems to be quite different. These appear t
3.c. Interest-based advertising (Score:2)
We consider [not sharing] the default, and since we aren't disclosing selling that data to third parties, isn't that how it should be if nothing else is stated?
It can still be better for the avoidance of doubt to reassure users of how your "default" practice differs from what has become common elsewhere:
"We don't sell your activity history to third parties. Nor do we use any mechanism that lets third parties, such as analytics or advertisement providers, collect your activity history on this site."
I've never noticed anything like that.
Scroll down to 3.c. For your convenience, I shall quote it below, with my emphasis:
Re: (Score:2)
As I observed in response to the other poster who raised this point, it seems clear that that paragraph was intended to apply to Stripe's own systems, not those of its merchants. Using Stripe.js, the end user is only ever on the merchant's site from their point of view, not "visiting" anything of Stripe's, so it seems a stretch to interpret the wording of that clause as giving any sort of consent of disclosure for data sharing based on what a user does on a merchant's site. To the extent that there is any s
Blocking the EU to avoid article 27 obligation (Score:2)
Throw in the data reselling for ad purposes and under GDPR law, the site owners can be prosecuted and fined for this
Not if a website hosted outside the EU has geoblocked the EU as a whole. This may have happened out of a site not having enough traffic from the EU to justify the cost of hiring a representative pursuant to article 27.
Re: (Score:2)
Dunno, it's hard to see how it could just be poorly thought through. I've programmed webshops, and I expected that to happen precisely when I built the the transaction info and said "go". If contact is happening at other times, then someone is packaging up info and sending it. Hard to see how that can be an accident or an oversight.
Re: (Score:2)
Yea, I can get behind point 2. Makes sense from a captcha-esque point of view or as a way to figure out how visitors use your site.
Point 3 sounds sketchy, though. Probably means your site violates EU privacy laws if you use Stripe. Same reason EU website operators had to remove or neuter Twitter/Facebook/etc. buttons. AFAIK the website operator, not Stripe, is responsible for making sure stuff they integrate complies with privacy laws.
Re: (Score:3)
TL;DR: they're both responsible (and liable).
In more detail: first it's necessary to determine whether Stripe is a data processor or a data controller with respect to the data it receives. My take, although it's a spot analysis rather than a detailed one, is that it seems that Stripe determines the purposes and means of processing, so is a data controller under GDPR 28.10. But even if it's
Re: (Score:2)
Liable for what? Monitoring for fraud is clearly a legitimate interest of both parties you mentioned. Personal data can be processed on that basis without explicit consent, as long as the balance with protecting the interests of the subject is reasonable. That in turn is very likely to be the case here, as long as the data is being collected securely and processed only in a way that would make a material difference only to a user who is reasonably suspected of being hostile.
Re: (Score:3)
Except for that "we may sell this data to advertisers" part...
Re: (Score:2)
What "we may sell this data to advertisers" part? I linked to the privacy policy I see from here in the UK, and there is no indication of anything like that being done through this mechanism. Not only that, but a founder and senior exec at Stripe is now on public record saying this hasn't happened and won't happen, and that any necessary legalese wording will immediately be clarified accordingly. Maybe some of you are seeing something in another document that is shown elsewhere in the world?
Re: (Score:2)
It's in TFS.
Re: (Score:2)
That seems to relate to Stripe's own facilities, though, not to hitting Stripe via a visit to one of their merchants' sites, which is what we're talking about here.
However, I assume any slight ambiguity there is what the documentation is going to be updated to clarify.
Re: (Score:2)
What part of "or online services" are you having a problem understanding?
Re: (Score:2)
The part where you are "visiting". If you're using Stripe.js, you're staying on the merchant's site, and contacting Stripe directly from your own system. You're never on Stripe's own site, from the customer's perspective.
That section was clearly intended to refer to visitors to their own systems, not a merchant's, and may have unintentionally been left slightly ambiguous, which they're saying they'll fix.
Re: (Score:2)
Stripe claims they are monitoring for fraud, but it's frankly hard to see how tracking viewed web-pages is going to help them do that.
Not if you have any idea what you're talking about, it isn't. Please don't fan the flames and spread misinformation like this. It's entirely counterproductive.
The knee-jerk reactions throughout this thread are disappointing. Yes, Stripe could have done a better job of disclosure, and their founder has admitted this and stated that they will immediately clarify their legal docs accordingly. But it wasn't a secret before; I've used Stripe on a business website and was well aware of their recommendation and th
following the user even on pages without Stripe (Score:2)
The author noticed the extra data flow, but why did he load Stripe.js on any page other than his payment page?
He didn't. He is pointing out that Stripe is following the user even on pages that don't have Stripe loaded.
From the summary:
After successfully implementing my app's payment flow with Stripe, I noticed that every page navigation generated a new HTTP POST request to a Stripe URL. This was strange because none of the pages I visited contained any calls to Stripe's library.
And from the article:
Who’s affected?Stripe collects this data on your website if either of the following is true:
Your bas
Re: following the user even on pages without Strip (Score:2)
Just because he wasn't making any calls to the library doesn't mean it wasn't loaded on the page.
Re: (Score:2)
"Stripe claims they are monitoring for fraud, but it's frankly hard to see how tracking viewed web-pages is going to help them do that."
Fraudsters will get stolen credit cards and have macros that fill a shopping cart the same way every time in milliseconds. Tracking that activity can be useful in determining what is natural shopping/browsing and bot driven.
Just like Google does every day then? (Score:2)
Move along, nothing to see.
That is what your get for using remote Javascript. (Score:3)
Good Case (Score:2)
No matter what you do tracking can and will happen. There might be at least partial justification here as fighting fraud is a legitimate purpose.
When tracking does happen and might have to happen or has a possible justification what can we do to address the risks that come with that?
We have s
What idiot engineer... (Score:2)
Never mind the security issue, loading the same files on every page is just lazy and bloated.
(PS - I know there is a caveat here for SPAs, since technically they don't have 'separate' pages in the same way. Might be worth it to do a separate 'real' page reload to cordon off Stripe.js from your main app.)
Re: What idiot engineer... (Score:2)
You obviously have no idea how caching on the web works. This is both an efficient (in terms of bytes downloaded) and performant (in terms of pre-fetching code) approach.
Targeted marketing (Score:1)
We should have a law that:
1. all marketing should be in the form of physical flyers. No online marketing
2. the previously mentioned marketing flyers should not be glossy paper and fully flushable.
Running low on T.P. over here guys.
Sinister (Score:2)
This is normal (Score:2)
So, yeah, Stripe is being invasive and
Re: (Score:2)
The kind of "normal" behaviour you describe isn't really normal any more, not least because it's illegal in a significant and increasing fraction of the world. People got fed up with the endless tracking and hassle, and legislators have started to respond.
What Stripe is doing is quite different in intent to most of the other services you mentioned, though, and is likely to still be allowed even under new privacy laws as a result.
Stripe implements de facto-standard anti-fraud. (Score:2)
News at 11.
Seriously, this is not new [google.com]. Splunk even advertises it [splunk.com] specifically as a potential application of their logging software.
Collecting Information from Users (Score:2)