> diagnostic data collection (telemetry) is not enabled for private builds
> this data collection is covered by windows 10 privacy, You can find the windows 10 privacy statement and details of controlling the diagnostic and feedback settings here.
So if you build from source, you can disable it, and if you don't build from source but install it from the store, then telemetry is controlled by the central privacy settings in Windows 10.
Presumably this would be a problem only if you specifically don't want MS to have telemetry from winget, but you also specicifically want them to have telemetry on the rest of your OS, which would be... weird.
You're technically correct for some use cases. For Windows 10 Enterprise users, the official tool does allow you to disable telemetry by modifying the system telemetry settings.
For Windows Home and Professional users, this is not the case. Disabling telemetry is not possible because Microsoft have decided that there is a minimum "required" amount of telemetry every OS installation must send in order to function.
If the telemetry description stated that some Windows users are able to opt out, they'd be correct.
It's just another example of Microsoft showing they couldn't give a rat's ass about their customers' wishes and that you'll just have to deal with them tracking everything you do.
And who knows? Maybe I do like to contribute to Microsoft about kernel bluescreens so that Windows can get more stable, but do not wish to upload a report every time I install or uninstall software? Why would it be strange that I don't like to share some telemetry but not all telemetry?
> For Windows Home and Professional users, this is not the case. Disabling telemetry is not possible because Microsoft have decided that there is a minimum "required" amount of telemetry every OS installation must send in order to function.
Yes but AFAIK, winget telemetry fits entirely under the optional category. No metrics of winget fits under the "required" category that you cannot disable.
In other words, you can completly disable the telemetry of winget, which the title of this article say you cannot.
Elsewhere in this discussion, a Microsoft employee working on the new terminal was completely sure that the data it collected wasn't sent anywhere, until they looked into it again and discovered that it actually was being picked up by some part of the inscrutable telemetry machinery and sent off to Microsoft.
It's not quite so clear. The data collection policy linked in the comment (that can be controlled in settings) distinguishes between required and optional data collection. It's possible to disable optional data collection, but not required data collection.
Here's one of the elements that is required (and so it cannot be disabled):
Information about your device, its settings and capabilities, including applications and drivers installed on your device
The required telemetry is already gathered by windows 10 though. My point is to say that if you disable the optional telemtry in W10, then presumably winget doesn't collect anything.
So while I agree with you that the required telemetry is obtrusive, it's not new and it's not related to winget.
This project collects usage data and sends it to Microsoft to help improve our products and services
It's this type of broad data collection disclaimer that I find lacking in modern products. Usage data? It's not clear what that is, or what exactly is being recorded, and what is sent that is required, and what is sent that is optional.
This is an impossible problem. If they underdeclare, they invite a lawsuit. If they overdeclare, they get accused of malfeasance they aren't even doing.
If they open the whole business to transparency, they become victims of commerical espionage and expose their users' data to invasion.
How about just providing a link to an actual payload (with example data)? And within the installed application, providing the ability to review all the data that was recorded and set?
MS adheres to GDPR export/delete requirements. Failure to adhere risks litigation so it's not something that MS is just going to willy-nilly flaunt.
It's frustrating reading a lot of comments that are of the form "Why doesn't MS just do XYZ?" from individuals who don't seem to know that MS is already doing that.
The parent comment that I replied to was asking about transparency and I tried my best to answer.
> Why doesn't MS just stop forcibly collecting data from my machine?
Updates.
At the minimum data collection level for client SKU (set via user settings), MS asserts that only data needed to keep the machine running and secure is collected (i.e, updates). They really do try hard to honor this assert, although I understand I'm not going to be able to entirely eliminate skepticism.
You can argue that you should be allowed to disable telemetry for updates, but I think that's a different conversation. MS didn't want Windows reputation to suffer due to undeployed fixes (this was a big problem prior to win8), and they took a hard line on the updates.
Enterprise SKUs have a zero exhaust option (no telemetry), but alas, it's not free.
> MS asserts that only data needed to keep the machine running and secure is collected (i.e, updates)
I think this phrase is going to be a contentious point anyway. Microsoft doesn't need any telemetry to "keep the machine running" - as trivially evidenced by me pulling out the Ethernet plug, disconnecting the wireless adapter, and booting up Windows 10. The OS will run just fine. As for keeping it secure, it depends on how much you stretch the word "secure". I can't see any reason why telemetry would be needed to deliver updates (Windows could just download the list of available updates and request the ones it needs). You could argue telemetry is needed for malware detection and mitigation, but that can be stretched to justify everything up to and including uploading snapshots of your hard drive.
I'm guessing "needed to keep the machine secure" is how we've arrived at the rather absurd situation in which Windows Defender is automatically uploading executables it finds on the machine, to have them tested on Microsoft servers - which has been demonstrated to be a neat vector for exfiltrating data from secure corporate networks: the malware can just encode the data it collected into an executable and write it out to the file system, at which point it gets picked up by Defender and uploaded to Microsoft (which corporate firewall will most likely allow), where upon execution it connects to the attacker's server and delivers collected data.
Linux distributions manage to provide updates (and keep the machine running and secure) without telemetry. They were already doing this before Microsoft implemented automatic updates in Windows. (And, in fact, Windows had updates before it had telemetry.)
This is not entirely correct: for as long as MS has offered updates via the internet, the update service has required some information from the users machine. If we went back to 2003 with the same legal definitions and awareness that we have today, we could have called this information 'telemetry'. The legal definitions and public awareness of the data gathering has changed a lot since then, but the use of 'telemetry' (for lack of a better word) hasn't.
You'll have to forgive my ignorance about Linux because I haven't used it in a long time: I just fundamentally don't see how any update manager (be it chocolatey, nuget, windows, or linux etc) can efficiently update a client without knowing what's already on the client. If any installation information is sent from the client to an external entity, it may be considered 'telemetry' and subject to certain laws. Doesn't sudo send such information? (again, forgive my ignorance on the Linux implementation).
> I just fundamentally don't see how any update manager (be it chocolatey, nuget, windows, or linux etc) can efficiently update a client without knowing what's already on the client.
Pretty simple. Instead of sending information about what's on the machine to the update server, the client would download the list of available updates from the server, use that list to determine what updates it needs, and request those specific updates from the server.
That's e.g. how apt - the Debian family package manager - works. You `apt update` to update the local cache that lists available packages and their versions; then, you `apt upgrade` to download and install any or all packages that need updating.
The client downloads the list of packages from the update servers, compares the available versions to the installed versions and offers (if the user so chooses) to download and install the newer versions (or a subset). (And there is some additional logic around resolving conflicts, all on the client, using metadata downloaded from the servers.)
You might argue that this is not "efficiently", but it works great and in my personal experience a lot faster, more reliably and more predictably than Windows Update.
(As for sudo: No, unlike e.g. the .NET Core CLI and winget, system utilities don't normally contain extra unrelated functionality to silently collect user data and send it off somewhere. Perhaps one reason Microsoft don't hear more complaints about it from developers is that nobody imagines that you would do such a thing. It's normally not done.)
Yeah, to extend the thought about sudo - which, for clarity, is a command you use to execute something as a superuser on your system; it's not a package manager, but something you often prefix when interacting with one.
So sudo, depending on system configuration, does log interactions, but does it locally. The rationale behind this is that Linux heritage is one of multi-user systems, so you want to have the owner/sysadmin of that system to be able to audit the use of superuser privileges by regular users, in particular when they break something. In a Linux system installed on a desktop, or a server you admin yourself, the user is the only person who can access these logs anyway, so it's no different than any other system log.
That these logs would be automatically sent to third parties is unthinkable - in the sense that nobody would even think an operating system would dare send sensitive information out like that.
* 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.
You can't disable telemetry on Windows Home or Enterprise in any supported way. You can either hack through multiple registry and task manager entries or use a third-party program. I suggest Shutup10.
yeah. Looks to me like the issue lies more with the base telemetry data policy surrounding Windows 10 itself, which has been a point of contingency between Microsoft and users ever since Windows 10 released.
Even if winget allowed for disabling telemetry entirely, our OS is still collecting telemetry too, so it seems the point is pretty much moot, imo.
> diagnostic data collection (telemetry) is not enabled for private builds
> this data collection is covered by windows 10 privacy, You can find the windows 10 privacy statement and details of controlling the diagnostic and feedback settings here.
So if you build from source, you can disable it, and if you don't build from source but install it from the store, then telemetry is controlled by the central privacy settings in Windows 10.
Presumably this would be a problem only if you specifically don't want MS to have telemetry from winget, but you also specicifically want them to have telemetry on the rest of your OS, which would be... weird.