Stories
Slash Boxes
Comments

SoylentNews is people

Windows Snooping Patches KB 2952664, KB 2976978 Are Back (Again)

posted by on Friday March 10 2017, @03:28PM   Printer-friendly
from the malware-or-spyware,-you-decide dept.

MrPlow writes:

Submitted via IRC for TheMightyBuzzard

Windows Update came roaring back today [Mar 7] after more than a month in a semi-comatose state, and the chute filled up quickly this morning. Windows Update seems to be working well -- even more reason to check your Win7 and 8.1 systems and make sure it's turned off

[...] More disconcerting are the re-re-releases of KB 2952664 (Win7) and KB 2976978 (Win8.1). As I explained last month, those two patches have, in the past, triggered a new Windows task called DoScheduledTelemetryRun.

Even proponents of installing all Win7 and 8.1 patches balk at those patches, which were born in the crucible of the Get Windows 10 (GWX) marched upgrade madness. The series was renumbered, with no explanation: KB 2852664 was renumbered from revision 25 on Oct. 4, 2016, to revision 12 today. Microsoft states:

This update performs diagnostics on the Windows systems that participate in the Windows Customer Experience Improvement Program. The diagnostics evaluate the compatibility status of the Windows ecosystem, and help Microsoft to ensure application and device compatibility for all updates to Windows. There is no GWX or upgrade functionality contained in this update.

Yet it appears as if the scheduled task runs whether CEIP is enabled or not. If there's a reason for installing the patches, other than increased telemetry, I haven't heard about it.

Source: http://www.infoworld.com/article/3177812/microsoft-windows/windows-snooping-patches-kb-2952664-kb-2976978-are-back-again.html

Original Submission

 
This discussion has been archived. No new comments can be posted.
Windows Snooping Patches KB 2952664, KB 2976978 Are Back (Again) | Log In/Create an Account | Top | 65 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by urza9814 on Friday March 10 2017, @07:58PM (1 child)

    by urza9814 (3954) on Friday March 10 2017, @07:58PM (#477496) Journal

    An industrial motion control system we use is built on Windows and requires special drivers and kernel level stuff that can't be ran on Wine. A lot of Industrial systems run Windows (scary, right?), have windows only HMI's, or have development tools that are Windows only. For me, it's a long road out of Winhell.

    Those kinds of tools cost big money though, right? Big money that could be used to GET it working on Wine rather than purchasing new software perhaps? Or does it even matter -- aren't a lot of those types of systems on some (hopefully) air gapped XP box? Are you really running that kind of stuff on _Windows 10_?

    Personally I find the exact opposite anyway though -- I've given up on Windows because the few pieces of Windows software that I *do* still want to run won't run on Windows anymore, but they run just fine under Wine...

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by LoRdTAW on Friday March 10 2017, @11:11PM

    by LoRdTAW (3755) on Friday March 10 2017, @11:11PM (#477582) Journal

    Unfortunatly, it's not my call. For management: If it ain't broke, don't fix it. Though, I do use Linux where I can. Some general use shop floor PC's run Mint and I'm contemplating writing a PLC engine that's POSIX compliant and running it on Linux or OpenBSD. I did some experimenting with Opto22's OptoMMP protocol and libmodbus. The HMI would simply be a terminal application written using ncurses or termbox. If the machine goes down, I could SSH into it remotely and run diagnostic tools right from the command line. Though half the time I'm fixing broken stuff.