Accessing Internet after update and telemetry was disabled

Question

I just installed the VScode Windows zip version with vim extension on Windows 7. For privacy I disabled these options in the settings.json file:

{
"update.channel": "none",
"telemetry.enableTelemetry": false,
"telemetry.enableCrashReporter": false
}

But VScode is still connecting to different MS Internet sites at startup:

• 191.238.172.191 Microsoft Informatica Ltda (br)
• 40.114.241.141 Microsoft Corporation (MSFT)
• 40.77.226.250 Microsoft Corporation (MSFT)

How can I disable VScode connecting to sites in the background I don't want to connect to?

Answer 1

Check also the version of Git you are using with VSCode.

Starting Git 2.19 (Q3 2019), possible telemetry can be sent from IDE/products using Git.

See commit 7545941 (13 Jul 2018) by Jeff Hostetler (jeffhostetler).
Helped-by: Eric Sunshine (sunshineco), René Scharfe (rscharfe), Wink Saville (winksaville), and Ramsay Jones (jeffhostetler).
^{(Merged by Junio C Hamano -- gitster -- in commit a14a9bf, 15 Aug 2018)}

Junio C Hamano, official maintainer for Git, added in this thread:

Transport (or file) can stay outside the core of this "telemetry" thing---agreeing on what and when to trace, and how the trace is represented, and having an API and solid guideline, would allow us to annotate the code just once and get useful data in a consistent way.

Ævar Arnfjörð Bjarmason added here:

To elaborate a bit on Jeff's reply (since this was discussed in more detail at Git Merge this year), the point of this feature is not to ship git.git with some default telemetry, but so that in-house users of git like Microsoft, Dropbox, Booking.com etc. can build & configure their internal versions of git to turn on telemetry for their own users.

There's numerous in-house monkeypatches to git on various sites (at least Microsoft & Dropbox reported having internal patches already).

Something like this facility would allow us to agree on some implementation that could be shipped by default (but would be off by default), those of us who'd make use of this feature already have "root" on those user's machines, and control what git binary they use etc, their /etc/gitconfig and so on.

So, in addition of Microsoft/vscode issue 16131, we will have to monitor how VSCode uses Git in the future, since Git will offer a telemetry framework, for editors to use if they choose to.

---

With Git 2.25 (Q1 2020), We have had compatibility fallback macro definitions for "PRIuMAX", "PRIu32", etc.
But we did not for "PRIdMAX", while the code used the last one apparently without any hiccup reported recently.

The fallback macro definitions for these <inttypes.h> macros that must appear in C99 systems have been removed.

See commit ebc3278 (24 Nov 2019) by Hariom Verma (harry-hov).
^{(Merged by Junio C Hamano -- gitster -- in commit e547e5a, 05 Dec 2019)}

git-compat-util.h: drop the PRIuMAX and other fallback definitions

^{Signed-off-by: Hariom Verma
Helped-by: Jeff King}

Git's code base already seems to be using PRIdMAX without any such fallback definition for quite a while (75459410edd (json_writer: new routines to create JSON data, 2018-07-13), to be precise, and the first Git version to include that commit was v2.19.0).

Having a fallback definition only for PRIuMAX is a bit inconsistent.

We do sometimes get portability reports more than a year after the problem was introduced.

This one should be fairly safe.

PRIuMAX is in C99 (for that matter, SCNuMAX, PRIu32 and others also are), and we've been picking up other C99-isms without complaint.

The PRIuMAX fallback definition was originally added in 3efb1f343a ("Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.", 2007-02-20, Git v1.5.1-rc1 -- merge).
But it was replacing a construct that was introduced in an even earlier commit, 579d1fbfaf ("Add NO_C99_FORMAT to support older compilers.", 2006-07-30, Git v1.4.2-rc3), which talks about gcc 2.95.

That's pretty ancient at this point.

[jc: tweaked both message and code, taking what peff wrote]
Signed-off-by: Junio C Hamano

Answer 2

I ran the program with Wireshark on linux and I can confirm the background connections.

The first address is for marketplace.visualstudio.com, so it's probably used for extension update checks or similar? If you use extensions you might want to leave it as it is.

The last addresses are most likely related to telemetry. Visual Studio Code makes several DNS lookups even though the telemetry and updates are "disabled". You can try to add some of those DNS names to your hosts file in order to prevent the connections, but keep in mind that doing so might have side effects on your system functionality as Windows uses them for other (telemetry and such) purposes. Here are a few of the DNS lookups I was able to trigger with a small testing, there are likely many more:

0.0.0.0 dc.services.visualstudio.com
0.0.0.0 dc.trafficmanager.net
0.0.0.0 vortex.data.microsoft.com
0.0.0.0 weu-breeziest-in.cloudapp.net

I share your concerns. Having 20 years of experience with Microsoft I'm very frustrated and scared of using any of their products. The license for Visual Studio Code does not fill me up with confidence either. I'm not really surprised that "opting out" of telemetry does not even actually disable it.

I do like Visual Studio Code more than Atom and instead of downloading it from Microsoft, I cloned the original vscode repository (which is MIT licensed base product for the Visual Studio Code) and installed it instead. It doesn't seem to connect to Internet immediately when I start typing. Unfortunately, I haven't figured out how I can easily update and install extensions to vscode, so I might have to return to Atom eventually. I wish someone with more interest and time on their hands would fork a telemetry free vscode with marketplace functionality and share the binaries for the rest of us.

Update:

I raised an issue (#16131) about this. Looking at the total amount of open issues (~3000) on vscode I don't expect it to be solved anytime soon. For the time being you should block at least vortex.data.microsoft.com and dc.services.visualstudio.com in your hosts file. Blocking those two won't affect the usage of marketplace or any other necessary functionality. Blocking them seems to cease most Internet traffic for Visual Studio Code 1.7.2 (which might change in future versions).

What also worries me is that even though the data sent to vortex is encrypted, Visual Studio Code actually sends details about your machine and OS unencrypted plain text (via HTTP POST) to dc.services.visualstudio.com. (Note that I didn't yet file an issue about that).

Update 2:

According to the official reply I got for the issue #16131, Visual Studio Code was sending the information to Microsoft that the user had opted out from telemetry. A bit odd choice to send telemetry about the user not wanting any telemetry, but they said that they will stop doing it in the future. I appreciate their honesty with this matter.

seanmcbreen:

We use our telemetry to help understand how to make the product better – in fact a good example of this right now is some work we are doing to improve performance. So, we appreciate it when users opt to send us telemetry.

That said there are times when people don’t want to do that and you bring up a good point – today we continue to send events stating that a user has opted out and nothing else i.e. no usage data is sent. Here is the test to ensure that is all we send... https://github.com/Microsoft/vscode/blob/master/src/vs/platform/telemetry/common/telemetryService.ts#L103

But we don’t need to do that and I don’t think it’s what you expect as a user – so we will stop sending anything i.e. even the opt out event 😄 Look for a change there soon.

Thanks for bringing this to our attention and I hope you enjoy working with VS Code.