.NET core spies on users by default | Hacker News Reader

.NET core spies on users by default

github.com

250 pointsIce_cream_suit150 comments

Lots of FUD as usual with these topics.

The .NET Core CLI/SDK dev tool to build and package code is the only thing sending telemetry. It's not the main `dotnet` command itself nor anything in the runtime. The data is also available for anyone to analyze: https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

It's definitely nothing out of the ordinary and is common practice among many tools and apps you already use. Your smartphone sends back way more data if you're that concerned.

There's also a warning the first time you use it, and if you're using something like this then it's a reasonable expectation that as a software developer you understand the message and how to disable it if you want to.

EDIT: the insights based on this telemetry are also interesting to look at and add further clarity: https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...

> Lots of FUD as usual with these topics.

> It's definitely nothing out of the ordinary and is common practice among many tools and apps you already use.

Also as usual it's opt-out and NOT opt-in. People get riled because (usually)

a) built in telemetry is almost always an unexpected and unannounced change - only to be discovered later.

b) opt-in is the only approach that leaves your trust in tact - everyone uses opt-out because they know the majority of users people will not choose to opt in given a choice.

I don't see how it's unexpected when you get a message telling you when you first run it - and the only thing to do with this tool is to run commands explicitly.

Most apps are opt-out though, the checkboxes are already checked and a message shown. I agree that it would be easier to just enter an option on the command line instead of typing the environment variable option.

> I don't see how it's unexpected when you get a message telling you when you first run it

https://github.com/dotnet/cli/issues/3093#issuecomment-32632...

It's a comment about something they saw in the install script. Since the code is right there in the repo, that would be the actual source to see if it does indeed send telemetry. Perhaps someone can do that to settle this definitely.

I'm confused. Why in the world would it be calling ProcessInputAndSendTelemetry() if it wasn't actually trying to send telemetry?

It always calls the Telemetry class; however is functions are disabled based on the settings - so won't actually send anything if environment variable is set

https://github.com/dotnet/cli/blob/22cd85daf6ca63a48e35fc7e2...

If you are confused, why not just read the source?

It always calls the Telemetry class; however is functions are disabled based on the settings - so won't actually send anything if environment variable is set

https://github.com/dotnet/cli/blob/22cd85daf6ca63a48e35fc7e2...

But that happens before displaying any information about how to disable telemetry... which is definitely unexpected.

"Most apps are opt-out though, the checkboxes are already checked and a message shown."

IMO, this is the key problem. I have no issue with optional telemetry, but there should be a bright line here: all telemetry should be opt-in. If necessary, by law. It should not become standard practice for applications to send data without explicit consent.

Most applications will claim that it is explicit consent since you have to click "OK", and then try and argue that a preselected checkbox is not the same as opt-out.

Maybe we need nullable checkboxes; so you have to explicitly make a choice either way, rather than leaving things to default.

- If you have to opt in, most people won't bother as it's not of direct benefit to them (even though overall it's beneficial to the community the more people who do opt in).

- If you have to opt out, people will complain even where the option's made explicitly clear (i.e. where it's not an attempt at being devious / a deliberate dark pattern).

Admittedly then people complain that they have to make a choice / can't just install-and-go... :/.

An off-topic mention, everytime I think of a project I'm taking over and seeing "nullable booleans" I'm left wondering why the developer before me went with that approach, there's no commentary as to why nor do I see any indication of nullable booleans being used in any special way / case.

Can any dev out there give me a good use-case aside from forcing someone to check something, and should nullable booleans mostly make sense on front-end as opposed to back-end code? How does a GUI define something is nullable, if a user has not selected it but it's unselected by default.. I find it all a bit confusing...

A checkbox is the wrong UI control for this, because its two states (checked and unchecked) do not cleanly map to the three possible values (true, false, no value).

Radio buttons come closer, but most UI widget libraries provide no way to select none of a radio group once one has been selected. So you can have a radio button each for true and false, and default to no value (i.e. neither selected), but the user can't change her mind and go back to no value.

Sometimes that's okay, as when no value is invalid or meaningless in the context of the form. When it's not, the best solution I have is a select box with three options; three radio buttons in a group would work too from a semantic perspective, but necessitate a probably confusing label on the no-valued one, where a blank option in a select box is much likelier to make intuitive sense to the user, especially if it's the default.

For required fields, either works. With the select box, making the no-valued option default requires the user to interact with the field, and the same holds for a radio button pair that has no button selected by default. In either case, if the field's value is null rather than false, you know no selection was made and can complain accordingly.

>A checkbox is the wrong UI control for this, because its two states (checked and unchecked)

Windows developers might disagree, since Windows 95 checkboxes have had three states (on/off/mixed, or checked/unchecked/filled out), and the third state is used in a lot of places by Windows (though usually to mean that some subitems are on and some are off).

I've never seen one of those used to represent a null value, and I'd consequently avoid using one that way purely on the principle of least surprise.

Sometimes you need to know if a value has been explicitly defined or not. Also, sometimes you need to know if a value is different from what it was before. Nullable values help in both cases, because you can tell the difference between the "default" value (false for boolean, "" for strings, 0 for numbers) and "no" value (null). If you have a form being submitted, you can tell the difference between the user setting fields to their default vs the fields not being returned to you at all.

