React-final-form: Reconsider use of scarf

[slightlytyler]

Hey @erikras

First off I want to say I really appreciate the work you've put into react-final-form. It's apparent this is the premier form library for React atm and I'm hoping to use it professionally in a large existing codebase that needs some forms tlc.

Adding final form as a dep seemed easy enough and it made feature development a breeze but during code review I came across this new dependency @scarf/scarf. Their README does a good job explaining my concern right off the bat:

Scarf is like Google Analytics for your npm packages. By sending some basic details after installation, this package can help you can gain insights into how your packages are used and by which companies. Scarf aims to help support open-source developers fund their work when used commercially.

Even if Scarf is completely harmless and honest in their mission its presence immediately makes this a hard sale. Even disabling it via the package.json is not enough for me to avoid a "fun" chat with our CTO about scarf if I want to stay the course with react-final-form.

Further, there is no discussion in the PR https://github.com/final-form/react-final-form/pull/790. Were these authors or packages telemetry code vetted?

I'm a concerned dev who would love to use this library but unless scarf is removed I will probably opt to use Formik which is comparable if not quite as feature complete. Please reconsider!

[slightlytyler]

Looks like there was a bit of feedback after the fact on the PR for final-form https://github.com/final-form/final-form/pull/342#issuecomment-635281062

[samsch]

Yeah, having the scarf malware as a dep for a library causes an immediate action item for removing that library.

As slightlytyler said, I also feel RFF is the best library for forms in React, but until Scarf is removed, I must recommend strictly avoiding it, or only using a fork with Scarf removed.

[efdee]

As much as I love RFF I will be switching it out for another solution for now. I hope you reconsider.

[tannerlinsley]

_[Redacted]_

Scarf has been removed from all of my libraries following a more granular discussion in the Reactiflux Discord.

[joepie91]

It’s an analytics package that is gdrp compliant out of the box

This seems incorrect to me. Two issues that jump out at me:

1. The default mode of operation is opt-out. That is not GDPR-compliant; for that, it must be opt-in. Unless there's another legal basis for collection and consent isn't required, which is very difficult to defend here - and in any case, the Scarf documentation would need to be much more explicit about what it's collecting, for that.
2. From a skim of the code, rather than collection specific bits of non-identifiable data (which could be defensible, if chosen carefully), it appears to be redacting specific bits of data, defaulting to sending data along, which would include custom fields in package.json. Note that this is based on a skim of the code, I have not verified this in-depth.

Now, that said, if you really wish that Maintainers personally don’t see your company’s name and website on internal lists of users, then just opt out.

That is not how this works. It should be opt-in. It not being explicit opt-in is part of why it's being branded as malware. The only reason to make it opt-out by default is because you know that most people would not realize it or bother changing it, which means you can collect their data without their explicit consent, which, well... you can fill in the rest.

[samsch]

"Programs are also considered malware if they secretly act against the interests of the computer user"

It is not in the interest of server owners to have a package make phone-home calls with information about the system and installation. If this was opt-in, it wouldn't be malware, but because it acts by default, and because it can easily be installed as a dependency of a dependency, it's can reasonably be expected to run secretly (install-time messages are frequently ignored, especially with the added noise of packages asking for donations).

[tannerlinsley]

You'll have to talk to @aviaviavi about the specifics, but as it has been explained to me, none of the data it collects is personally identifiable in any way and because of that, should be GDPR compliant.

[tannerlinsley]

To preface what I'm sure @aviaviavi will explain, I also know that the once piece of data that is used extensively in scarf is the IP address, which if stored, technically falls under GDPR, but this information is never stored. It is cross-referenced to publicly known associated company websites (with their accompanying names) and all other information is discarded.

[samsch]

The GDPR side of this is a strawman. If it fails GDPR, great, the EU's laws are being properly effective, and that's another reason not to use it. If not, it still fails basic security scrutiny, and sends sensitive data secretly.

[tannerlinsley]

"falls", not "fails". The IP address is NOT stored. Just making sure you read that carefully.

[samsch]

My response was not due to misreading. As stated explicitly, I was pointing out the strawman of GDPR, but noting that if the software failed GDPR (which isn't an argument I'm making), that would be an additional problem.

[tannerlinsley]

_[Redacted]_

Scarf has been removed from all of my libraries following a more granular discussion in the Reactiflux Discord.

[aviaviavi]

Hi everyone, author of scarf-js here. I'll respond to some of the points here:

