Recently on the r/dotnet Reddit community, a new post has been published with an alarming title: Does Moq in it's latest version extract and send my email to the cloud via SponsorLink?.
Since then, there have been a lot of discussions around it, but what is this all about?
Starting from the beginning
To gain a proper understanding of the situation, let's begin by providing an overview of Moq itself.
Moq was is a popular .NET mocking library that has accumulated over 475.7 million downloads as of now.
For more than 10 years, Daniel Cazzulino (or @ksu) has been diligently building and refining it.
When comparing it to one of its most well-known alternatives, NSubstitute, which has "only" reached 85.6 million downloads, it is fair to say that Moq is the most widely used mocking library in the .NET ecosystem.
Setting the scene
Earlier this year, @ksu released a new project named SponsorLink in a blog post named SponsorLink: trying something new-ish for OSS sustainability.
The primary objective of this project, as outlined by the author, is to establish a direct connection between projects and your GitHub account:
So the goal of SponsorLink is to connect in the most direct way possible your sponsorship with your library author’ sponsor account. And since the place where you spend most of the time enjoying your fellow developers’ open source projects is inside an IDE (..), I figured that’s the first place where you should be reminded that either
This approach allows sponsors of a GitHub library through the GitHub Sponsorship program to potentially access additional features, receive thank-you messages within their IDE, or more.
However, an alternative perspective on SponsorLink, albeit less flattering, is that the project is capable of identifying individuals running a project containing it by transmitting their email addresses to the cloud.
Worse: it doesn't merely capture your email address; it also extracts all email addresses present in the git history of your project. Depending on your project's lifespan, this could involve a significant number of addresses.
Claims have been made that these addresses are hashed and so forth, but the DLL is closed-source and obfuscated. Given the nature of this project, such practices raise suspicions, to say the least.
In the blog post itself, people raised concerns about its ethical considerations:
What went wrong
By now, you have likely guessed what went awry.
A couple of days ago, @kzu submitted a Pull Request, announcing that SponsorLink was now integrated into Moq, thereby harvesting email addresses of the developers utilizing it in their projects:
Add 💜 SponsorLink support
#1363
See https://www.cazzulino.com/sponsorlink.html and https://github.com/devlooped/SponsorLink
Let's thank everyone who supports the project 💜
This Pull Request received a largely negative reception and prompted a significant number of projects to replace Moq within their codebases.
Shortly after, various issues raising privacy concerns has been opened:
Privacy issues with SponsorLink, starting from version 4.20
#1372
There's a related discussion on Reddit: https://www.reddit.com/r/dotnet/comments/15ljdcc/does_moq_in_its_latest_version_extract_and_send/
It seems that starting from version 4.20, SponsorLink is included. This is a closed-source project, provided as a dll with obfuscated code, which seems to at least scan local data (git config?) and sends the hashed email of the current developer to a cloud service. The scanning is provided as a .NET analyzer tool, which runs during the build. There is no option to disable this.
I can understand the reasoning behind it, but this is honestly pretty scary from a privacy standpoint.
Any chance this can be reverted?
What now?
This update has some questionable points such as collecting the user's data by default without an opt-in/out option (defying GDPR) or adding closed source and obfuscated add-on without any consent of the community.
For now, it seems that people are running away from it and companies are blocking the library. Some are also reporting the 4.20 version, which introduced SponsorLink.
However, it's important to also take into account the perspective of the maintainer, especially given the challenging landscape many open-source maintainers face in sustaining their projects. Open-source maintainers often struggle to find sustainable ways of supporting their work.
In a new issue, the maintainer of Moq expresses the desire to gather feedback on how their Open Source projects could receive better support:
SponsorLink and supporting OSS more broadly
#1374
Trying to aggregate the various issues into one to collect feedback.
I invite everyone to read the SponsorLink announcement to understand the intention behind it. No nefarious purpose, I promise! 🙏. I also wrote a follow-up post with additional context based on feedback so far.
With that in mind, I'm obviously open to suggestions that help achieve both your goals and mine :)
NOTE: 4.20.2 removes SponsorLink since it breaks MacOS/Linux restore. I'll take the opportunity to collect more feedback. The underlying issue still needs addressing, IMHO.
NOTE: SponsorLink won't be coming back until I improve on the suggestions made here. In particular, those mentioned in the announcement on OSS'ing it
Despite the apparent goodwill, SponsorLink remains included in Moq as of now and, I think, its reputation permanently damaged as the implicit trust most people had in it has been broken.
If you are more of a listener than a reader, check out @elfocrash video on the subject, who did a great job summarizing everything:
I hope that you learnt something useful there!
Photo by Jason Blackeye on Unsplash
Top comments (12)
It raises some important questions:
It reminds me of a saying I once heard, "If you don't have to pay for the product, you are the product."
Either way, it sounds like the maintainer won't have to spend their free time working on an unpaid project. ¯_(ツ)_/¯
The thing is, if you start your own open-source project with extremely permissible license you don't expect people to pay or donate for it to make you a lving, do you? You always have the choice to offer additional services (e-mail/phone support, consultations, etc.) or make a paid version of a product with extra corporate-focused features.
I'm not trying to defend people that built multi-billion dollar businesses on top of OSS libraries and products. Just understand that people will not do what they don't have to or should do, unless you make them in the most polite way.
This reminds me of IdentityServer who also made OpenSource code on GitHub but slowly moved towards a different business model, without harming the community nor the trust it has from it
It's sad that it came to this. I don't think the intention was to cause harm or steal sensitive information, but I do believe actions speak louder than words.
What I find problematic is that the PR in question was merged without a single reviewer. How can a library so foundational in millions of repos be held with such little accountability?
What can we do, as a community, to avoid repeating this problem? I don't think the answer is to never trust open source again...
Well, the harm has been done. This all has been done wiith hot needle. I've no idea what was the impulse but it was irresponsiible to change OSS project to data-collecting machine. Moreover it broke MacOS and Linux builds so it was not even properly tested. That raises even more questions about what actually happened that lead to his decision?
Neither do I but sadly the way the
@kzuforced his way into this might not have been the best solutionI get the impression that the general feeling of the community is that it didn't even had the opportunity to opt-out by design, let alone a word on the embedding of SponsorLink into Moq
Sure, there is a deeper problem that needs to be addressed and it's not new at all, but, with this update, I don't know if the community will still be supportive
I personally think that the targeted audience should have been different: SponsorLink seems to target individuals while companies are the ones holding money (look at AG Grid for example)
How exactly is the community supportive ?
What I see is a library used by millions, including corporations, who all saved a lot of time and effort by using someone else's code in their own product, commercial or not.
What I see is those same millions complaining to the sole maintainer of the library, who gracefully provided his many hours of work to them free of charge, that he made a move (maybe not a perfect move) to try and get some financial reward out of his hard work.
What I see is millions of downloaders whose only actions towards the author are to ask for more features and expect bug fixes, but never ever consider paying back for it, in one way or another.
What I sadly only see is users of OSS software complaining that the maintainer is not doing what they want, or is introducing security risks in their software supply chain, or have an inappropriate governance for their project which puts theirs at risk.
Which talented and idealistic developer would still want to contribute a piece of software to the world knowing that, if succesful, the road ahead will look like this sacerdotal hell ?
Those unhappy with Moq can walk away, find a replacement, or better, fork it and fix it themselves, or pay for it, ot help the maintainer, but they should not complain over something that they have used for free for many years.
There's an issue in the Moq repository explaining that SponsorLink is now OSS too, and that 'Future versions of the package will come from there, will no longer be ofuscated, and will also have an OSS license.'
It seems you missed the actual concern. Making SponsorLink OSS is one small issue, but the major issue is breaking GDPR law, which is not just applicable for European Union, but for entire world (at least theoretically) because getting email address, even in hashed form, is illegal without users' consent.
Hi Nikunj
Thanks for raising this point. As you rightly mentioned, it's a violation of GDPR if they get an email address without a user's consent. The following is an excerpt from the SponsorLink Readme:
According to this, SponsorLink only gets your hashed email address 'after you install the SponsorLink GitHub app and give it explicit permission to do so'. The concern expressed in the linked Video is that as a compiled and obfuscated library, there's no way to tell whether this statement is true. However, by opening up SponsorLink and linking to that, it's now possible to see what's going on.
In addition to this, there appears to be an open issue where people are discussing GDPR compliance here
It looks like a step in the right direction
Harvey Dent was right. And I probably have lived long enough already.