Devlooped.SponsorLink analyzer should not contain obfuscated code

[sharwell]

See the title. Users need to be able to understand the code being injected into a build. This is important for transparency and trust.

[kzu]

That would make it trivial to bypass the SponsorLink check. So, this is by design at this point unless there's serious concerns raised by a large portion of users.

[NickMOrlando]

That would make it trivial to bypass the SponsorLink check. So, this is by design at this point unless there's serious concerns raised by a large portion of users.

What constitutes a large portion of users?

The introduction of this package into Moq has spawned a significant number of concerns over that package's viability in any F/OSS or Corporate environment.

[CryoMyst]

Developers are not going to accept telemetry without transparency.

[Atulin]

"Trust me bro" isn't much of an assurance when it comes to running arbitrary code on the user's machine.

[cygnim]

@kzu I'd say serious concerns have now been raised. The vast majority of users don't even know this change has been made and would have a problem. Trust with moq is now broken as has GDPR. This is underhanded to say the least. Be one of the good guys.

[Ibmurai]

That would make it trivial to bypass the SponsorLink check. So, this is by design at this point unless there's serious concerns raised by a large portion of users.

Why should it not be trivial to bypass?

[kzu]

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

Yes, I'd consider serious concerns have been raised. I'm evaluating bringing the analyzer code over to this repo. I'd like to bring it with its commit history so that it's clear how it came about too. Need to brush up my git-fu :)

[CookiePLMonster]

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

This exact mindset is likely going to incentivize people further to challenge this assumption and work harder on cracking down on whatever obfuscation you've applied. Clearly you've not researched how determined reverse engineers can be against such challenges.

[cygnim]

I think the point is, this funding model is inherently dishonest and should be abandoned immediately.

[hilari0n]

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

So you are basically using an extortion tactic. I.e. "I will not stop snooping on you and annoying you, until you start paying and then we'll call you my sponsor."
The idea of sponsoring is that anyone not able or not willing to sponsor can simply and easily say "no" and not be bothered afterwards.

Yes, I'd consider serious concerns have been raised. I'm evaluating bringing the analyzer code over to this repo. I'd like to bring it with its commit history so that it's clear how it came about too. Need to brush up my git-fu :)

Unfortunately it looks like too little, too late. 😞

An acceptable solution could be one where the package displays an information message in IDE, asking the user to be a sponsor (without extracting and divulging any data), explaining how you can become one and how you can suppress this message or (better) showing you a link to a page where you can read how to become a sponsor and how to suppress the message.
This way you would not be invasive and even if you would not gain many sponsors, you could at least bring more people to the discussion. (I've only just found out that you've been discussing it with some unnamed developers and I have seen no traces of such discussion.)
The next step would be to use a new message (with a new, but still simple way for suppression) informing, that from version X.Y.Z you will be developing 2 separate variants of a package, one free, offering only the existing functionality and maybe fixes and another one, which will be commercial.
A different approach could be to talk to Microsoft, on the NuGet.org offering a way to advertise option to support package creators. E.g. similarly to how npm does show messages about package authors looking for funding.

All in all, there's probably a multitude of ways to do this, without harvesting personal data without consent and without annoying people, as both of those tend to rather drive people away, instead of bringing new sponsors in.

[ScarletKuro]

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

Any skilled .NET engineer possesses the capability to bypass through this obfuscated code. I am convinced that any motivated individual could do so, as even dead de4dot can still dismantle a portion of the obfuscation present in the DLL, also replacing some IL code is not a problem nowadays as well. However, I'm skeptical that any reputable software engineer would do it, but if they do, I doubt they would sponsor whoever uses Devlooped.SponsorLink anyway.

This is not the main point tho. By obfuscating and keeping the source code closed, you create a barrier for audits, especially in highly secure environments. You are attempting to conceal the inner workings of your program, but there is no assurance that a future update of Devlooped.SponsorLink won't introduce unexpected elements, such as a Bitcoin miner(just an example). Sadly, I've come across numerous of paid software developed by individuals that contain hidden backdoors to take revenge if something happens.

I strongly believe that projects like these libraries should prioritize transparency. The primary goal of this library should revolve around capturing developers' attention, highlighting its donation avenues, and encouraging sponsorship if feasible. This is why I'm puzzled by the idea of obfuscation – after all, those uninterested in sponsoring won't be swayed regardless.

[wdolek]

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

It's easier to send few bucks than trying to figure out how to bypass message somewhere (even trivial one). Even your obfuscated closed source solution can be bypassed after all 🤷 - this cannot justify malware-ish behaviour of this library.

[Kryptos-FR]

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

It is already trivially by-passable but just putting fake email/user in .gitconfig (or better a know contributor's address) and using an alias to inject the real one into each git commit command. So you have no gain anything by this, and just lost the community's trust instead.

And about the obfuscation part: on one hand, people who don't want to pay, would still not want to pay and find a way to bypass. On the other hand, people ready to pay a sponsorship would like to be able to trust the package, which in this case they can't because of the leakage of PII.

[NiKiZe]

Any obfuscated analyser should be treated as virus/spyware. Will be blocking and reporting.

[kzu]

Analyzer and backend is all OSS in this repo now too. Locking this thread as a consequence.