NoelC Posted October 30, 2015 Posted October 30, 2015 (edited) With Windows 10 getting all the hot "Privacy Invasion!" press lately, I thought it's worth mentioning that an updated Windows 8.1 system is as likely to send your data abroad as Windows 10. Perhaps even MORE likely, since there aren't as many tools of the genre "ShutUp8.1"! The subject is finally getting good attention. I've long since thrown all the switches on my Win 8.1 x64 Pro MCE system to the most-private settings, I use a local account, and I have no Metro/Modern/Universal Apps. OneDrive is completely off as well. I've developed a "deny-by-default" firewall configuration based on Sphinx Windows Firewall Control that blocks things I haven't specifically given permission to communicate. You'd be surprised at how many communications are STILL attempted by the operating system itself. As an experiment, with the firewall and full monitoring in place, I left the Windows Update service not running for the past several days. The following is a summary of what I saw: The encrypted communications, marked in red, may represent clandestine attempts to send telemetry or personal data to Microsoft. I attribute the several connections marked in blue at the end to a possible "secret" Windows Update attempt. Unwanted Win 8.1 communications my firewall has blocked in the last few days: TCP 23.1.117.231:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using my login IDTCP 23.13.70.176:80 - Akamai Technologies (CDN), Cambridge MA - by dllhost.exe using SYSTEM login IDTCP 23.14.181.100:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using SYSTEM login IDTCP 23.39.131.234:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using my login IDTCP 23.62.165.99:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using SYSTEM login IDTCP 23.96.212.225:443 - Microsoft Azure, Redmond WA - by Microsoft Windows Malicious Software Removal ToolTCP 23.218.211.122:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using my login IDTCP 104.41.32.78:443 - Microsoft Azure, Sao Paulo, Brazil - by Microsoft Windows Malicious Software Removal ToolTCP 108.162.232.196:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.197:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.198:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.199:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.200:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.201:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.202:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 108.162.232.205:80 - CloudFlare, San Francisco, CA - by svchost.exe using my login IDTCP 172.224.184.228:80 - Akamai Technologies (CDN), Cambridge MA - by dllhost.exe using SYSTEM login IDTCP 191.237.208.126:443 - Microsoft Azure, Wichita, KA - by Microsoft Windows Malicious Software Removal ToolTCP 191.238.241.80:443 - Microsoft Azure, Wichita, KA - by Microsoft Windows Malicious Software Removal ToolTCP 192.204.82.178:80 - NTT, Orlando, FL - by Windows Media PlayerTCP 192.204.82.210:80 - NTT, Orlando, FL - by Windows Media PlayerSpecifically blocked on Win 8.1 late last night while the system was idle: TCP 104.73.11.204:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using my login IDTCP 23.62.165.99:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe using SYSTEM login IDTCP 23.218.211.122:80 - Akamai Technologies (CDN), Cambridge MA Win 8.1 Communications that have succeeded, since I've specifically whitelisted the address or protocol ICMP - 23.99.222.162 - Microsoft, Redmond WATCP 178.255.83.2:80 - Comodo (Certificate Revocation List server), London, England - by svchost.exeTCP 93.184.215.200:80 - Edgecast Networks (Certificate Revocation List server), Wichita KA - by svchost.exe In the past I have whitelisted the following addresses to allow a successful Windows Update, but communications with these happened autonomously without my having requested a Windows Update These concern me, as they may represent an attempt by the system to do a "secret" Windows Update. It is apparently not fully possible to lock a system down with just a firewall alone and still allow Windows Updates. This is why in general I advocate disabling the Windows Update service when I'm not looking to actually do a Windows Update. TCP 23.14.84.57:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exeTCP 23.14.84.113:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exeTCP 96.16.98.112:80 - Akamai Technologies (CDN), Cambridge MA - by svchost.exe I'll be continuing my test a bit longer to see what the system will try to do on its own if Windows Update is left disabled. -Noel Edited October 30, 2015 by NoelC 1
Ridrok Posted October 30, 2015 Posted October 30, 2015 (edited) Thank you for sharing this NoelC. With updates from Mai until now, Win 8.1 smells like a Win 10 in privacy aspect. I did not check personally for a month since I came to the conclusion that the only viable solution was:1) to disable Win Update service (and bits service to free memory used for nothing)2) to remove all updates since April 2015. I have a quiet Win 8.1 (with aeroglass, Classic Start Menu, Opaque TaskBar, SwiftSearch...) and am happy with this to develop software, encode video, play WoW.... Sure I understand you in checking all possible solutions because I don't feel comfortable in having a fixed version which will age forever, and can't switch easily to Linux since I mainly develop for Windows platforms and playing with Wine is just not a good solution. But since I lost my trust in MS now, I really feel trapped with a hope one day an OS like and compatible with Win 7 will emerge. My 2 cents.Ridrok Edited October 30, 2015 by Ridrok
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now