Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Privacy The Almighty Buck The Internet

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.'"
This discussion has been archived. No new comments can be posted.

Stripe Is Silently Recording Your Movements On Its Customers' Websites

Comments Filter:
  • by Joce640k ( 829181 ) on Wednesday April 22, 2020 @05:06AM (#59975522) Homepage

    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.

    • by AmiMoJo ( 196126 ) on Wednesday April 22, 2020 @05:31AM (#59975556) Homepage Journal

      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.

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

      • by epine ( 68316 ) on Wednesday April 22, 2020 @01:07PM (#59976864)

        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:

        Hi ddevault—we would like to do this, and I'm very supportive in principle (and, per GP, we are perfectly fine with anyone not using Stripe.js), but our current product/engineering focus is on trying to build better tools for the businesses who are losing tens or hundreds of thousands of dollars to fraud.

        We think we have to first help the businesses who need help immediately. We'll probably then circle back to build products that explore more points on the [efficacy of fraud prevention] – [PCI burden] continuum.

        Here:

        Definitely no dismissiveness intended—apologies.

        While Stripe has been in business for 10 years, Radar (our fraud prevention tool) has only existed for 3.5. We've made a good deal of progress in that time and I would guess that it's 1–2 years away from being sufficiently complete that we can start to seriously focus on things other than fraud. (As it happens, I just had a conversation about this with the guy who leads it.)

        Here:

        I'll ask our legal team if we can somehow contractually preclude ourselves from sharing this data in the case of liquidation or otherwise bind ourselves in a useful fashion ...

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

        Here:

        This is a fair call-out. We have actually worked pretty hard to ensure that our Privacy and Cookies policies are clear and easy-to-read, rather than filled with endless boilerplate jargon.

        But we still did make a mistake by not have a uniquely clear document covering Stripe.js fraud prevention in particular.

        Here:

        I apologize that anything about the pricing change felt sneaky. (We tried to do the opposite: we emailed every single impacted customer!) I posted a few thoughts about the refund change [here].

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

        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

      • sounds like pretty shitty fraud protection then if you're relying on client side data. we use stripe but all calls to them are made from the backend, so they are getting zero client telemetry from us.
    • by jellomizer ( 103300 ) on Wednesday April 22, 2020 @08:36AM (#59975892)

      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.

  • by Orgasmatron ( 8103 ) on Wednesday April 22, 2020 @05:06AM (#59975524)

    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.

    • }}} Tell me again why browsers default to blindly executing every bit of javascript that they see? {{{ --- Anyone have an answer to this?
    • 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.

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

      • 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

        • by Anonymous Brave Guy ( 457657 ) on Wednesday April 22, 2020 @08:07AM (#59975818)

          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.

          • 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

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

              • by tepples ( 727027 )

                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

                • 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

        • 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

          • Platforms? In this case, platform means web browsers so Brave, Chrome, Edge, Firefox, IE, Opera, and Safari.

            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

            • 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

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

            • by tepples ( 727027 )

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

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

          • 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

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

              • by tepples ( 727027 )

                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

          • 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

            • >

              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.

          • Many people are using old/obsolete versions of browsers.

            Not true. Browsers have been auto-updating themselves for many years now.

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

        • By the way, never again complain about how much memory a browser uses as you are fine with web pages that have 600Mb of javascript libraries which have to run separate copies of the libraries for each tab because we don't want any cross tab data sharing.
      • 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.

        • For the end user, maybe not. But, as related to this article where the developer/provider is blindsided by a library tracking his customers possibly even after he has said his site doesn't do it, it very much fixes that problem
      • 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

      • as general purpose application UIs. They're easy to fix when they break (just reinstall) and they seldom break. I support several web apps for a living and compared to the desktop apps there's about 1/3 the support demand.

        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,
    • For Chrome users, uBlock Origin added a javascript blocker to their adblocker. If you click on the UO icon, it's the </> symbol in the bottom right. Click it to disable javascript on that site. You can also change it to block javascript by default in the settings if you like.
    • 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

      • 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

      • 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

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

  • that allows disabling every mouse event and it is enabled by default?

    • Who cares, use the dang 'a' tag ya dingus.

    • I feel like this (interpreted literally) would break a pretty large number of sites; need to at least whitelist primary mouse click/mouse down/mouse up.
    • 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)

    by dagooncrn ( 618659 ) <mg@fork.pl> on Wednesday April 22, 2020 @05:52AM (#59975568) Homepage
    Main link is broken in this story (copied from previous one). The proper one is https://mtlynch.io/stripe-reco... [mtlynch.io]
  • by tronicum ( 617382 ) * on Wednesday April 22, 2020 @05:54AM (#59975572)
    yeah. we need more data, so do as we say its for your own good as we need to detect any fraudster and we do that by recording just everything. no need to explain what we do as long as you get money, right?
  • by bradley13 ( 1118935 ) on Wednesday April 22, 2020 @06:01AM (#59975586) Homepage

    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?

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

      by yassa2020 ( 6703044 )
      This. I had no reason to suspect anything foul of the script, but I not only restrict it to just the checkout, I keep it in it's own little iframe on the checkout page so that it can't even scan the rest of the checkout page, all it can see is the credit card markup. I did this because it is basic hygiene.
      • Huh.... Here is a snippet that you may not of thought of...

        window.parent

        • iframes have a separate security context. I suggest you do some reading up on it because it is too complex for me to explain here.
    • by asylumx ( 881307 ) on Wednesday April 22, 2020 @06:47AM (#59975648)

      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?

      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.

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

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

        • by asylumx ( 881307 )
          It's certainly an issue and creates an opportunity for abuse -- my comment doesn't argue against that. 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.
          • by thomn8r ( 635504 )

            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"

            • 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

              • by tepples ( 727027 )

                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.

                • 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

                  • 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:

                    c. Interest-based advertising.

                    When you visit our Sites or online services, both we and

                    • 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

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

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

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

      • by pjt33 ( 739471 )

        AFAIK the website operator, not Stripe, is responsible for making sure stuff they integrate complies with privacy laws.

        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

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

          • by sconeu ( 64226 )

            Except for that "we may sell this data to advertisers" part...

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

              • by sconeu ( 64226 )

                It's in TFS.

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

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

                  • by sconeu ( 64226 )

                    What part of "or online services" are you having a problem understanding?

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

    • 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

    • 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

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

  • Move along, nothing to see.

  • Not only are people bloating their websites to be larger than Windows 95 [dev.to], they have no idea what the code is actually doing. Sure, one knows what the provider says it does but the fact is, it could be randomly serving up code that steals data, distributes malware, or tracks users and one would never be the wiser.
  • I've got a long time been trying to explain to people that data protection laws are still woefully inadequate. Quite often they attack the means to block tracking at all rather than what could go wrong with it.

    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
  • ...is going to load their .js file on EVERY page, just because they 'recommend' it?

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

  • What is with all the "silently" lately? Should we get a big bright popup alert for every line of JavaScript that executes?
  • Not saying that it's good or bad, but this is normal. Nearly every commercial website you visit will have a number of 3rd party pixels or javascript snippets on every page of the site. They're executed or loaded on every page load, passing your referrer, user agent, IP, and other information. Search engines, social media, payment processors, product recommendation engines, affiliate systems, all have scripts that give them full info about their client's browsers.

    So, yeah, Stripe is being invasive and
    • 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.

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

  • that a reasonable person would not expect to be necessary for the function of the app should be illegal. For example, if I give you a key so you can deliver a package inside my front door, that is not permission to go through the drawers in my bedroom. Vague, overly general statements in the fine print of a privacy policy are not acceptable.

Utility is when you have one telephone, luxury is when you have two, opulence is when you have three -- and paradise is when you have none. -- Doug Larson

Working...