Another example is an ORM system. A data entity could be initialized from an existing database record, or it could be blank. Each property of the data entity could be initialized or not, depending on the SQL query that was used to initialize it. For fields that are non-nullable in the database, you can compare two entities for the same record to determine if fields have been updated or just weren't initialized. That lets you perform database updates only when necessary, and prevents accidentally deleting information.

All booleans - in the fullness of history, brought into the harsh light of business logic - are destined to become enums.

That's deep and thought-provoking. I like it!

One of my clients has a database flag field that I needed to use to determine whether or not to show something on their website. Should be a simple boolean field, I thought. Nope; their field can contain one of half a dozen character codes, none of which are Y or N. So you're right; I created an enum to represent the allowed codes and map them to meaningful names, and then I had to create a second boolean property to contain the business logic that decides whether or not to do the display based on the various codes.

Here's a use case for nullable booleans in the database, at least. Arguably this could be solved with different data modeling, but suppose you have an "Application" model/table that represents an employment or credit application. The application requires many different steps, so you want to save progress along the way. On Step 3, there are checkboxes for perhaps certifying whether or not you're a U.S. Citizen, or to check if you agree to a certain legal document. Prior to step 3, you wouldn't want to default those values to "false", as they haven't been specified yet by the user, so you leave it as "null". Once the user saves Step 3, you can now be sure that the false or true value is one that came from the user.

That being said, I challenge other developers on my team to make sure they have a very good reason for using a nullable boolean. Sloppily using nullable booleans when not needed causes queries and data understanding to be a mess (i.e. what does IsActive == null mean?!), as well as the possibility of introducing subtle bugs.

Also, I don't think "nullable boolean" as used by the parent actually should refer to the CLI/GUI, but rather that the setting of whether you've opted in or out would be null by default before the first run, and then the CLI/GUI would force a choice resulting in a non-null true or false for whether to opt-in to telemetry. That doesn't require "nullable" checkboxes, but rather a nullable boolean data field in the .NET Core settings. If you need to represent a "I'm purposefully not making a choice" null boolean value in a UI, use a radio group with 3 options.

I know this is an example, but I would also say please do not store things that you dont know yet.

Eg, if there is a form with optional values, do not store them in a sparse row, instead consider using Entity Value Attribute to store each value as a row (even though its kind of blegh in general, you wont ever store nulls for things you just dont know "yet".)

Okay, I see your point, but the counter-argument is that opt-in telemetry is practically useless. The whole point of telemetry is to passively monitor the majority of users and see how they use the software, what the pain points are, where to focus on, etc. Most of the people who would explicitly opt-in are also likely to make their feelings known through other channels, their voice is already heard on forums, help channels, issue trackers, etc. What you need to know is how the "silent majority" uses your software.

Personally, I would prefer developers have this option to improve their products. I am willing to put lots of caveats there: the telemetry gathering should be clearly indicated, it should be transparent, we should have access to the data, and obviously, it should be anonymized as much as possible. I think Microsoft ticks all those boxes in their approach. I also acknowledge that they hadn't done so at the start of the issue, but the situation quickly got muddled up with the opt-in vs opt-out back-and-forth, rather than how well they had implemented their opt-out approach.

Using telemetry to see how users use software is pointless. It does nothing to actually explain why a user is doing something. So instead you have to have teams of people who try to make, at best, an educated guess about user activity and reasons behind them.

If I'm clicking back and forth in a window, why should you assume it has something to do with your software? Yeah it's the most likely culprit in your opinion. But in my opinion I simply accidentally clicked somewhere, brought your window to focus, and went back to what I was doing elsewhere. Or clicked a button and clicked around to figure out how to undo it. I've seen tons of people with ADD-style clicking and typing while they're actually doing something completely irrelevant. It's literally just noise. Why do you need to try to interpret it?

    Using telemetry to see how users use software is pointless.

The word you are looking for here is something like "limited", not "pointless". Sure, there is noise in telemetry but there is also a lot of signal. And it is the sort of signal that is difficult to acquire.

I'm certainly not convinced that for consumer grade applications opt out telemetry is a good thing, for lots of reasons. But none of them are "it isn't useful".

I've upvoted you, even though we obviously don't agree, because I think that was a really excellent response.

Personally, I find that I have knee-jerk reaction to this. My feeling is that if something can be wrong or be abused, it will. That's why I feel that the best thing would be for opt-in telemetry to be simply put outside of consideration.

This kind of data collection is something that we've given to ourselves as an industry in the past few years, but we've developed software for decades without it. IMO, developers definitely have no inherent right to extract data from user systems, especially with Open Source products, where the license effectively says that there are no strings, and no obligations. If we want this, I think that we should have to make the case for it.

Your interactions with ycombinator.com to read this discussion and leave your comment were logged in an access.log file, which is a form of telemetry. Should that be opt-in? If so, a necessary tool for managing websites will be destroyed. If not, if an exception to your law is made, then the tools and applications you're worried about will end up with features that integrate with remote websites that are necessary for their function.

