Let’s start by stating something I believe is so obvious it shouldn’t need stated:
You should not have to worry about your tools spying on you.
You should be able to run a command that doesn’t use the network, knowing that it won’t open a network port. You should be confident that your tool is doing its best for you, not reporting back on you to someone else. In short, you should be able to run software without it looking over your shoulder like a voyeur with a clipboard.
But nearly a year ago that kind of spyware is just what Microsoft/.Net Foundation added to the dotnet command line.
I’ve been using the dotnet core since well before then and I never knew about this. And I’m one of the few people I know who tries to keep up with this kind of nonsense! I feel foolish and embarrassed for not knowing about this spyware when it was added. And maybe my embarrassment at having been spied upon for months is colouring my judgement a little. But I still believe it’s wrong.
I’m sure they’ll say that it’s to improve the tools, but - while I have my doubts that’s true - it does bring up the question:
Would you prefer a tool you can just trust, or a tool that may have better features but that you constantly have to check to verify isn’t doing anything it shouldn’t?
I’d rather be able to trust my tools. I just don’t like the idea of a voyeur with a clipboard watching over my shoulder, sating its prurient interest by taking notes and gathering statistics.
This dotnet voyeur then sends these notes and statistics to Microsoft without asking the user.
Your only chance of opting out is knowing the special environment variable incantation to use.
But maybe they’ve tweaked it so that today it’s sending files as well? They managed to sneak the first change past me, so have I missed another? No? Maybe not. But tomorrow? I can’t know, since they’ve demonstrated I can’t trust them or the tool they created.
What used to be a simple ‘dotnet run’ command has turned into something that has me watching my back. Why are they so interested in my typos that they’ve paid someone to sit down and write code to capture them? If they actually want to improve the product, why not have that developer writing code that adds new features rather than spying on me?
And that’s why it’s not a minor thing. I’m not (quite) so arrogant that I think Microsoft is targeting me. I don’t even think they’re especially interested in the telemetry from ‘dotnet run’. It’s that they’re seeking to normalise this spying that makes it more than a minor problem.
We’ve seen this with Windows 10 hoovering up all the data it can get, just like Facebook, Google, Apple and Amazon. It’s in all their interests to have us become inured to this constant surveillance. And I don’t like it.
Homebrew faced a similar issue around the same time dotnet introduced their telemetry. I noticed the Homebrew debacle but didn’t notice the introduction of telemetry in the tool I use all the time. (I’m still embarrassed by that.) To show I’m not the only person concerned about telemetry-gathering tools, here’s a blog post about Homebrew - ‘Homebrew betrayed us all to Google’. It starts with the summary:
- Open-source is about trust. Trust is underminded by things like tracking.
- Do not track your users. In the rare case you really need anonymous data, ask your users first.
- Never use Google products (or any other “big data” company that relies on making money out of the data you provide) to track your users.
- Using Google’s tracking and then calling it “anonymous” is a lie. Google collects tons of information of its users and even non-users. There’s no way to know what data Google will relate internally. Even if you don’t get to see all of the collected information, Google still has them.
- Opt-out is never an excuse. It always excludes most users (which either don’t care, or have more severe things to care about than protecting their privacy in every random app they’re using).
(Source: ‘Homebrew betrayed us all to Google’)
Homebrew backed down a little and provided a better opt-out mechanism, but it annoyed a lot of people. (More, probably, than are annoyed at Microsoft. Let’s hear it for low expectations!)
Opt-out mechanisms aren’t really enough though. For one thing, why should I have to opt out when I didn’t opt in in the first place? For another, that may fix it for me, but I don’t want your tools spying on you either. For a third, the opt-out procedure is (deliberately?) awkward.
It’s not something you just pick, it’s something that needs to be set for every user on every machine in every shell and every container. And you need to get it perfect every single time, or else the tool will assume it can report back on what you’re doing.
Opting everyone in automatically as Microsoft have done is just plain dishonest. There’ll always be some portion of users who’d opt in, some portion who’d opt out, and some who’d go with the default. But you know what, Microsoft? Those people who wouldn’t have opted in but who haven’t opted out? They’re the ones whose data you’re taking without permission. You just don’t have permission to take that data. (Don’t start me on EULAs when the person agreeing to the EULA may not be the person running the software…) You don’t have informed consent here, because you didn’t actually ask. Worse - you know that if you asked for informed consent, you might not get it. That’s an argument against spying on people, not an argument for spying and not asking.
And that’s before you get to people like me who - despite what you consider ‘transparency’ - didn’t even know there was a possibility of a voyeur with a clipboard looking over my shoulder.
So how could Microsoft fix the issue?
There’s really only one fix I’d like - take the spying code out of the tool completely. If there are people who really want to send their telemetry to Microsoft, by all means find a way to accommodate them. But don’t put spying code into the tool. Keep it clean. Have the telemetry spyware in a separate module that has to be explicitly downloaded and installed. (Call it ‘Voyeur.DLL’ if you like.) Keep the core pure.
And have a strong ‘Private By Default’ policy. Allow people to feel safe using your tools. It’s hard enough keeping up with the latest in technology without having to keep up with the latest in obnoxious business practices.
Private By Default would mean guaranteeing that it never gathered any information on you, even in aggregate. That it never sent any data that you didn’t explicitly ask it to send. That it never opened any network connections you didn’t ask it to open. That it never did anything not explicitly to do with carrying out the user’s intent.
In absence of that, what can I do to stop it spying on me?
- I could just not use dotnet. For me this is the easiest and the hardest approach. It’d be easy because just walking away from dotnet would mean it’s not my problem any more. There’d be no voyeur looking over my shoulder. It’d be hard for me too though. I’m getting to the point where a large side project is becoming useful, and it’s based on dotnet. It’d be difficult just to walk away from that.
- I could block telemetry traffic on the router or firewall. Here’s someone’s (not my) best guess at the hosts to which it sends data. I like the idea of ISPs blocking all those hosts - denying access to login.windows.net because of Microsoft’s telemetry-gathering could be hilarious.
- I could wrap the dotnet command in a script that automatically sets the environment variable for every single invocation of the command. Here’s one way to do it:
echo "Trying to run a non-spying version of dotnet..."
DOTNET_CLI_TELEMETRY_OPTOUT=true /usr/local/share/dotnet/dotnet $*
(That’s for bash on OS X - if you call it ‘dotnet’, make sure it’s on your $PATH ahead of /usr/local/share/dotnet/dotnet.)
- I could add the environment variable to every single RC file for every single shell for every single user. And every single docker file. For every single development machine and server.
I’ll be doing a combination of all those things. I might keep using dotnet for existing projects, but I’m fucked if I’m starting any new dotnet projects now.
The ‘tech stack’ conversation has come up in $WORK a few times recently. Where before I’d have talked about dotnet core I’m sure as hell not going to now. I won’t just not be talking it up, I’ll be actively talking it down and discussing alternatives.
From a wider perspective, what could I do to fix the root of the dotnet spying problem?
- Rewrite the part of the tool that calls the spying code. It’d be easy enough for me to fix (it’s right here), but that wouldn’t solve the problem of Microsoft writing tools that spy on users, it would just stop my version of the tool from spying on me. Your version could still spy on you.
- Send the code change to Microsoft as a ‘pull request’. I think we both know what would happen with that.
- ‘Fork’ the code, and provide a binary distribution of the fixed/improved code so that everyone that wants can use it.
- Start a ‘Private By Default’ campaign in the hope we can shame Microsoft into behaving better.
But you know what? I’m not going to do any of that. I’m just going to point out why I think it’s wrong, then try moving on to using better, more trustworthy tools. I’ll still use it for current projects but I’ll be trying to move away from the platform.
Today I was planning on settling down to read the new AssemblyLoadContext design document pull request and delving a lot deeper into that area. My dotnet project needs to generate and load assemblies in different contexts and it has got as far as it can without this kind of functionality. I might even have written a blog post about it. After all, it’s an area not well served by others and the documentation doesn’t go into a lot of detail about how to use the API.
Instead I’m writing about how dotnet has managed to shatter my trust.
I’ve no enthusiasm for working with dotnet now. No desire to watch the weekly ASP.Net standups. No desire to write C#. No desire to work on my side project built on dotnet core MVC.
I keep looking around for the voyeur with the clipboard.