Will cause packages to be no-go in corporate

[DanielCordell]

Just echoing the points that other users have made here. The current implementation (with closed source & obfuscated package) basically means that a lot of corporate environments with half decent security measures on what packages are allowed won't touch anything like this with a 10 foot pole. I'm sorry, but while I genuinely think this is a fantastic idea, I don't think it's viable to use any libraries that integrate this unless people have both proof of what is actually happening (full open source) and the ability to turn it off at the solution/project level. Moq is a good example where I and I'm sure many others are having to consider our options for migration away from it.

[DanielCordell]

Not even considering the fact that many places may have treat warnings as errors, causing this to unexpectedly cause builds to start failing.

[kzu]

Hi @DanielCordell , thanks for sharing your concerns. No CI/CLI builds will ever fail since those checks are never performed in those scenarios.

This is an EDITOR ONLY check. Hope this helps.

[dnperfors]

I am sorry, but even in my editor my build will fail when there are warnings...

[DanielCordell]

Hi @DanielCordell , thanks for sharing your concerns. No CI/CLI builds will ever fail since those checks are never performed in those scenarios.

This is an EDITOR ONLY check. Hope this helps.

I never said CI/CLI anywhere in my comment, having it fail in editor is problematic enough.

[dmsch]

This project appears to be in violation of GDPR by sending hashed email addresses to a foreign server, allowing for user tracking. The use of obfuscated code further raises concerns about the project’s transparency and intentions. Therefore, we classify this package as malware.

[kzu]

Would making the SL source code OSS too, dissipate the concerns? Seems like checking the sponsoring might still be an issue even in that case?

[rokonec]

Seems like checking the sponsoring might still be an issue even in that case?

Well, big part of my work is optimizing build performance and such. Seeing things like

is unacceptable behavior.
So yes, in my books, this kind of sponsorship extorsion will be an issue even if open sourced.

[sbergot]

Would making the SL source code OSS too, dissipate the concerns? Seems like checking the sponsoring might still be an issue even in that case?

Making the code open source would not make it ok from a GDPR point of view. It would just improve the perceived intention. The only way to make it ok for GDPR is to state which data is being collected for which usage and ask for user consent. And it has to be done with a specific legal framework.

edit: @kzu as other have said, you are now exposed to litigation. I would urge you to remove the 4.20.x versions just to limit the legal risk. It would only take one vindicative organisation to make things worse for you.

[steve-fenton-octopus]

To expand on the answer to the GDPR question, if you create an identifier that can be used to identify an individual and link them to other data it is classed as PII. If you are collecting your email-hash from users in the EU you are definitely collecting personal data that requires specific informed consent.

There is zero chance of claiming legitimate interest for this processing and even if you did, you have to provide a mechanism to allow users to object to processing and exercise their rights.

https://commission.europa.eu/law/law-topic/data-protection/data-protection-eu_en

[michalrosenbaum]

You can compare those hashes against set of mails leaked somewhere else and this way identify me. Even hashed mail should be sent only after consent.

[fuglesang]

From the readme:

Specifically, the actual email is never sent when performing the sponsoring check. The email on your local machine is hashed with SHA256, then Base62-encoded. The resulting opaque string (which can never reveal the originating email) is the only thing used.

The statement that this can "never reveal the originating email" is wrong. As mentioned earlier, what this hashing achieves is considered to be pseudonymization.

Pseudonymized data can be restored to its original state with the addition of information which allows individuals to be re-identified.

By using, for instance, a rainbow table one can restore the original data.

GDPR Recital 26 explains

...Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person.

[Mart-Bogdan]

I can't understand why the hell it is closed sourced AND obfuscated!

[madhon]

To expand on the answer to the GDPR question, if you create an identifier that can be used to identify an individual and link them to other data it is classed as PII. If you are collecting your email-hash from users in the EU you are definitely collecting personal data that requires specific informed consent.

There is zero chance of claiming legitimate interest for this processing and even if you did, you have to provide a mechanism to allow users to object to processing and exercise their rights.

https://commission.europa.eu/law/law-topic/data-protection/data-protection-eu_en