Don't be so quick to call for laws.

ycombinator.com is a site that you willingly send data to, it is not an application that you use locally.

I do agree however, we do not need more laws about that, we just need the people to start using software that respects its users and can be audited by anyone - free software.

But that "willingly" isn't so willingly if I included a link to something on ycombinator.com on another website that has nothing to do with it.

Please elaborate.

if I link to an image, javascript file, or even an iframe to ycombinator.com, your browser will make a request to ycombinator.com most likely without you knowing.

if ycombinator.com logs information on that request, is that okay? if not where does the "fault" lie? With the site that linked to a 3rd party (my website in this example)? With the site that is gathering telemetry without opt-in consent (ycombinator.com in this example)?

If it's the former (my fault for including a 3rd party request), what happens when user-submitted content includes a link to a 3rd party? What about if a user-submitted content includes a link but doesn't make a request and your browser decides to prefetch the contents of that link?

> if I link to an image, javascript file, or even an iframe to ycombinator.com, your browser will make a request to ycombinator.com most likely without you knowing.

True, which is why many people (including me) use something like umatrix with every 3rd party request disabled unless whitelisted. This should be the default to be honest.

> if ycombinator.com logs information on that request, is that okay?

You are willingly letting your traffic be logged by the original site that you connected to. Does it matter if another party (usually trusted by the first party) gets the logs as well?

> and your browser decides to prefetch the contents of that link?

Change browser or configure it properly. Who even thought that prefetching is a good idea?

