* Basic error information to help determine whether problems your device is experiencing can be addressed by the update process.
* Information about your device, its settings and capabilities, including applications and drivers installed on your device, to ascertain whether your device is ready for and compatible with the next operating system or app release and ready for update.
* Logging information from the update process itself to understand how well your device’s updates are proceeding through the stages of downloading, pre-installation, post-installation, post-reboot, and setup.
* Data about the performance of updates on all Windows devices to assess the success of an update’s deployment and to learn device characteristics (e.g., hardware, peripherals, settings, and applications) that are associated with the success or failure of an update.
* Data about which devices have had upgrade failures and why to determine whether to offer the same upgrade again.
The most egregious of that list is, imo, this:
* Information about your device, its settings and capabilities, including applications and drivers installed on your device
> The most egregious of that list is, imo, this: Information about your device, its settings and capabilities, including applications and drivers installed on your device
How is it possible to know what updates to install without checking this information?
A. Software Update process provides your local machine with a list of available updates.
2. Software Update process includes metadata that indicates what local machine conditions should be satisfied to warrant installing a given update.
D. Local machine checks the metadata against its own settings, capabilities, applications, and drivers to determine a matching condition to select and apply relevant updates.
Is that practical with the sheer number of different drivers/updates that can be delivered through WU? And wouldn't they get the information anyway when they see your machine in the access log for the update files?
The local machine only needs a manifest of available updates and its local state to determine what updates it requires. The potential size of the manifest doesn’t strike me as a good reason to exfiltrate more data from the local machine. There are myriad options for limiting the size of the manifest into something more manageable—say, splitting it into many smaller manifests—and let the local machine identify the updates it needs. An access log isn’t going to provide the Update Provider the same level of data that transmitting local settings, capabilities, applications, and drivers would—or the Update Provider will have to write additional software to turn access logs into best-guess approximations of, at most, apps & drivers being downloaded by a particular IP. However, the local machine still retains more information about itself than is otherwise given up by blanket data collection of its settings, capabilities, applications, and drivers.
The collection of massive amounts of data is not necessary to provide a collection of available updates and leave it up to a local machine to determine which of those updates it needs to apply.
https://support.microsoft.com/en-us/help/4468236/diagnostics...
Required telemetry (that cannot be disabled):
* Basic error information to help determine whether problems your device is experiencing can be addressed by the update process.
* Information about your device, its settings and capabilities, including applications and drivers installed on your device, to ascertain whether your device is ready for and compatible with the next operating system or app release and ready for update.
* Logging information from the update process itself to understand how well your device’s updates are proceeding through the stages of downloading, pre-installation, post-installation, post-reboot, and setup.
* Data about the performance of updates on all Windows devices to assess the success of an update’s deployment and to learn device characteristics (e.g., hardware, peripherals, settings, and applications) that are associated with the success or failure of an update.
* Data about which devices have had upgrade failures and why to determine whether to offer the same upgrade again.
The most egregious of that list is, imo, this:
* Information about your device, its settings and capabilities, including applications and drivers installed on your device