Also SHA256 has been rejected by court already as not sufficient to hash emails
https://www.spiritlegal.com/en/news/details/e-commerce-retail-facebook-custom-audience-not-allowed-without-consent.html

"The court found that the SHA-256 hashing procedure used was not suitable for assuming anonymisation of personal data within the meaning of Section 3(6) of the old version of the German Federal Data Protection Act (hereinafter referred to as the “old BDSG”). Despite the creation of hash values prior to the transfer as a decisive processing step (Section 3(4) Sentence 2 No. 3 old BDSG), it was deemed possible to re-identify data subjects with not only disproportionate effort. Otherwise, Facebook would not be able to compare the data after the transfer."

[madhon]

I can't understand why the hell it is closed sourced AND obfuscated!

To hide it, nothing more.

[wdolek]

My 2¢: After the issues we faced recently, I think it's time to think carefully about this project's future.

Even if we were to fix the problem with the closed-source library being injected into any project (#9) by making it open for everyone to see, and even if we made sure the dotnet analyzer doesn't make any unexpected web connections (#10), I'm still not sure that would be enough.

While the concept of GUIDs stored on a developer's PC has been suggested (@kzu mentioned this idea yesterday), it does not appear to be a comprehensive solution of balancing company sponsorship against individual employed developers' use of the library (additional details would be helpful in understanding this proposal).

I genuinely understand and appreciate the need for corporate support the FOSS community, and the critical role that it plays in enabling maintainers to contribute without financial constraints. However, I believe it's important to ensure that the path you (we, community) take aligns with our shared values and principles. Several successful models for fostering collaboration within the open-source community were mentioned at https://github.com/moq/moq/issues/1374.

[madhon]

Hi @DanielCordell , thanks for sharing your concerns. No CI/CLI builds will ever fail since those checks are never performed in those scenarios.

This is an EDITOR ONLY check. Hope this helps.

The fact that it breaks on MacOS and Linux, which use the command line to build suggests your assertion is wrong.

Open the source, prove us wrong, until then there is no trust around this at all.

[ABruel]

Seems like checking the sponsoring might still be an issue even in that case?

Well, big part of my work is optimizing build performance and such. Seeing things like is unacceptable behavior. So yes, in my books, this kind of sponsorship extorsion will be an issue even if open sourced.

Wait, this thing blocks the build for 130ms if you aren't sponsoring a library that uses it? Now that's gold.

[madhon]

There's also that any builds with warnings as errors will fail to build

[kzu]

I do think build pauses for non-sponsors is an acceptable trade-off for library authors who want to get sponsored for their work. Please chime in on #33 . Closing this to we keep discussions separate on the various issues raised.

[FeldrinH]

Please chime in on #33 . Closing this to we keep discussions separate on the various issues raised.

But the original issue here and #33 are completely unrelated? The original issue here is that SponsorLink as currently implemented is likely to violate a lot of corporate guidelines for what dependencies can be used (due to being obfuscated and the source not having an open source license), which has nothing to do with the build pauses.

[TsengSR]

I do think build pauses for non-sponsors is an acceptable trade-off for library authors who want to get sponsored for their work. Please chime in on #33 . Closing this to we keep discussions separate on the various issues raised.

No it's not. Everyone understands your need for compensation for the work done, but for gods sake, offer commercial support (in the form of SLA) or trainings.

This brings way more value to the companies to know that they can ask for a critical bug fixed or new feature added, who would be more willing to pay to have this kind of guarantees. That would bring you way more than a few bucks charity, something you could even build a whole business model on it. The whole goddamn Linux ecosystem works on this premise and employs thousands.

Your way resembles more of a blackmailing approach or the "chip out" way, get as much money possible then quit and abandon it. If anything, you reached the opposite of what you wanted. Not only that, but you are at very high risk of getting sued by a few 10's of dollars per case for violating GDPR and the damage you caused, if the companies would decide to sue you (the GDPR is not up to the companies its to the users and the GDPR authorities) because they now have to remove your malware from their projects which may be weeks and months worth of work to rewrite all the tests to work with a different mocking framework!