At some point we have to accept that this data actually helps them fix real issues too, they're not monetizing their players directly with it.
It is strange that this community of all communities has such a resistance to this idea. Software developers should know better than anyone how difficult it is to identify and fix vague software problems without having specific details about the problem. Yes, there is a negotiation between the value of telemetry and privacy and often too much privacy is sacrificed. But I am always surprised to hear developers say all telemetry is bad.
As long as it is anonymous, it's a good thing, IMO.
As long as users give informed consent, then it's acceptable.
Transparency is key here. If projects explained the steps taken to anonymize the data (either provably using Differential Privacy, or approximated via some other means), I feel like people might trust them more. Even with DP, though, the server does see IP addresses, even if it doesn't know what the telemetry is, and that alone might cross the line for some people. Even if the project promises to not log them.
Can you give 1(one) example of a program which was improved by using telemetry ? And no, trashing the UI in the name of change or modernism does not count.
Thank you.
This sounds more like 'MS bad, must hate MS at all costs' then actual legitimate complaints.
- We found out by looking at the distribution of software version that we had a strong holdout on one specific revision. It turns out we had a regression in a niche feature which was very important to a sub-community of our users, and users were basically telling each other to just use that old version. No bug report was filed until we found out via analytics and asked.
- We have a "game quirks" mechanism where the emulator reports weird edge cases that happen very rarely. Current list: https://github.com/dolphin-emu/dolphin/blob/master/Source/Co..., example usage: https://github.com/dolphin-emu/dolphin/blob/ffdc8538a162b1ca... . We used this to find games that use currently unimplemented or stubbed features.
- The list of popular games being played on the emulator was extremely surprising because it turns out there's a huge disconnect in what most NA/EU players are playing and what JP players are playing. This led to us adding a bunch of new games to the list we regularly test for performance and stability regressions. Would you have guessed that Inazuma Eleven GO: Strikers 2013 is in the top10 of emulated games on Dolphin?
https://github.com/dolphin-emu/dolphin/blob/master/Source/Co... is the actual code which collects most of the information. We do multiple things to avoid being able to track user activity too much -- for example, while every instance of Dolphin has a unique ID so we can do things like unique counts, events that happen within a play session are associated to truncated_hash(unique ID + game ID) and not directly with the unique ID. This means that we can only correlate events from the same user playing the same game, but not* two events from one user playing different games.
* Our implementation is a bit weak given that the set of all gameids is small and enumerable. We could probably do better there.
I’m talking extremely basic things, like, what are the most popular crashes in the app? Which did I introduce in the most recent version? Why is there an increase in end to end latency in fetching data from the server? Stuff that would fall under “bug fixes and improvements” that you would likely not notice.
The last example sounds detailed enough. And some privacy considerations are moot when the app is a client for your server.
As a dev, telemetry makes me nervous because so many projects rely on it too heavily and make bad design decisions because the telemetry blinds them.
- Have a screen that shows all telemetry that is going to be or has been sent
- Ask for permission to send any telemetry, or certain types of telemetry (i.e. crash reports)
– Publicly share the collected telemetry.
(i.e. if you observe telemetry data being abused at the company you work for and that is tolerated, you'll be wary of any telemetry?)
And we are a very abused culture sitting in the middle of what I hope is peak surveillance capitalism.
Beat someone with a stick enough, and when you go to scratch your back and they flinch, it's not sensible to deride them for being irrational.
Gaming is a weird point though, telemetrics are already in heavy use, the privacy risk is indeed minimal, and gamers don't seem to care anyway though. I can't tell you how many GDC talks I've watched that discussed player heatmaps, incident (like death) reports, and whatnot used to fine-tune game balance.
There are numerous places where telemetry is completely inappropriate, like one's operating system. An idle computer should indeed be 100% idle, internal housekeeping exempted. (I recently installed freebsd on a new server, did some setup, and basked in the glory of htop showing 32 cores at 0.0% and a root process list that was under a page long. I wish other operating systems could follow that example)
It always makes me happy to see how short the list returned from `ps aux` is with FreeBSD. Whereas if you go onto a typical Linux box (even just a raspberry pi!) and run that, you get at least a screenful of processes doing who knows what. (Just my small experience.)
It depends on which processes. If you include kernel threads (which show as processes), the number of processes can get pretty huge, especially on many-core servers (several of these kernel threads are per-core).
I don't know whether on FreeBSD kernel threads show up as separate processes; if they don't, it might explain part of the difference.
$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 3.5 0.0 8944 332 ? Ssl 11:38 0:00 /init
root 7 0.0 0.0 8944 228 tty1 Ss 11:38 0:00 /init
dando 8 1.7 0.0 16804 3396 tty1 S 11:38 0:00 -bash
dando 32 0.0 0.0 17392 1916 tty1 R 11:38 0:00 ps aux
1. Telemetry is unethical if the users didn't provide informed consent (opt-in) for it. It's not just a theoretical point - anyone who's worked in tech sector for a while should know most companies cannot be trusted to behave ethically (especially if they took VC funding).
2. There's a certain dysfunction/antipattern that's popular in tech sector, called being a "data-driven company". It's the practice of making decisions through divination from data collected through extensive telemetry, to the exclusion of other knowledge sources (like e.g. actually talking to your users, hallway testing, or thinking things through). This leads to software being optimized in questionable directions - so in a sense, you could say that adding telemetry implies an increased chance the software will become worse over time.
Doing such a study would be the first step in optimizing for a good emotional state. But it (quite understandably) led to an outcry which stopped it dead in its tracks.
https://www.nytimes.com/2014/06/30/technology/facebook-tinke...
And if the only way to opt out is not use the product. Or stop using it particularly.
This is sarcasm. Right?
I don't think many people here have any resistance to this. It's simply true. I think a lot of people, though, think that benefit isn't sufficient to overcome the drawbacks.
On the other hand, if it wasn't Microsoft's brand being connected to this and it wasn't called telemetry but "Automatic Bug Report Sharing" nobody would make a peep.
The same goes for the kind of data or application: if people know what type of data would be shared and what it would look like, they might indeed understand that this isn't some nefarious profiling but just normal software improvement. If you are a developer, bug reports are nearly useless unless it's super repeatable with normal conditions and a few clearly defined steps... or if there is a useful automatic reporting system in place.
But none of that reduces someone's expectation of privacy or acceptance of data sharing.
How do you know? Did they pinkie swear on it? Did they add any kind of T&C around their use of Telemetry specifically?
Telemetry that can be used to identify frequently used game functionality could equally be used to identify game functionality that can be monetized. Identifying how a user dies is a fantastic way to identify items which can be sold to prevent those common deaths.
Just as commonly, it is done to identify bugs and issues, tweak the game balance to get it to a better state, or to see which things players like to do (as opposed to what they say on forums and in focus groups) in order to provide more of similar features.
It is no different from engagement logging in a lot of applications. It is far from always being done for the purpose of monetization. If my business application has a lot of users stuck on a particular screen for prolonged periods of time due to the UX being confusing, I would want to know about it and address it. A lot of times it is hard to gauge how bad it is, because users might just tolerate it if it is ok, or maybe it is something users attribute to their own fault (i.e., they might feel it is just them being confused about it, not that the UX is confusing for everyone). Engagement logging would help me identify that problem and pinpoint it very fast.
>How do you know [they are not using it for monetizing]?
How do you know they are? I am more surprised they didn't have that type of telemetry already for a while, because that's one of the most common ways to identify pain-points in the gameplay balancing, which features might need more attention/rework, identifying potentially very tricky to catch bugs, and come up with ideas for new feature ideas that users might like based on actual data (as opposed to hearsay and public feedback, which can get significantly skewed by selection bias and other factors).
It can be a good thing, yes. Why on earth would anyone assume it would be used and only used in positive, privacy respecting ways in this day and age?
If you are judging based on Windows as a benchmark, almost all software is going to come in as acceptable.
It's not that I blame those who distrust any form of telemetry. Many companies are eager to harvest as much personal information as possible. Depending upon one's definition of personal information, some of the data acquired by telemetry can be used for that purpose. In many cases the data collection process is deliberately opaque. In the remaining cases, very few people have the ability to verify that what is actually sent reflects what they are told is sent. That's before factoring in Microsoft's involvement here, since they have a negative reputation in some circles due to their past business practices.
But seriously though, it's not on the same level as, say -visual studio code sending back telemetry which includes potentially secret code or anything. Or Defenders willy-nilly sending "samples" back to the mothership for analysis.
I sincerely don't mind it if a game sends this info back, I think it's actually a good use of Telemetry.
What do we know about that?
Microsoft have long lost the benefit of doubt with their shady data collection practices.
But then Minecraft is a video game. Why do they need to spy on their customers?
I mean, world building is an expensive but actually pretty simple, predictable operation. If they want to see how it performs on slower computer they don't need to get telemetry, just actually run it on slower hardware.