Closed duaneking closed 1 year ago
Only slightly related but I think it makes sense to put it in this issue - we've had the Assembly-Info-NetCore@3
task in our pipeline for a long time now but only just started looking closer at it as part of an effort to get our build time down. We've found that this step has gone from 18s -> 2s by disabling telemetry (we're not self-hosted btw). I'm not sure we even realized this was enabled in the first place which isn't great.
Making this opt-in would likely see a similar performance improvement for others who are similarly unaware. It would also mean you're only collecting analytics from users who have made a conscious decision to allow that, which is surely a good thing for everyone.
The lack of informed consent is a huge issue for me, but its important to call out because it also violates the MSFT marketplace agreement that allows this plugin to exist.
At the end of the day there is no engineering reason for this invasive Telemetry to exist. It also actively hurts engineering efforts and increases the costs of runs 10 to 20 seconds at a time when enabled by default; Now aggregate all that extra time from all the build systems using this to everybody using it, and all builds run, and do the math to find out how much that arbitrary delay is costing people without their consent in terms of azure compute time, without the user's knowledge....
Needless to say, this is actually a huge issue and the marketing person that thought this was a good idea really should ask their legal department what "Moral Hazard" is, as I do not believe they fully thought this through.
Thanks for reaching out. To clarify; - the telemetry is used to track anonymous usage and exceptions. There's no personal data, pipeline data or any Azure DevOps data being collected. You can check the code if you want to clarify this for yourself.
I am aware the introduction of telemetry has increase the build time however this is a trade-off in being pro-active and monitoring and tracking exceptions with new releases.
I am very aware not all users will be happy with the telemetry and that is why an option was added to disable the telemetry. This is all explained on the marketplace listing.
Exceptions and stack traces contain possible Telemetry that I don't want you to have, And that would be explicitly leaking personal data to you, either way.
And you even having knowledge of the IP address that it's running on to make the request is a security problem, as that actively violates many compliance requirements and is considered a leak of personal data to any auditors who understand basic cyber security.
Any kind of Telemetry at all that is not explicitly opt-in is malicious and violates the right of the user to provide informed consent.
I understand your concern with the exceptions and stack traces: - no identifiable data is collected willingly however there is a possibility some data may get dumped in a stack trace of an error.
I do not have any knowledge of IP Addresses, that data is not captured in the telemetry and for good reasons. As mentioned previously the telemetry tracks anonymous usage and exceptions, to be precise it logs a START & END event and any exception that may occur.
I appreciate the feedback but if you are not happy this extension contains telemetry then please either disable the telemetry or remove the extension from your tenancy.
I love the idea of this plugin but the addition of Telemetry makes me not trust it as much and you should know that the ability to turn off Telemetry is not the same as not having Telemetry. Pleased consider making telemetry opt in to allow more people to use this plugin in secure/regulated environments without pushback.