VS 2015 VsHub - Another Chip Off the Win 10 Cloud?

[NoelC]

Just a few days ago I installed the new Update 2 of Visual Studio 2015 Community Edition.   It works well enough, but it brings back to mind an issue that saw with the earlier releases and worked around...

It wants to start VsHub components that don't appear to be needed, and which look like they're trying to share data with the world.

Several processes from folder "C:\Program Files (x86)\Common Files\Microsoft Shared\VsHub\1.0.0.0" are started, and remain running persistently when Visual Studio is run and after it exits: 

• VsHub.exe
• Microsoft.VsHub.Server.HttpHost.exe
• Microsoft.VxHub.Server.HttpHostx64.exe

Server?!?  I do NOT wish to have ANY program "share my data" without my knowledge, yet I cannot find a setting that stops VsHub from starting.  I've unchecked all the boxes I can find that might govern this activity, and yet these programs still start and run, and attempt to communicate online.

Things that auto-start and run in the background and serve your data to others online?  Shades of Windows 10 anyone?  Thing is, I'm not running it on Windows 10.

As of VS 2015 CE Update 1, I found that the VsHub processes could be blocked by removing Execute permissions.  I got a lot of positive feedback on the StackOverflow site for suggesting this.  Clearly I'm not alone in wanting my system to NOT become a "server of all Noel's data".  I'll probably investigate whether the same tweaks will work with Update 2, but...

Do you think "cloud integrated" software that provides no way to control its online participation is welcome?  Even when it's free?

-Noel

 

Edit:  Some hard info, just to prove I'm not being "tin foil hat paranoid"...

I closed down all VsHub processes, then traced the DNS names being accessed by Visual Studio on an otherwise idle system...

These were accessed during VS 2015 startup

• [19-Apr-16 10:09:49] go.microsoft.com
• [19-Apr-16 10:09:49] download.microsoft.com
• [19-Apr-16 10:09:51] az667904.vo.msecnd.net
• [19-Apr-16 10:09:51] az700632.vo.msecnd.net
• [19-Apr-16 10:09:56] vortex.data.microsoft.com
• [19-Apr-16 10:09:59] ocsp2.globalsign.com

These were accessed after I opened a solution

• [19-Apr-16 10:10:11] go.microsoft.com
• [19-Apr-16 10:10:23] crl.usertrust.com

This was accessed after I exited VS 2015

• [19-Apr-16 10:10:49] sqm.telemetry.microsoft.com

 

By my reckoning that's an update site, several Azure servers, and several Microsoft telemetry sites all being contacted either without or actively against my permission.  I have opted out of ALL CEIP settings everywhere I can find them, and I always disable ALL "auto update" functions.

Edited April 19, 2016 by NoelC

[mikedigitize]

I see some similarities in autocad. It's really annoying...

[qwerty12]

