3 ms·
I understand abstaining from a platform on principle. But it's pretty simple to opt-out of non-essential telemetry because so many people complained about it i
by modernerd 6y ago
I understand abstaining from a platform on principle.
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-diagnostic-data-windows-10-april-2018-update 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/ 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-feedback-and-privacy-in-windows-10-microsoft-privacy 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.
- SahAssar 6y agoThere is no such thing as essential telemetry. There should be an option to turn it off completely.
- modernerd 6y agoLet's say Microsoft adds one. You tick it and what MS currently considers “essential telemetry” is turned off completely, instantly, and for real. 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.
- anikk 6y agoCould you stop the MSFT advertisements? - 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.
- derefr 6y ago> 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.
- Spivak 6y agoThe shorter version is that opt-out exists so the people that care don't get angry. If the percent of people who opt-out becomes non-negligible it will cease to be opt-out.
- slipheen 6y agoI get where you're coming from, but I think it's indicative of exactly what I don't like about Microsoft's attitude, and part of why I don't use their software. 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.
- modernerd 6y ago
- derefr 6y agoThere's unavoidable telemetry. I.e., there's metadata about your interactions with Microsoft's servers that Microsoft inescapably derives from those interactions. You can certainly ask them to throw that metadata away; but—if you're paranoid enough to be worried what they'll do with it in the first place—then why are you trusting them at their word? 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."
- SahAssar 6y agoSure, but none of that requires there to be unique IDs or hardware info sent to their servers. Let's not pretend that Microsoft enabled us to make that choice for ourselves. Requesting software packages from a server should not require them to keep logs or send uniquely identifiable info.
- derefr 6y ago> unique IDs 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 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.
- anikk 6y agoIt is not at all simple to "opt-out" (i.e. remove malicious software). 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.
- diegof79 6y ago> https://support.microsoft.com/en-us/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy https://support.microsoft.com/en-us/help/4468236/diagnostics... 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.
- modernerd 6y agoSure, telemetry won't inform every product decision and user testing is still valuable. 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.