No kidding. This does not inspire confidence. v9 already does weird things like show stopped cars bouncing around randomly. This kind of thing along with crazy branding really makes it feel unsafe.
It’s one thing that the stereo goes to 11, that’s funny. But I’m not going to die if the stereo has a bug.
The real question would be "inflation adjusted per-capita tax receipts over time" but a mid-work googling didn't turn up anything promising; that being said from the above graph _and_ the knowledge that inflation is increasing, your statement doesn't seem to mesh. Feel free to point out if I was really thick and got the wrong data or something.
I know a lot of people don’t like things like this, but also remember not all data collection is malicious. If you look at what they actually collect it’s not pulling a bunch of personal info. They collect usage, perf and errors. As a product manager (not for vsc or MS) I use this type of telemetry all the time to make priorization decisions. It’s a balance, but my hunch is the team at MS uses this info exclusively to make the product better.
Of course, you should always be able to disable this sort of collection.
No, you should ALWAYS explicitly ask for user consent. You should explain exactly what kind of data is being collected and how it's used and ask them if they are fine with that. Anything else is unethical.
I'll happily enable certain kinds of data collection when a tool is transparent and it makes its data collection opt-in.
Even if we accept that scrubbing of personal data is possible, which is far from certain, that theoretically non-malicious traffic still provides camouflage for malicious traffic. If we insist on opt-in, then we can apply a very simple and fail-safe heuristic: any traffic the user didn't explicitly request is malicious. There's no need for slow and error-prone analysis.
And how in the world do you intend to distinguish traffic?
How do you intend to tell the difference between Atom's and VSCode's Git(hub) integration, app updater, package manager, telemetrics or an exploitation? The difference between a Signal, WhatsApp or Telegrams' messages and their telemetrics?
Your proposed heuristic only works for applications that would not otherwise have any network traffic, and even then, only if you do on-machine per-process network monitoring. Once it has any valid traffic what-so-ever (which is the case for basically any modern GUI application), then you quickly descend into needing to disassemble binaries locate the cause.
Opt-in vs. opt-out is about privacy and rights, not about security. Malicious companies whose traffic are a security breach and things down those lines are problems that belong in an entirely different discussion, whose root-cause is much deeper than opt-in vs. opt-out.
Also, regarding scrubbing: A stack-trace and error message is far from private identifying information. No harm done in sharing it.
If I select a git command from a GUI, that's an explicit request by the user.
>app updater, package manager
If something legitimately requires background network activity, and security updates might qualify, it should go in Crontab. The system should have exactly one package manager, and apps should not re-implement their own.
None of this makes any sense unless you're manually authorizing all connect()/write() calls, manually monitor network traffic and correlate it in real-time with user actions, or have some form of surveillance software to automatically do this for you. All of these seem extremely improbable.
Otherwise, on the network, git fetch and telemetrics to github will be indistinguishable (except if you start doing opaque data pattern analysis). There's also no automatic correlation on the network.
On the machine itself, the closes you could get is something like Little Snitch, which still won't be able to help at all, as permitting Atom to speak to Github on port 443 will permit everything while disallowing will block everything, and it's also designed to be a manually populated whitelist, rather than a constant authorization system.
> If something legitimately requires background network activity, and security updates might qualify, it should go in Crontab. The system should have exactly one package manager, and apps should not re-implement their own.
First of all, eww. Nothing is worse than updates running on a crontab, causing shit to break because it updated automatically.
Also, welcome to 2018. Everything outside Linux bundle their own updater, and on Linux, flatpak and other newfangled things bypass most package managers (even with dnf's flatpak integration, it's still not going through any yum repos).
Internet access is still pretty variable throughout the world (or even within countries that can have good speeds, like the US). Anything randomly uploading megabytes is going to cost somebody an unreasonable amount of money so there should be consent.
I agree. Most telemetry gathering is not malicious. But I always disable it simply because I use a lot of software. Telemetry from all of it would just be a big outgoing stream of data all the time.
Microsoft is a very big company and I have absolutely no doubt that the Windows team and the VSCode team hardly ever—if at all—talk.
I also question how 'evil' policies like this could propagate across company divisions to the point where they are actually implemented in code—in today's age where engineers have a lot of agency over what they do and often speak up—without someone leaking said policy.
You have to remember that giant corporations are actually many small teams trying to work on their own problems. So the “shit” to one team may very well be mission critical to another team. Part of the manager’s job is basically deciding when it makes sense for two teams to work together (I.e. let the “shit” through) and when it doesn’t make sense and shield the team so they can focus on their work.
And at smaller organizations “shit” can take on different forms. I’ve seen a lot of “executive indecision” shit. Where the CEO or some big shot leader wakes up every week with a totally different idea and he thinks the engineers should drop everything and start working on it right away. The best managers can talk him off the ledge and let their team focus without even seeing this chaos.
As a manager at a big company, most of the shit I'm protecting my team from is not mission critical for some other team - it's the shit they don't want to deal with themselves and hope to drop in your lap.
> You see, they knew this process sucked - any reasonable person with half an idea about security did - but the internal security team alone telling management this was not cool wasn't enough to drive change. Negative media coverage, however, is something management actually listens to.
Are you sure the additional telemetry isn’t from extensions? Our extensions (Salesforce) have our own telemetry setting, but we do also respect the global VSCode setting due to this exact possibility of confusion. However, I know that there are other extensions that dont respect the global setting.
I tested without extensions back when I was following the open GH issues, so that wasn't the case then.
It could be that MS fixed the issue since, and the connections I see in logs now are from extensions, but I also presume this isn't the case as my firewall rules are IP-based rather than purely app based (since the latter would kill the market browsing functionality).
It’s one thing that the stereo goes to 11, that’s funny. But I’m not going to die if the stereo has a bug.