Not a new finding by any means (just Google the functions I've mentioned), but sadly, this isn't the worst thing about VS2015 in this regard. Build a simple hello world console program (hell, no need to even go that far: just keeping main() { return 0; } is sufficient enough for testing) using VS2015 and look at the imports table of the resulting exe using Dependency Walker/your favourite PE viewer. Even with a binary in Release mode, you'll find MSVC shoves in calls to functions like  __telemetry_main_invoke_trigger and __telemetry_main_return_trigger.

Maybe it's done so that the diagnostic component of VsHub can trace the process via ETW as according to https://habrahabr.ru/post/281374/ (a good analysis, worth using Google Translate for), nothing's written to the disk. 

I don't know if there's a proper linker option to turn it off, but the best way I found to avoid it is to add notelemetry.obj as the first additional dependency of any project that links with the VCRT, which will replace those telemetry functions with stubs and they won't be referenced in the import table.

Edited April 29, 2016 by qwerty12

[moataz]

Any idea about VS 2017, its named "C:\Program Files\Microsoft Visual Studio\2017\Community\Common7\ServiceHub\", but deleting/renaming it crashes VS.

[NoelC]

For VS 2015 as I mentioned you can use file system permissions to remove the privileges of VSHub.exe to run.  Note, don't ADD deny permissions, but rather uncheck the existing allow permissions for "Read & Execute".  Remember to look at whether an update has re-allowed them from time to time.

Unfortunately the above doesn't apply to VS2017.  That's quite a bit more complicated to control, since - as expected - the product has become much more cloud-integrated.

VS 2017 communicates with a LOT of different servers.  I've caught it trying to communicate with servers like the following to send telemetry:

az700632.vo.msecnd.net
az667904.vo.msecnd.net
vortex.data.microsoft.com

What I'm doing here to retain as much VS2017 functionality as I can while not allowing telemetry is to selectively block the resolutions of DNS names for several key telemetry reception sites.  You can see my extensive blacklists, part of which are regenerated daily, in this file in the dns_hosts and wild_hosts files:

http://Noel.ProDigitalSoftware.com/files/DNSListCompiler.zip

I have to admit that I'm not as confident in this setup blocking all unwanted comms since it IS being allowed to contact so many other sites, such as:

aka.ms
download.visualstudio.microsoft.com
go.microsoft.com
visualstudiogallery.msdn.microsoft.com

Keep in mind that whatever we can do to try to block their taking of information from us, they have already thought it through and have secondary and tertiary methods of retrieving it.  There's probably no real hope of maintaining complete privacy except to just not use modern software.

-Noel

Edited July 6, 2017 by NoelC

[HarryTri]

10 hours ago, NoelC said:

Keep in mind that whatever we can do to try to block their taking of information from us, they have already thought it through and have secondary and tertiary methods of retrieving it.  There's probably no real hope of maintaining complete privacy except to just not use modern software.

-Noel

Just don't trust any Microsoft's product from 2015 and afterwards.

[moataz]

10 hours ago, NoelC said:

Keep in mind that whatever we can do to try to block their taking of information from us, they have already thought it through and have secondary and tertiary methods of retrieving it.  There's probably no real hope of maintaining complete privacy except to just not use modern software.

I don't expect NoelC to run out of choices, they are human, and human do faults always, and they mostly put their efforts at useless things (like Ads), and we still have firewalls (I use this) and C:\Windows\System32\drivers\etc\hosts (which I don't like to edit it manually extensively).  

Most of the time I'm even blocking svchost.exe (BITS service), to prevent Windows or 3rd parties (like google chrome) from updating in background, I'm always monitoring network bandwidth (up/down), so I know When and Who is making traffic, if I allow it to do so in the 1st place.

And I never used w10 before, so I'm bit optimistic than you NoelC 

[HarryTri]

For monitoring traffic: NetBalancer (free for monitoring traffic, just a prompt to activate when you open it after the trial period expires). You can see which application communicates with whom, when and how much it uploads/downloads (with Windows 10 we reached the spot where the uploading is more suspicious than the downloading...).

[UCyborg]

Diagnostic Tools do not work with disabled VsHub.exe.

PS: I'd like to note that the meaning of "server" depends on the context. It can be used for nothing more than inter-process communication. Though they do acknowledge that telemetry is also part of VS Hub.

VS2017's VS Hub hosts more functionality of the IDE, probably why it refuses to work without it. I'd say if you find the whole thing fishy, probably the best to not use the software at all, rather than worrying about what each process hosts. At least that would be good for sanity.

Edited July 7, 2017 by UCyborg

[moataz]

1 hour ago, UCyborg said:

VS2017's VS Hub hosts more functionality of the IDE, probably why it refuses to work without it. I'd say if you find the whole thing fishy, probably the best to not use the software at all, rather than worrying about what each process hosts.

I don't care about privacy much since I block VS (devenv.exe itself) most of the time, I just don't want useless processes to consume my RAM/CPU.

By the way I found a solution to prevent vs2017 servicehub.*.exe from running along with devenv.exe, without crashing, but I don't like Microsoft to know about it now.

Edited July 7, 2017 by moataz

[NoelC]

I have been busy getting some releases ready, so I haven't had time yet to experiment further with VS 2017.  At the moment I have it in a pretty good place, with the telemetry sites being blocked by DNS, but like moataz I'm always interested in getting things to run in the most efficient possible ways.  If a build goes 10% faster because of it, that's less waiting and more work I can get done in the same amount of time.

-Noel

[Dibya]

Well I am using vs 2015 pro for months.  I am not at all satisfied. 

[moataz]

This is a small tool that kills Visual Studio 2017 ServiceHubs, here.