From a skim of the code, rather than collection specific bits of non-identifiable data (which could be defensible, if chosen carefully), it appears to be redacting specific bits of data, defaulting to sending data along, which would include custom fields in package.json. Note that this is based on a skim of the code, I have not verified this in-depth.

Sounds like one of the function names in scarf-js (redactSensitivePackageInfo) may be misleading here, we can update the name surely. But we're not defaulting to sending any data along - this function always runs to transform the raw package details into something that's safe to send, free of any sensitive data. The data is non-identifiable, and has been chosen very carefully, so I'd argue it's completely defensible. I'm happy to talk in-depth about what we've chosen to send, but that may or may not be out of the scope of this discussion here.

"Programs are also considered malware if they secretly act against the interests of the computer user"

There's nothing "secret" in how scarf-js functions. Everything scarf-js collects is clearly written on the README and it logs what it's doing to the console. On top of that, react-final-form clearly states in the install instructions that scarf-js is being used. It's also not even against the interests of the computer user, quite the opposite. By helping open-source maintainers understand how their software is being used, their work can be better supported which enables them to deliver better software to you, the user. Combine that with the fact that we aren't actually storing any personally identifying information here, I don't see how it can be argued that this is either being done secretly or against the interests of the user.

Scarf isn't collecting anything that npm isn't already collecting, the difference is we actually expose this to maintainers in efforts to support their great work, which is directly benefiting your employers' bottom line. All the package authors are asking for here is just a little bit of information to support their work, and none of that information is sensitive.

Even if Scarf is completely harmless and honest in their mission its presence immediately makes this a hard sale.

Can I ask what aspects, in particular, makes this hard in your case @slightlytyler? Everything Scarf is collecting is already being collected by npm (they collect quite a bit more actually!). The difference here is that we expose this information to maintainers, so they are better informed and supported, which ultimately means you, the user, receive better software.

Scarf's purpose is to support open source maintainers, and I hope we can figure out a solution that both helps package authors and is agreeable to users.

[aviaviavi]

That is not how this works. It should be opt-in. It not being explicit opt-in is part of why it's being branded as malware.

By this logic, npm is also malware. Npm collects all of this information and it doesn't have any kind of dialog when you install it or any packages in their registry. Rather, they give notices on their site that they do it, and move on, and you are all using software on their platform anyway. Giving some of that information to maintainers too should not be controversial. npm should be doing it themselves, but they are not. Scarf intends to simply fill that gap for maintainers.

[slightlytyler]

At the end of the day you are installing third party telemetry code on package install. This means it not only goes on my computer but every single developer who works on the codebase. To me, and I'm guessing any CTO or manager I've worked with, this is unacceptable. Scarf is not opted into by developers, so it feels like malware. It's hidden away as a sub dep that I only caught during the diff of the package lock file.

To use RFF professionally I'll need to discuss it and scarf with my supervisor which pretty much means it's dead on arrival. What engineering manager is going to let telemetry code from an untrusted vendor on their dev machines? I'll just pick a package that doesn't feel the need to opt me and my team into data collection

[bdharrington7]

Scarf is not opted into by developers

IANAL, But don't you technically opt-in to using the packages that your package depends on? I feel like there is some onus on the person installing the package to review the dependencies. Still, if a package depends on some analytics package, they should highlight that fact.

[slightlytyler]

@bdharrington7 if I discovered those packages were installing telemetry code I'd have the same problem. I found this issue through vetting because I'm worried about a situation like this

Scarf could be made opt in:

npm install --save react-final-form final-form @scarf/scarf

but I bet that kills user acquisition cus who wants to have to tell their boss they opted the team into data collection

[MichaelDeBoey]

At the end of the day you are installing third party telemetry code on package install. This means it not only goes on my computer but every single developer who works on the codebase. To me, and I'm guessing any CTO or manager I've worked with, this is unacceptable.

@slightlytyler This would mean no CTO will every use gatsby, as they're having telemetry (like Node version that's used, ...) enabled by default too.

[samsch]

@erikras Can you hit this package too, as well as redux-form (and any others, I'm going by the dependents list for the package on npm)?

[erikras]

@samsch Are you proud of how pushy you're being? How many dollars have you donated to Open Source this month?

[samsch]

If you'd like to join a more conversational place, you can in Reactiflux. It's the current topic in #news-and-links.

[erikras]

Published RFF fix in v6.5.1.