Official Windows 10 spying list
 

Today Microsoft released an official list of all the ways Windows 10 is spying on its users by calling it "diagnostics data". In the past most of these things were considered as horror stories and the only thing people could agree on was that the spying is so complex that only Microsoft knows what is transmitted.

https://technet.microsoft.com/itpro/windows/configure/windows-diagnostic-data

And this is just a list of things Microsoft officially admits to. The special Windows 10 version for China which recently was released as beta version is supposed to contain even more spy functions...

There are a number of programs that configure windows with the intention of stopping the telemetry, but I havnt seen anyone validate if the tools work.

For example you could configure a machine then maybe intercept all the windows communication (has anyone actually decoded the telemetry data?), and watch for network connections when none should be happening on a clean install.

I noticed there is a persistent connection to a microsoft server for "push" notifications which was not disabled by tools like "shutup10"

I think I just ended up having to track it down and disable the service myself.

From the ones I have looked at, none of them seem to do a particularly great job preventing what I consider unwanted communication with microsoft... but this project seemed fairly good:

https://github.com/Nummer/Destroy-Windows-10-Spying/releases

Also you can run the LTSB version of windows 10, which probably wont change all your configuration without your permission, although I never really checked.

It's a good beginning if Microsoft publish collected informatons by Windows 10.
Only if they maintain the web page..

@surferxyz: i am using here shutup10. Do you think is best to user other program? I thought this was very complete. Thanks

I think shutup10 is alright as a quick way to setup a new windows 10 install, I haven't seen any research on exactly what communication is remaining from windows to microsoft after these tools are run.

But I can confirm that with shutup10 the "WpnService" (windows push notification service) is still running after you used the tool, resulting in a persistent connection to microsoft, which I feel like should be an option to turn off in the tool (and therefore I would say it is not doing a very good job/living up to its name). However I found basically all the other similar tools had the same deficiency.

I don't think any are "very complete", and I'd like to see a good technical review of what communication remains, and exactly what risks are involved with allowing unfiltered windows update communication.

Also I had the idea that, it might be good to intercept the windows update process, and use a out of band web of trust mechanism to confirm that everyone is also receiving the same updates (so for example preventing Microsoft from pushing out a backdoor update just targeting you/or a subset of users)

I know you can kind of do that already by using WSUS, but that seems too heavy for the simple kind of validation I have in mind.

I use Destroy Windows 10 spying in conjunction with Shutup10 plus private firewall to see where my beloved windows is connecting to.

werfault.exe send data Microsoft whenever application fault. Not matter what setting you place for "Windows Error Reporting".

You can disable with secpol.msc

Software Restriction Policy (if no exist), add policy.

Additional Rules. Right click; add Disallow entry. Type: Path .. Name: WerFault.exe

Does win10 collect these information by default? Is there any method to turn off this function?

I recently found the following project which uses a series of tools/wireshark etc, to periodically collect all the outbound connections windows is making:

https://github.com/crazy-max/WindowsSpyBlocker

I did a similar thing, where I just ran wireshark on my own system over night, and noticed that my current setup still missed a few things, and those things are actually present in the "WindowsSpyBlocker" list.

It is interesting at least.

I am not sure when they are ever called, but it might make sense to also restrict
WerFaultSecure.exe
and
wermgr.exe