It would seem the only route to privacy, in such a world, is to never interact with their servers at all; which means never receiving updates; which makes any OS into a lame-duck product vulnerable to all manner of exploits; which probably means you should just never touch a computer in the first place, "to be sure."
Requesting software packages from a server should not require them to keep logs or send uniquely identifiable info.
One thing that unique IDs are necessary for, is deduplication. Without a unique ID when talking to e.g. the update server, then their statistics (used to determine which updates should be e.g. CDN prioritized) will be heavily skewed in favor of anyone who has configured their system to poll the server more often.
(Yes, they can partially resolve this problem by looking at the request IPs—but, well, NAT. Sometimes even entire countries are behind a small set of IP addresses (https://en.wikipedia.org/wiki/Carrier-grade_NAT).
The ideal thing here would be for everyone to have a public IPv6 address, and then that address could be your "unique ID" without really uniquely identifying you or your device, but rather just uniquely identifying "a place to deliver updates to", like a mailing address uniquely identifies a place to deliver parcels to.
(This might not seem so relevant for updates, but a clearer example is in crashes. All OS vendors prioritize the issues in their issue-trackers by their prevalence among users, counted as the number of times a Crash Report has been [voluntarily] submitted that seems to be "about" that issue. Crash reports need to be deduplicated by installation to be useful for prioritization; a piece of software that happens to get into a super-edge-case crash loop and so crash a million times for one user, should not be prioritized over a piece of software that crashes once for a million users. Just the opposite, really.)
> hardware info
If we're talking about software updates, then this is part of the "inescapable metadata." Yes, the OS vendor can stuff each update full of all possible updates for all possible drivers released in the interrim—and that's a workable idea, if you're Linux. It's not workable in the Windows/macOS ecosystems, where "drivers" are third-party bloatware blobs that ship with their own GUI control panels et al. Such a monolithic update, covering all possible bloatware driver blobs, would be hundreds of GiB. It makes far more sense in Windows/macOS to just have the client retrieve the GPU/RAID/printer/camera/etc. drivers (and updates for said drivers) they need, as separate packages, from the server. And that separate retrieval essentially describes, piece by piece, your hardware profile.
> require them to keep logs
I never said it was (or should be) required; only that, if you're paranoid, you should have no reason to believe that they're not doing that, even without any client-side telemetry being pushed. A paranoid person would expect that even Linux distributions keep the access logs for their package servers (incl. gathering them from mirrors), and act accordingly.
The risk seems to be that people who don't understand the implications of not sharing basic telemetry, when faced with a box that says “share nothing”, “share essential“, and “share essential and optional” would choose “share nothing” every time, because it just _feels_ better, right? Why would I choose to share anything at all? But they might be angry or surprised when:
- The OS and apps can't tell if you're eligible for an update because they don't know if your hardware/drivers will run the new version, because you won't tell them what hardware/drivers you're running now.
- Updates that affect performance or stability just continue to affect performance and stability because there's no data about the impact of an update, apart from what's provided by angry customers in support channels.
- Bugs and application crashes are not addressed ever or in good time because they are either never known about or not captured in sufficient detail to reproduce.
So, sure, maybe it should be an option. But there are certainly many who overestimate the risk and underestimate the value of basic telemetry (like sharing system info) for them as a user.
Why do you need to give Microsoft a bunch of details about your hardware for this? Why can’t Microsoft publish info about which hardware/drivers are supported in the new update, and then your machine determines whether or not it’s compatible?
For diffed updates to work efficiently Windows first works out what hardware/software you have. Then it can either:
1. Send info about the system to an update server and let the server decide what updates it needs.
2. Download a big manifest of all available updates (as you describe) and calculate locally what updates it needs.
Either way, Windows then has to make a request for updates specific to the system, at which point you reveal info about your software and hardware that you were attempting to hide in (2) anyway.
For the semi-annual feature updates, the process is more like you describe where there's a compatibility check then a large download (~3-6GB) containing all new features, even if your system won't be able to make use of all of them.
[1] https://docs.microsoft.com/en-us/windows/deployment/update/p...
At the end of the day, it's my computer. Not theirs.
Regardless of how much it's "For my own good", that's not their decision to make.
It's my hardware, that I'm paying for. Ultimately, I need to have the final decision on what it does.
But I don't know that, “I own this computer and therefore understand what user defaults will make it most stable and usable for me” scales beyond the informed user to general users, if that's what you were suggesting.
“For your own good” preferences exist to try to make the default experience better for users who don't care enough to understand the tool they're using 10 hours a day. Is choosing defaults that seek to benefit most users really not a decision that software developers should be making?
Btw, what you're saying is 100% bullshit. There is an obvious trivial way of doing all what you suggested, properly & legitimately: paid software testers. Or, alternatively, actually pay users for telemetry (I love it when companies say "we value your feedback" you value it at $0 all right!)
The well-known quip of "search for an answer to your problem, find a forum post from ten years ago resolved with an 'I figured it out, thanks'" only happens when you're far outside the idiomatic usage of the system.
Sometimes it's necessary; sometimes long-chosen buisness constraints force down the bad arm of an X-Y problem. But that doesn't make it any more likely that anyone other than you (especially the software vendor's QA dept.) will ever independently encounter your problem.
I don't think “just hire QA” or “just pay for the telemetry” solves the issues of how you reliably deliver updates, bug fixes, and asses performance issues at the scale of a company like Microsoft, though. Even the best-funded QA department and millions spent incentivizing data sharing could struggle to achieve a fraction of the coverage that metrics baked into the OS achieves.
> Or, alternatively, actually pay users for telemetry
At a _minimum_, people should at least get free software updates based on findings from the metrics they share. By opting out I'm relying on others to provide that data instead, or for the company to spend more to get it from me or someone else like me, or for them to somehow improve the experience for me without knowing what my experience is.
I recognize that some feel very strongly that software should be possible to improve without any form of automated telemetry, though, and I respect the desire for an off switch and the continued drive for opt-out being the default.
- All of these are possible without telemetry.
- There is a deceptive button on install that does not work.
- Make it opt-in for submissive persons who want to please MSFT.
Users don't read. Anything that's opt-in will never be opted into, because users won't even look at what the dialog says. (See also: organ donation.)
Most of UX design isn't targeted at people with opinions; it's targeted at the 99% of users who want to never make any decisions at all, because they don't see the system they're interacting with as their responsibility to dictate the policy of. They treat even their own computer—at least in the software sense—as "somebody else's computer."
They're used to interacting with the literal "somebody else's computer" at work, and at informational kiosks; and with the non-literal "somebody else's computer" in the form of the game-console walled-gardens, and the cloud-managed IoT devices. So it's no surprise that they think that "somebody else's computer" rules apply to their PC, too.
I checked the box "no telemetry" on install, yet I still had to disable dozes of spyware "options" manually later. One of them was a keylogger! Microsoft is in the black hat business.
> telemetry can benefit product teams
Pure marketing. If product teams what to know about issues, how about setting up decent bug-trackers like everyone else?
Reporting issues is a convoluted, humiliating and mostly futile process.
Thanks for sharing the link. However, it doesn’t change my point of view about Windows telemetry.
As I read that page, I see a lot of BS justifying why the only way to improve the product is to have telemetry.
The reason why I call it BS is because they use phrases like “we hear your feedback to improve the product”... that’s lie. I work in UX, and I’ve been involved in user research many times. The data that you get from event logs is related to measuring adoption and engagement. You get better UX feedback from traditional research methods. Telemetry is good for fast market analysis, rather than UX... but that doesn’t sound good when you try to justify it to end users.
Take for example the design of the Office ribbon (there is an excellent video explaining the process). After analyzing the data from usage logs (this was in the pre-telemetry era), and doing interviews they concluded that the main issue was that many features were hard to find (is interesting to note that the conclusion came from user testing, not event logs). The solution: a UI showing all the operations (the ribbon). And because they found that paste was the most used action, they put a big paste button first (this came from event analysis).
After the success of the ribbon, MS adopted it in many Windows UIs (even if they don’t have the same issues as Office). So as you can see the main product design decisions had nothing to do with usage data analysis. The same applies to other big product design decisions (the back and forward with the Metro UI, Cortana... etc). The use of telemetry is marginal to many product design decisions, so there is no reason to force it to every user... other than doing market research.
It does provide insights you won't get from user testing and direct observation, though, as you point out with the usage logs that informed the ribbon design.
> The use of telemetry is marginal to many product design decisions, so there is no reason to force it to every user
If the benefits were purely limited to the design phase, I can see your point for many teams, particularly small ones with niche products where they're less likely to get enough data for it to have much meaning.
But telemetry also has increased value over user testing at different stages of the product lifecycle, like when analyzing what features or products to deprecate or replace.
It also helps for peripheral things like working out what languages localization and documentation efforts should be prioritized for. This year I was asked what five languages a product we make should be translated to. They wanted to start with locales that have the biggest impact and expand to more later. The team who approached me made a list based on support requests and another product in our sector. But our install data showed usage was completely different. We even had two locales that hadn't made the top-10 shortlist. Their guess about the second-most popular language after English was also wrong. By using telemetry we made sure work and funding was focussed where it helps the most users.
Telemetry can definitely be abused or underused, but being on the other side and doing data-driven design and development over the course of a product lifecycle has shown that it has real value.
But it's pretty simple to opt-out of non-essential telemetry because so many people complained about it in Windows 10:
https://www.windowscentral.com/how-view-and-manage-diagnosti...
I set telemetry to 'basic' which means I'm comfortable with essential system data being sent in return for my system gaining updates and security patches.
Microsoft does a better job than many about explaining what data it collects, why it collects it, and how to disable collection where possible across its products:
https://privacy.microsoft.com/en-US/
Last year it started explaining which telemetry in Windows 10 is required (system data for updates/security) and which is optional (usage data to shape product direction) in a way that's largely free from legalese:
https://support.microsoft.com/en-us/help/4468236/diagnostics...
There are definitely Windows users who are “being ignorant about this topic” but that's not true of everyone. For me it's a combination of understanding what is sent, why it's sent, and how to control what's sent. That info used to be a lot harder to find so I'd say things are improving.
Reflecting on my own risk profile, seeing first-hand how much telemetry can benefit product teams, and learning about how the Windows update process works at a global scale (the “essential” telemetry class informs partial/phased roll-outs) also helped temper my initial reaction against telemetry being included at all.