Stripe is absolutely logging your mouse movements on websites' payment pages – for your own good, says CEO Stripe CEO Patrick Collison insists his company's collection of e-commerce customers' site interactions, mouse metrics, and identifiers is solely for fighting fraud – though he allows that the payment platform's disclosure could be better. On Tuesday, developer Michael Lynch questioned Stripe's data collection in a blog post, …
Wow. Okay, let me just, for a second, imagine that this argument is actually honest. So present, in a no less than five pages, an explanation of how recording my mouse movements on any of your web pages can lead you to define my activity as fraudulent.
Next, outline what it is you do with that data when you have defined that my activity is not fraudulent, and oppose it to what you do when you define that it is.
Then, in no less than two pages, explain what gives you the right to implement these measures when you are not requesting my permission to record this data.
Finally, explain how you expect to escape GDPR fines when it is proven that you are doing all of that without consent, without warning, and in total violation of privacy rules.
Oh, and for bonus points, explain why it is that Amazon does not need to use that technology even though it is making billions more in transactions than you are.
GDPR (most probably) does not apply, because the data collected for the model training do not contain personally identifiable information. The model is trained not to tell your mouse movements from my mouse movements, but to tell a bot imitating mouse movements from you or me actually making these movements. At least that's what I understood from their explanations.
1) They’re using it as an indicator that the ‘person’ using your credit card details is either human or, in future use cases (see point 3) that it’s a high probability it is you. It will be one of a number of rules / scores / variables used to determine whether to proceed with the payment.
2) depends on use case. If i want to use it to prove it’s you, i store it (hopefully securely) against your identifier & reuse again to prove it’s you when you buy something else. I may in future share this information with your card issuer’s ACS (3D secure provider). if just anti bot, I store (hopefully securely) as input to the AI or whatever. If i think its not you, i decline the txn, hopefully securely store data & use to train AI.
3) Right to..... tricky, but fraud prevention tends to have carve outs. Need to.... PSD2, FCA have opined that behavioural biometrics must be available as a factor for strong customer authentication. The card payments ecosystem therefore have to do this. for it to work, it needs data. payment pages alone are data point poor. to work effectively more data needed. There will need to be interaction between merchants, acquirers, issuers & all their supporting providers to make this work - the EMV 3DS protocols makes it hard if not impossible for issuers to do it alone.
4) GDPR - good point, kinda hoping the regulators have this covered (PSD2 Europe wide) as they’re the ones driving a lot of this.
5) Amazon is a merchant. Stripe is a payment processor. Amazon are actually shit hot at fraud prevention, & have invested in a whole suite of tools to spot & prevent (i.e. decline the transaction). Stripe’s market tends to be smaller outfits who don’t ‘get’ fraud (not a criticism btw) nor have the ability to invest in the tools individually - they use what their payment processor offers them.
Amazon may well go down this route (see point 3), just not yet.
Not the required number of pages I’m afraid & so a bit broad brush, but that’s kinda it. I don’t work for Stripe, I do work in payments & have been on PSD2 for the last 3 years - there is a lot of detail chock full of devils, this is one of the biggies.
Well, I hope you and your colleagues are getting busy on how to replace this with an alternative fraud protection scheme which is clearly visible, stores no private information and gets pre-approval from the user.
Because, now it is known, I will certainly be taking counter-measures and I am sure we will soon see the equivalent of the canvas and audio fingerprint defenders being created for this. Personally I have removed stripe.js from my whitelist and will now only enable it for a very limited time and only on payment pages (like I do with some other payment providers who I already did not trust).
Of course, a vendor is welcome to then disallow me to purchase from them. If they can afford the hit to their revenue stream from disallowing all of us who turn on these blockers.
Sorry, but fraud protection does NOT magically override privacy or other considerations unless you get prior, informed approval.
If anyone at El Reg fancies trying to get in touch with Mr Collison, ask him if he's comfortable with sending all of the data (the kind which Stripe collects from website users) from his and his staff's computers to me. I pinky promise it will only be for fraud prevention.
"Wow. Okay, let me just, for a second, imagine that this argument is actually honest. So present, in a no less than five pages, an explanation of how recording my mouse movements on any of your web pages can lead you to define my activity as fraudulent."
I could answer that.. a machine learning system would be set up to classify transactions "fraudulent" or "not fraudulent". Initially the system would be trained, it's fed in initial data and told which transactions ended up being legit and which fraudulent. After initial training, a well-trained ML system really is quite good at pattern matching especially for a categorization problem like this. I imagine in some cases fraudsters are either using scripts and this would be easy to detect (jdownloader has a captcha-box-checking script in it and the mouse movement to click the box does not look at all like a natural mouse click or tap), otherwise (even if it's a human) they probably do in fact navigate the site differently if the goal is to order some items on stolen cards versus anyone naturally using the site.
"Next, outline what it is you do with that data when you have defined that my activity is not fraudulent, and oppose it to what you do when you define that it is."
That is an excellent question, to me this is the $1000 question. I actually believe stripe about the fraud detection, but I'd definitely prefer data was not retained indefinitely. If chargebacks can be done for 14 days, it'd then take up to 14 days to know a "non-fraudulent" transaction was really fraudulent (false negative), or for someone to complain their legitimate transaction was denied (false positive), so maybe they'd need it for 14.1-30 days or so, but not indefinitely.
"Finally, explain how you expect to escape GDPR fines when it is proven that you are doing all of that without consent, without warning, and in total violation of privacy rules."
Yup, that's a major problem for them for sure.
My bank 2FA doesn't need it, my email 2FA security doesn't need it, most fora that matter don't use it, & reputable shopping sites don't need it, so do yourself & the world at large a favor by dropping it.
It's a security hole that makes Adobe Flash player look positively airtight by compairison.
I refuse to run it, it's blocked at the browser & never... N. E. V. E. R. ...allowed to run, not merely plug in controlled per site, but *never*, & if you insist on using it then you insist on refusing my money gracing your coffers.
I realize I'm just one little peon, but it's peons like me that offer shopping advice to friends, family, coworkers, & all those random strangers that ask questions like "What's a good $Widget & what's the best place to get one?" ... I answer "Not from $SiteThatUsesJS as they're a security hole just waiting to screw you over." Guess which sites they now avoid like the plague?
So don't discount us peons, we're the ones that matter when your own advertising isn't good enough to even get their notice.
PCI-DSS auditors need to do their job and request proper documentation that every bit of Javascript on a payment page is properly audited. The stilly mouse tracking thing goes nuts with my trackball which appears to confuse their code. The stripe code seems to have been written by someone who uses tabs and not windows because all the stacked windows will be sending data at the same time.
Quite apart from the inherent hazards of javascript (and there are many) "don't do anything critical or sensitive client side as it can be tampered with" is such a basic principle that it's amazing anyone is still doing this. In fact almost everyone is doing it, and it contributes to fraud. If you want evidence, take a look at the BA breach.
In this case, even if the client side code doesn't get tampered with I expect bots to swiftly adapt to simulate legitimate user activity, nullifying the intended benefit.
I'd also add that it is the end customer's behaviour that is being profiled, but the alleged benefit is for the merchant. In other words, it's not for your own good, but for someone else's.
I wonder how many people with impaired motor skills or using screen readers or other assistive technologies are going to be denied service because of their "unusual" behaviour patterns.
*Raises hand in disgust* I'm one such person.
I don't use a mouse at all, don't even have one plugged in, so any attempt they make to monitor the movements of said device automaticly fail. Since I'm on a desktop browser & not a tablet nor SmartPhone, their algos insist that I have a mouse (or other pointing device). None of them seems to give two shits if their algo doesn't account for folks that don't use a pointing device for any reason, they just pop up the message "You're a bot. Go away." & deny us the ability to go any further.
I try to call their help line to complain, but it invariably wastes my time, breath, & already dwindling supply of dried frog pills. =-j
If you want evidence, take a look at the BA breach.
With all due respect this shows a lack of understanding of how that attack worked. The Reg even posted a screenshot of the malicious script:
https://regmedia.co.uk/2018/09/11/ba_suspicious_script.jpg
As much as this is a .js (client-side JavaScript) file, modifying it required access to BA's web server which is proven by the fact it's hosted on britishairways.com which is clear on the screenshot. If someone has access to modify files on your web server then even server-side validation code could be modified.
It's true that the attacker in that case set up a fake domain (baways.com, also shown on the screenshot) to post form data to. But the actual script where that was occurring (modernizr-2.6.2.min.js) was hosted within BA's own legitimate webspace. So someone had access to be able to modify that, which at that point is a server-side breach.
The issue you're describing is when people serve JS from untrusted third party domains. But that isn't what happened in the case of BA.
Just plug an hdtv on an off the air, rabbit ear anttenna close to your wifi enabled computer, tune into an off the air channel, and watch the reception go wuzzy as you mouse around most web pages, if you don't have a fancy sniffer. Clearly all activity is being monitored and wifi-ed down the rabbit hole for some purpose that you haven't given explicit permission for, and why should you?, even when you are not clicking a link, just mousing or typing. How much of this constant wifi broadcasting data is actually safe? How many other JS libraries are doing it, or is it just built-in to the Browsers themselves, or in fact Windows itself (which it appears to be, even when using notepad)? Should I feel important, that some control knob wants to record all my activity? Building a personality profile on just what patterns are exhibited by simple things as mouse gestures and keystroke timing? Will I get a summary report of my personality type when the server is bursting with my data?
What are you on about? 'wuzzy' TV reception as a benchmark for the amount (?) of data broadcast from your computer over wifi? Specifically related to mouse movements?
There is so much wrong about your understanding of these technologies that this must be a joke... a poorly worded joke...
We had Stripe payments implemented on one of our websites about a year ago and we were aware of this because it's clearly stated in Stripe's own developer docs. Did your blogger Mr Lynch not actually read those?
It is true that the docs recommend that stripe.js be included on every page so that it can gather up so-called behavioural (i.e., mouse movement) data to do the captcha thing (this is the same technique used by Google's hideous captcha forms).
Because we actually care about privacy, what we did is that the library is not loaded until after the user clicks on the "Pay" button. The library is unloaded again when the user moves away from the checkout page and all this is documented in the site's privacy policy.
I think the point is, given the context of the article, is that website user/ customers do not typically go around reading the developer docs for all the scriptyness implemented on the website. Just because you ensured you did exactly the right thing does not make Stripe's process more transparent or privacy-respecting in the general case.
I really wish before people came out with this "all JavaScript is evil" nonsense they would actually understand how it works.
It's possible for anyone to see HTTP requests in their browser by using the Developer tools (F12 in Chrome) and then opening the Network tab. Any data which is being sent is shown in the Request section. This is the case for any website and any request including ajax requests which are commonly made through JS libraries.
So, all these people moaning have tried it on a site where Stripe.js is present on every page? What did you see in the Request data that "logs all your activity"? Oh, you haven't, and it doesn't. I know this because I've done it myself.
It does send some data aside from for the payment, including a timestamp of how long you were on the site. But that is legitimately useful in combatting fraud as it could identify a bot submitting card data, amongst other things such as geolocation details.
I've already replied on a previous comment where someone was trying to describe how they thought JS was to blame for the BA attack. A total lack of understanding of how that actually worked (I've explained it in my reply).
I recently tried to open an account at Digital Ocean. Stripe handles their payment processing. During the account creation there were nearly 50 scripts running from third parties, including Googles captcha and Stripe. After I created my account, I felt pretty violated and immediately closed my account and took my hosting business elsewhere.
I use a pre-paid electricity meter that is topped up on line with a card number and the meter is credited (somehow) over a mobile phone network. Up until recently Stripe has been involved in the payment process, "remembering" my details. However, the company running the meter seemed to have mysteriously ditched Stripe without any announcement as to why and I now have to enter all my details on line when I need to top up the meter. Wonder if there was a problem with Stripe that nobody's telling?
We are having the same discussion right now about COVID-19 response: martial law verse civil liberties in virus response. It would be interesting to see how many of the "no tracking of anything" absolutists are the same ones vociferously attacking anyone raising civil liberties interests. But to the issue at hand, I worked for a while at Whitepages.com. While I was not directly involved with the fraud detection work, I was aware enough to be able to make the following points:
The online retail industry would go up in smoke if they were unable to effectively detect most fraudulent activity.
The ad industry would go up in smoke if they were unable to effectively detect a significant amount of fraudulent activity.
If your credit card shows up on a new site with a shipping address in a different county, that's a red flag, right? And to detect this (and minimize false positives), we need to...follow your every transaction across the web. Yeah. Fraud detection uses EXACTLY the same information as the ad networks.
It's not about data collection (mostly). It's about the handling of that data. If it is in fact being used for fraud detection? Fine. If it is being used for first-person marketing? I'm pretty much okay with that. There are genuine tradeoffs here. But when it comes to how the data is stored, and how easily some one who steals that data can make use of it, I'm pretty much an absolutist.
But we really do want fraud detection stuff if we want to do retail on the web. TANSTAFL
Many companies start with the good intentions for collecting data for the sake of progress or security. The temptation, however, is strong to monetize that data. There are solutions that provide simple (but unattractive) non-Google captcha texts, but the security is pretty weak. In fact, most solutions rely on full website monitoring since front-end human verification is pretty weak. CyberSiara claims to offer a solution to the front-end which is unbeatable by bots, which would reduce the need for full website monitoring, potentially eliminating it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