Anyway, the one at fault at this specific case is your browser (and maybe you, considering how you selected to use that browser or didn't bother configuring it).

So in the case of this .NET issue isn't the fault on you since you didn't configure your PC to block this request?

Not exactly. In the link case the application is the browser instead of the site and there are many browsers that you can select from, in the .net case however the .net itself is the application.

Logging the interactions a device has with you is not ‘telemetry’ because it is not tele, at a distance. It is local.

Logging things from a device that are not related to your server is telemetry.

Don’t be so quick to apologize for spying on users. Telemetry is not necessary, we did fine without it for decades.

> I don't see how it's unexpected when you get a message telling you when you first run it - and the only thing to do with this tool is to run commands explicitly.

What about when it's run through VS or some other tool that hides much of the text? How does it know that I've read this information when it could be buried in several thousand lines of output from itself and other tools like make or msbuild?

Being explicit about opt-out is even less acceptable for command line tools than it is GUI based ones.

Exactly. It only takes one misconfiguration for your build server to call home.

It should take one misconfiguration for your hold server to not call home.

Slightly subtle inversion there.

Build server would use MSBuild which doesn't use the dotnet cli (the dotnet cli also calls MSBuild)

We use Jenkins and currently nuget restore first. Your assumption is invalid.

> What about when it's run through VS or some other tool that hides much of the text?

VS uses MSBuild rather than the dotnet cli (its also what the dotnet cli calls)

> telemetry

> opt-out

Just like Google's chrome, flutter, android sdk, etc. Just like apple osx, xcode, etc. Macromedia everything. the list goes on. Even mozilla who had it right now have so many telemetry modules that most ignore the main setting about it.

my point? I don't think I have any other than to highlight this is a lost cause and everyone should be eternally vigilant with everything :(

> There's also a warning the first time you use it

If you'd actually read the issue before commenting, you'd realize that this behavior was added after people complained about the telemetry not being obvious. It's the sixth comment on the issue (by guardrex) - not even that far down. The very next comment is an MS contributor saying that he makes a good point that it wasn't obvious, and that they'd improve it in a future release. Which is why there's now a warning when using it. I mean, the link is old, but it should be understood that an issue on preview tooling from over a year ago might not represent the current state of the tooling. But yeah, on first release, all the notice you got was a blog post, if you even bothered to look for it.

It's also a fair point that it's still not made very clear that what information is collected under what circumstances. It's a huge problem with Windows, so you can understand why people have their jimmies rustled even over something small. Especially since windows 10 makes it impossible to completely opt-out of telemetry. Even after disabling the visual options, it's still regularly calling out to Microsoft servers. Even if you disable the services, updates will turn them back on and other services will start it up. And then it chews through your system's CPU like it's starving. Which means it's probably collecting far more data than it needs.

Finally, sometimes it's not even about what's collected or that there's an opt-out procedure. Sometimes just having a mechanism for transferring data can cause problems. 'sushihangover' comments on that issue that someone failed their HIPAA audit based on this behavior. I've no idea if it's an accurate example, but there are government, medical and enterprise environments where any non-sanctioned traffic is strictly prohibited and can cause liabilities.

Telemetry needs to be easy, simple, and thorough in its opt-out mechanisms. Microsoft has failed its users on this frequently and recently. I don't think this particular instance is that bad, but they should be doing damage control in all products based on the public perception that they're spying on users.

SQL Server Management Studio, on the other hand, is much better about its analytics opt-in request. Microsoft is a big company with varied practices. Not every division deserves a high-five about their privacy practices.

> It's definitely nothing out of the ordinary and is common practice among many tools and apps you already use. Your smartphone sends back way more data if you're that concerned.

Let MS take their knocks when they earn them. And it's totally fine if people point out that Microsoft has a problem with opting users into unwanted telemetry. Even if it's not important data, it's data that someone didn't volunteer to give up. It's a horrible, common-place practice that needs to end.

Honestly, they might not need automatic telemetry if they just made volunteering information during a bug or slowdown significantly easier. If it was easy to, for example, enable telemetry for a Visual Studio session to track down why it runs like a whale, and then to review the information sent before it was sent, people would use it all the time to better the software. Instead, people turn off everything they can and don't bother to enable it (required for some MS feedback apps) to report issues because they don't know what'll sneak across.

When your telemetry is easy, open, and transparent, people will gladly opt-in when they think it's needed. Or they can hide the data they care about and share the rest.

> When your telemetry is easy, open, and transparent, people will gladly opt-in when they think it's needed.

Well said. As a favour to the developers, I have always chosen to opt in for telemetry when it was asked upfront and in a transparent and guileless manner. One example is Firefox, where I opt in for its telemetry.

What I suspect I (and others) don't like is software that treats the user as if they're too dumb to decide for themselves and somehow too inconsequential to have full control over the software that they have bought. It gives off the impression that the software is more important than the user or their work/machine, which is why we see such a backlash. Stallman is right in this sense. You don't need to open source your software, but make the user your priority. Treat them well. And watch your software be praised far and wide. Conversely....

they don't just want to get a lot of data, they want representative data. they're afraid that, even if many/most people opt in, if the sort of person who opts in is different from the sort of person who doesn't, and has different usage patterns, the data will be skewed.

I think one of the issues is the maintainer of an open source project will always have the final say in which patches are accepted. So the best way to not have any telemetry would be to fork the project and remove the offending code. Also historically, is /var/log any different from telemetry? I can easily figure out which applications were installed, what the hardware on the system is, which cron jobs were executed etc.

But in any case I agree that MS should definitely allow the owner of the machine the ability to block the transmission of any and all telemetry data.

> fork the project and remove the offending code

Yeah, it's possible. And it will probably happen at some point or another, now that it's open source. But that won't stop the momentum of the core product.

> Also historically, is /var/log any different from telemetry? I can easily figure out which applications were installed, what the hardware on the system is, which cron jobs were executed etc.

Telemetry by definition includes the transmission of logged data. System logs may be collected and transmitted internally by an organization, though by default it is not. But pretty much everyone would be up in arms if a software vendor collected logs of not only what their own software is doing, but what other software on a user's system is doing. And that's the main problem with Windows telemetry - it's too invasive, resource intensive, opaque, and integrated for people to stomach. So they turn it off wherever they can, and thus starts this disgusting game of whack-a-mole with Microsoft.

The dotnet cli isn't as bad, but Microsoft has earned some black eyes from the behavior of their other departments. So everyone's going to feel the heat until they learn too control their greed for data.

Yeah, you're correct.. telemetry does include the transmission.

>And that's the main problem with Windows telemetry - it's too invasive, resource intensive, opaque, and integrated for people to stomach. So they turn it off wherever they can, and thus starts this disgusting game of whack-a-mole with Microsoft.

Ironically, its mainly the technical users who fiddle with all the knobs the OS provides anyway. The same technical users who write tech blogs, influence IT decisions, etc etc. Not having those knobs exposed for telemetry was a bad business decision on MSs part. I've managed to block it at the IP level when I installed W10, but I definitely don't want to be micro managing that.

To their credit the doc is pretty explicit on what they collect. Has Microsoft published anything similar for windows? All I have seen is very broad and generic statements, not a list of fields and a description of how they are obfuscated.

[edit]: actually they do, and it is a pretty scary (and very long) reading, even the "basic" telemetry:

https://docs.microsoft.com/en-us/windows/configuration/basic...

And it's still incomplete. They refuse to publish what happens for "security" level telemetry, which is sent in addition to basic and not disclosed.

> Your smartphone sends back way more data if you're that concerned.

That's not true. My iPhone asked me if I want to share iPhone / iCloud analytics and I said no. This wasn't an opt-out, but an explicit question. I remember my Google Nexus asking me about it as well, including for Google's Keyboard. I said no and again no opt-out happened.

And in fact it would be illegal to collect user telemetry in the EU without the user's explicit consent ;-)

I have very limited apps in my phone. And I have disabled almost all Google creepware (except Google Play Services, Maps etc) and opted out of anything Google allows me to do. Still, I see this in Disconnect Pro:

https://imgur.com/a/ajRbI

Are you asking me to debug your phone?

Google Analytics is a service that can be used by websites, online services and mobile apps to track users. If I were to guess, those are requests made by the browser or by the apps that you have installed. I was also talking about a Nexus 6 phone, with the pure Android experience, not whatever Samsung or the others are doing.

I don't feel this is relevant to the discussion at hand though.

The little symbol at the right side means that this connection is initiated by the Google Services Framework, also called Google Play Services.

According to Disconnect Pro, these are the apps does the tracking in my phone: Google Play Services, YouTube, SmartThings, Outlook & Firefox Focus (https://imgur.com/a/Ga9Bj).

I understand that other apps could be doing analytics through Google Play Services. But I don't want that. Whether it is Google doing it (I still get location based alerts even though I have disabled location history) or third party apps, Google is facilitating it (of course I am aware of the argument you are the product if its free). Since I have no way of opting out, I have to install Disconnect with admin privileges (which in itself is scary to me). I am also in the process of setting up a pfsense box so that I can block Google and Microsoft telemetry at home.

I shouldn't have to do all these.

Google Play Services is THE creepware. It's essentially a MITM on most of your phone's live status information.

I wouldn't be so sure about what that iPhone sends out, with or without your consent, given the fact that Apple has deemed it necessary to dole out 'special' permissions to the likes of Über (not exactly the most scrupulous of companies) to work around limitations in their platform:

https://news.ycombinator.com/item?id=15411533

The only way to find out what your device - no matter which device - send out is to sniff out all the traffic it generates. While easy to do on Wifi this is harder to accomplish on the mobile data connection.

Putting your tin foil hat on is healthy, but not relevant for the discussion at hand.

If indeed iOS is collecting user data without the user's consent, or allowing a company like Uber to collect that data, then I'm pretty sure a class action lawsuit or a huge EU fine will happen.

But that is a separate discussion altogether, the fact at hand being that iOS does ask the user explicitly whether telemetry should be enabled or not and I remember that Android does that too.

No, the fact of the matter is that Apple gave Über this special permission which allows it to do whatever it wants with the frame buffer. It did not ask for permission to get that permission, nor did it tell you what it would do after it got said permission. This is directly in contrast to your trust in the platform to "ask the user explicitly whether telemetry should be enabled or not".

As to the tin foil hat statement I'd like to add that 'tin foil hat' refers to the belief in unsubstantiated rumours of a conspirational nature. In this case it has been proven beyond doubt that something fishy is going on - and has been going on for years - so the statement is not applicable.

I’d like to add that just because something is common it doesn’t make it healthy or good for the user.

Telemetry is a recent obsession of the industry and as trust declines this is the equivalent of stuffing a cigarette in the mouth of your customers and stealing their passports.

It’s just not ok on any level.

> Telemetry is a recent obsession of the industry and as trust declines this is the equivalent of stuffing a cigarette in the mouth of your customers and stealing their passports.

Wow that went way over the top. Who knew Telemetry is carcinogenic or was considered stealing. Honestly it's hard to take the anti-telemetry crowd seriously when these types of arguments are used.

There are more axes of comparison than literal interpretation.

I agree, if you make telemetry opt-in, you might as well not even try doing telemetry in the first place.

However I think the way to disable it is a bit user hostile, maybe a prompt when run interactively for the first time and a env var for when running in automated environment.

Summary of the key problems:

1. Microsoft won’t engage with customers on removal of this even if it causes problems.

2. The feature fires off before it informs you.

3. We don’t trust Microsoft after they turned their platform into a data gathering and leak risk.

4. This spans more than just windows as a platform so the assumption that opt out is OK is leaking onto privacy respecting platforms.

5. This is resurrected because it’s still being fought.

6. No one else does this. This is new and we don’t want the assumption that it’s ok to go forward any more than it has.

7. Steamrolling opinion is not how you treat customers. That’s how you lose them.

Microsoft are doing a big platform push for tooling I.e SQL server, powershell, VScode etc and we’re making it known that when in Rome, do as Romans do.

A lot of younger users will be used to telemetry as a feature and are not sensitive to it. This does however pretty much kill the product for healthcare, finance and defence sectors.

In my case this signifies the end of a 15 year investment of my life in a platform.

How does this “kill the product for healthcare, finance and defence sectors”? This is part of the SDK tooling, it should not installed or run in the deployment evnvironment. (If teletmetry is bad, running “dotnet restore” to download code from the internet is worse).

If having telemetry in the development environment is bad too, then so was the “Visual Studio Customer Experience Program”. While that was opt-in, I would think that if telemetry was so dangerous that precautions would be taken to prevent it from being turned on. Precautions that would be at least as difficult as setting an environmental variable.

> How does this “kill the product for healthcare, finance and defence sectors”? This is part of the SDK tooling, it should not installed or run in the deployment evnvironment.

This will also be installed in places like the build server that may have extra permissions into the production environment. Often the firewall between production and development won't be as great as you think and all software has to be compliant because the developers will be dealing with real private data.

> If teletmetry is bad, running “dotnet restore” to download code from the internet is worse

"dotnet restore" could be hitting a local repository only, which is much more common in these environments.

> If having telemetry in the development environment is bad too, then so was the “Visual Studio Customer Experience Program”.

Typically it would be disabled, but things slip through the cracks, no matter how many precautions there are, which is why off by default is important.

Aside from that, it kills trust. The developers don't even understand that this is a privacy violation and refuse to fix it, so when the next thing on the slippery slope comes along I don't expect them to appreciate the ramifications of it. Will compiler error codes be considered telemetry? How about exceptions? How about code metrics? I can't trust the dotnetcore developers to respect privacy.

No, it does not kill trust. Maybe only in people who doesn't know how to configure and use CLI tools properly. Just disable this feature and move on!

> Just disable this feature and move on!

This implies that you're aware of the feature in the first place. One of the major points is that they don't make any sort of notice that telemetry was added in, turned on by default. There's a good example in the issue comment chain how Yeoman asks on first run if you want to send anonymous data.[1]

[1] https://cloud.githubusercontent.com/assets/361677/15396939/3...

They do, the first time you run dotnet.

> "dotnet restore" could be hitting a local repository only, which is much more common in these environments.

You have to do this as part of your configuration. Alongside that configuration, you can change a single environment variable to turn telemetry off.

> but things slip through the cracks

I don't see how negligence is a valid counterargument. You could use the external repository by mistake and do far more damage. Are you more likely to forget about the the telemetry opt-out? After all this fuss I doubt it.

The root comment also claims that Microsoft refuses to engage and allow the removal of it. The environment variable exists, Microsoft has clearly engaged and allowed the removal of it. This comment chain is FUD.

Finally, if you really care about privacy this much you should be building things from source. This applies to .NET Core as much as it applies to GCC. .NET Core is open source, so this is absolutely possible to do.

> Finally, if you really care about privacy this much you should be building things from source. […] .NET Core is open source, so this is absolutely possible to do.

It's not that simple. Until recently, you had to have .Net Core installed to build .Net Core. There is now a way to build from source (https://github.com/dotnet/source-build), but it only works on Linux.

> How does this “kill the product for healthcare, finance and defence sectors”?

Here's an example for healthcare:

https://github.com/dotnet/cli/issues/3093#issuecomment-33389...

In healthcare software development you do risk analysis as a daily exercise. Mitigating this is so easy.

In this Github comment the only issue is a scared customer management (how I read it), which in my opinion has no experience in handling audit findings or software development. Stopping CIL (or CLI) projects because of this is ridiculous and shows a lack of professionalism.

I am in healthcare with multiple active development stacks (Java, Node, .NET, Python, ..) and in this regards I worry more of the Cordova/Node apps with their 1000s of npm dependencies which some of them do not even have a public source code repo and/or intentional anonymous author and/or without a license. Analyzing who is calling home there is a monumental task compared to the pretty uniform .NET or Java stacks.

I agree the lab management overreacted in this particular case. If I were them, I’d ask the author of the comment to fork that repo disabling telemetry, and probably implement some automatic verification tool/tests to make sure no parts of the software stack call home.

However, I can also understand the reason for the management’s paranoia. Besides that HIPAA law, it’s also the fact that if your genome gets leaked, you can’t change password/order another card like with the traditional IT data leaks. Probably, they view the data leak risk as an existential risk for their whole company.

That is true. But in that level of paranoia I would argue they should stop using software :). In healthcare and other regulated environments they can shut you down for months or years because of your handling of audit findings. But you get findings because an employee missed his badge, hold open a door for an auditor or has the wrong training records. But there are finding severities, risk analysis and capa handlings to deal with them. Handling this case is easy.

My argument is, when you are in healthcare and you cannot deal with audits and their outcome, stop being there.

> This does however pretty much kill the product for healthcare, finance and defence sectors.

This is such an odd thing to write. .Net core is not even wounded in those sectors.

Yet.

And will never be wounded by something like that. If you do healthcare software development without proper handling of your dependencies you are screwed.

Imagine you use a garbage collected golang code base for an implant defilibrator with limited memory (of course it will crash). Or Rust for a data shifting smartphone app (financial overkill). Or JavaScript when dealing with floating points in 64 or 32 bit during a medical parameter calculation (wrong result).

.NET Core can be used. JavaScript can be used. Python can be used. Just make sure you understand it well before you use it.

We’re not talking critical or embedded systems, just ones that handle PII. Crashes are not critical.

It's not even used there either.

It's used in finance. I cannot speak to the rest.

It also tells you that telemetry is enabled and gives you instructions to disable it the first time you run the `dotnet` command.

Just like any other tool that automatically checks the telemetry box for you. You just need to use an environment variable instead of a checkbox in this case because it is server software.

If I'm reading the comments right, it sends some stuff during installation. So before you can do anything.

It uses an environment variable, you can set that before running the installer.

Only if you know about it prior to installation. Opt-out is simply never acceptable and it should be considered spyware until it's fixed. I can't believe there are so many apologists for this sort of behavior.

All that's missing is hiding the information in a basement, without stairs and a sign saying "beware of the tiger".

You bring up a good point. Software shouldn't start sending information until the user is explicitly informed just as users are required to explicitly consent to an EULA.

Otherwise it's the software that's using the user and not the other way around.

> Only if you know about it prior to installation.

This is a piece of third party software. "Should be" doesn't override reading the manual and knowing what you're installing.

> https://www.microsoft.com/net/core#windowscmd

Can you point out where in the installation instructions I'd find out about this telemetry or do you seriously expect me to read every single piece of documentation this might be hidden in? Considering this was added after the initial release, do you expect me to re-read the documentation on every single update?

Sorry, but even if your argument was correct, this just (deservedly) burns any good will I had with MS, which wasn't much but at least I used to have some for the .net team.

> Can you point out where in the installation instructions I'd find out about this telemetry or do you seriously expect me to read every single piece of documentation this might be hidden in?

I expect someone who cares about telemetry to search for it. It is well publicised, discussed, and available [1]. There is a telemetry warning when first using the tool.

> Considering this was added after the initial release, do you expect me to re-read the documentation on every single update?

No, but I would expect you to read the release announcements. [2]

> Sorry, but even if your argument was correct, this just (deservedly) burns any good will I had with MS, which wasn't much but at least I used to have some for the .net team.

So, regardless of correctness you would have been burned anyway. Microsoft even releases the telemetry gathered under a creative commons license [3]. You can opt out of this completely transparent and well documented option.

[1] https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

[2] https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin...

[3] https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...

>No, but I would expect you to read the release announcements. [2]

Yeah, well...where is it?

https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcin...

https://github.com/dotnet/core/blob/master/release-notes/2.0...

Or do you seriously expect me to read every beta/RC release note of versions I won't ever use for elementary issues like this?

> I expect someone who cares about telemetry to search for it. It is well publicised, discussed, and available

I missed it, maybe I was on holidays at the time or just missed the headline, unfortunately I'm quite fallible.

> There is a telemetry warning when first using the tool.

This is assuming it was run manually, by a user at the command prompt and that it wasn't buried in thousands of lines of output. Those are all false assumptions. If I set makeprg to "dotnet build" in vim for instance, I'm only going to see filtered output (compile errors). Visual studio and other tools will also hide a lot of the raw output.

> No, but I would expect you to read the release announcements

Silly me trusted them, lesson learned.

It collects redacted usage data for dotnet development commands - e.g. dotnet restore for package management - not run a backdoor on your production servers like the title implies. If you scroll down the thread you'll see that it doesn't even collect arguments you pass to the commands.

If you think that npm or any other tool you use doesn't do the same you are delusional.

Well, it is an opt-out feature, which is already a way to purposely collect data if you're not playing attention enough. Plus, if npm has such flaw, this is still no excuse for Core to do the same.

Visual Studio Code also has opt-out telemetry enabled by default, with no warning (that i've seen).

https://code.visualstudio.com/docs/supporting/faq#_how-to-di...

People don't read TOS, Agree the terms and then complain. If this kind of privacy is really important for people, they should at least read TOS.

https://code.visualstudio.com/license

> DATA. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. There may also be some features in the software that enable you to collect data from users of your applications. If you use these features to enable data collection in your applications, you must comply with applicable law, including providing appropriate notices to users of your applications. You can learn more about data collection and use in the help documentation and the privacy statement at http://go.microsoft.com/fwlink/?LinkID=528096&clcid=0x409. Your use of the software operates as your consent to these practices.

Extremely disappointing.

First we had to keep a close eye on our browsers, now we have to keep track of our text editors, dev tools, operating system, and even our own hardware. if we're really lucky, some will have some obscure way of limiting it.

Making you job easier and improving your product are not valid excuses for this kind of despicable behavior.

When I set up my next dev machine, everything will be sandboxed or the entire machine air-gaped. Some developers and software vendors can no longer be trusted.

> if we're really lucky, some will have some obscure way of limiting it.

In this case, it tells you how to completely turn it off the first time you use it.

Is there any reason this matters? Besides the automatic reaction of "data = evil" that I'm seeing, I see no reason why it even remotely matters that this data gets out.* I see no practical way MS could benefit from this other than by improving the open source project. Maybe if they reallly wanted to they could link your IP to a Facebook/Google account so you could get ads for developer tools? Is there actually a good reason to turn this off?

* I'm assuming MS is being honest about what they're collecting in their documentation. If someone has evidence that their sources/binaries say something different, feel free to bring it up.

> I see no practical way MS could benefit from this other than by improving the open source project.

Then why don't they make it opt in?

> Is there actually a good reason to turn this off?

Security. In the sense of "enable only needed features, to reduce attack surface".

Of course it would be even better to not have it turned on by default in the first place.

Microsoft comes from a place of being automatically distrusted by a lot of people, and for good reason. It may seem unfair to you, but they have to conduct better than this to make up for this disadvantage.

> Then why don't they make it opt in?

Perhaps because they think it is a reasonable default that few people will want to change (vocal minorities and all that)? Curious if anybody who does opt-in telemetrics has stats on first-time downloads vs telemetry enables.

> Security. In the sense of "enable only needed features, to reduce attack surface".

I’d assume that the attack surface here is pretty small (HTTPS request via the standard mechanism, ignore the response). If .NET HTTPS APIs are broken, we’ve got bigger problems. At the end of the day, everything is a cost/benefit, and it seems like this is something pretty hard to get wrong + pretty large tangible benefit for the project.

> Then why don't they make it opt in?

Because opt-in telemetry doesn't really improve the open source project. It no longer provides a representative sample of the usage patterns in your app that you can use to guide your further development or maintenance efforts; the people that would opt-in majorly overlap with the people who are also willing to file issues and seek help channels.

My first reaction was "if you're really worried about accidental/malicious exfiltration I'm sure you're running your servers WITHOUT unfiltered outbound access to the internet, RIGHT?"

You're right, but at the same time you should not have to. Software should be secure by default.

Software is buggy by default. That alone is enough to require you to not run with unfiltered access, if you really care about minimizing security risks. And if you do it (and you should) then this story doesn't affect you.

I agree though that transparency about data collection is important, especially for building trust.

Leaks data from production servers to a Microsoft run network.

What fun....

"Behavior The telemetry feature is on by default.

You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running."

Is running dev tools (compilers etc) on production servers a thing? I have always built on my machine (or build server) and then deployed to production.

That's the way to do it, use a build server, deploy with something like Octopus to production.

Fear mongering, it's relatively benign telemetry. Also needs (2016).

That's not for you to decide. It's meant to be the user's call.

It is. You're informed about it and you can opt-out.

Thanks, we added the year.

It started in 2016 but it's not over. There are comments from a few minutes ago, maybe because of this HN thread, and tales of things that went wrong recently. Example: a failed HIPAA inspection.

I'd take the year away, not to make people think it's not relevant anymore.

Ok, we've taken it out.

Yes, that is correct. Not sure what triggered this renewal of the campaign on the part of the opposition. Maybe this post on today's Microsoft discussion (re: Windows Phone abandoned)? https://news.ycombinator.com/item?id=15434859

Microsoft/.Net Foundation added telemetry to the dotnet command line last year | https://news.ycombinator.com/item?id=14836737 (Jul 2017)

I’ve been at it for a while. I’ve learned that if you want something to change you don’t let it go.

... that's not absolutely right. There is way more than simply "don't let go."

It's mind-boggling that people here are equating smartphones, browsers to development utilities. This is not something I would expect in Go, node, ruby ... but it's OK because it's .NET build utilities? How is that FUD?

To all the posters saying it's harmless. What's your stance on your source code being uploaded on crashes while you develop your app with new IP in it?

All of this can be "shut off" through options during install and first usage.

I accept that point. I also raise a counter point of Microsoft overwriting privacy customization such as that, on subsequent updates, regularly.

Do you have any evidence that this occurs? It doesn't seem to appear in MS's documentation.

If you have a debug build the source is included automatically (as debug information).

MS reserves the right to look at memory dumps and crashed binaries "to improve the customer experience" or something...

Take these two things together, and... you lose your source code :-(

(Assuming this is true) That’s Win10, not .NET. That would happen regardless of the telemetry discussed here.

if you genuinely fear this then go build tons of drivel and make it crash giving them too much to look at. The idea that MS are busy analysing arbitrary crashing code really suggests they have more time on their hands than sense. Getting people to read code is expensive as fuck.

I can analyze the data and discern real from false information pretty quickly. The thing about massive amounts of data is that patterns emerge pretty readily.

patterns are lossy abstractions though. That arrogance might bite ya one day.

This telemetry is tracking the `dotnet` commands used (i.e, how the CLI tool is used).

If that is true it is of course bad, but since I host my stuff in Azure they have my source code already.

This title is very misleading... The code is open source. And it is NOT spying on the user. I understand an opt-in model is typically preferred. This title is about as click-bait-esque as it gets though.

"FYI: Microsoft

The fact that this is an opt-out vs. opt-in and the opt-out procedure is based upon an env. var. just caused dotnet to fail an externally conducted HIPAA privacy/security audit at a genome testing lab in the backyard of your main campus.

Lucky for us, we were able to convert the runtime to use Mono and get a temporary pass, but this killed the future CIL-based projects with the lab's management..."

Ouch!

Would you no be able to build a version with the telemetry disabled?

Yeah, not exactly super hard to find the info:

https://github.com/dotnet/cli/pull/2145

"There is a way to opt-out of the telemetry gathering process by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT. Doing this will stop the collection process from running. "

But why? It's a single environment variable to turn it off. That HIPPA comment raises more questions about their dev practices if they're running dev SDKs on production servers or can't set a single env variable.

I know that this subject is super important to some people on this site, but it literally tells you when you execute the command how to turn it off.

Also, the thread seems to have people from MS (the core team) actively soliciting feedback and wanting to work with users. They published a blog post before they started collecting telemetry, so it wasn't unannounced.

There are lots of ways that this could be worse. Maybe we shouldn't slap their hand when they are doing a pretty good job?

I can see how this is still completely unacceptable if you are a privacy maximalist, but most people aren't.

There is no real evidence that something substantive is coming out of this feature. It definitely seems to be doing more harm than good.

What do you base that on?

I'm sure this recently discussed on HN.

Maybe we should change the name of the industry from software to spyware.

.NET core collects telemetry. This isn't really any different than loads of other applications, but it's microsoft instead of google so booo hiss evil evil evil.

From the people that brought you Gmail man these hypocrites never cease to amaze. The telemetry they're sending back from their OS wasn't enough so now they're sending telemetry from their language tools - unless, of course, the user proactively turns it off which they probably never do because their not directly told about the data collection.

Reply on news.ycombinator.com