Linked by Thom Holwerda on Wed 5th Apr 2017 23:12 UTC
Windows

The Basic level gathers a limited set of information that is critical for understanding the device and its configuration including: basic device information, quality-related information, app compatibility, and Windows Store. When the level is set to Basic, it also includes the Security level information.

The Basic level helps to identify problems that can occur on a particular device hardware or software configuration. For example, it can help determine if crashes are more frequent on devices with a specific amount of memory or that are running a particular driver version. This helps Microsoft fix operating system or app problems.

Use this article to learn about diagnostic events, grouped by event area, and the fields within each event. A brief description is provided for each field. Every event generated includes common data, which collects device data.

The long, long, long list of data Microsoft gathers when Windows 10's data collection is set to 'basic'. Some... Light reading as the Windows 10 Creator's Update, which is now available, installs (you can also wait until 11 April to get it through Windows Update).

Thread beginning with comment 642836
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Too much data, but ...
by daedalus on Thu 6th Apr 2017 07:51 UTC in reply to "RE[2]: Too much data, but ..."
daedalus
Member since:
2011-01-14

When it comes to bug fixing data, their benefit is our benefit.

True. The problem is how to write monitoring software that only sends them information that is relevant to bugs. That would be very clever software indeed!

I don't see why that data couldn't be collected locally on your machine, and only sent to Microsoft when something happens worthy of a bug report. Then it can gather the information together, show you what it's sending, and let you click the "Submit" button yourself. Lots of software does that and it seems to work quite well.

Reply Parent Score: 3

RE[4]: Too much data, but ...
by Alfman on Thu 6th Apr 2017 10:19 in reply to "RE[3]: Too much data, but ..."
Alfman Member since:
2011-01-28

daedalus,

Anything that microsoft can collect on us, realistically should be considered accessible to the government as well considering what's happened in the past.

It's not far fetched that a group like the NSA would feel entitled to it on the basis that in their view even US citizens don't have a right to privacy when it comes to "metadata".

Reply Parent Score: 2

daedalus Member since:
2011-01-14

daedalus,

Anything that microsoft can collect on us, realistically should be considered accessible to the government as well considering what's happened in the past.

It's not far fetched that a group like the NSA would feel entitled to it on the basis that in their view even US citizens don't have a right to privacy when it comes to "metadata".


Indeed, which is why I suggested it should be gathered *locally* and only sent to Microsoft after you've reviewed it and are happy for that information to be released.

Reply Parent Score: 2

ahferroin7 Member since:
2015-10-30

Because not all bugs have a clear cut indication from the software itself that there is a bug. Performance issues are a classic example of this, but there are all kinds of bugs that don't involve the software crashing or otherwise thinking something went wrong, and even if it does crash, then it may not be a bug in that software (For example, the version of Cinnamon I'm using on my laptop will crash if running in software rendering mode when something else pokes at certain OpenGL functions in Mesa, which in turn brings down whatever app was trying to use the functions in the first place. The bug is solidly in Cinnamon, but the other app 'crashes' too).

WHile I may not agree with what MS is collecting, I do in general agree with the practice of collecting runtime telemetry from actual customer systems simply because what matters in terms of things like performance is not how well it works on your test systems, but how well it works on actual customer systems.

Reply Parent Score: 2

daedalus Member since:
2011-01-14

Yes, of course. That data could be collected locally though instead of being constantly transmitted to Microsoft. Then you're in control of what is and isn't sent. If there's a crash, or some sort of performance issue, you have the logs that you can submit if you like.

Reply Parent Score: 2

RE[5]: Too much data, but ...
by CowMan on Fri 7th Apr 2017 20:27 in reply to "RE[4]: Too much data, but ..."
CowMan Member since:
2006-09-26

This is what (theoretically) matters to developers, not users. To users, in aggregate, there is a potential for benefit over time for improved software perhaps, but only if they continue to use and upgrade the program over time. Is that worth the privacy, data use, and unintended consequences of telemetry?

That question is one for the user to answer (opt-in). It is arrogant to assume the desires of the developers should trump that of the expectations of the end user. Sure, developers own the code - but users own the program once in their hands, and the hardware it runs on.

From the users perspective, it would be better to have the option to temporarily enable enhanced logging, and to be able to edit or review those resultant logs before sending (double opt-in). That respects the user, while also allowing for users to diagnose their own issues if so capable (i.e., telemetry won't generally let you know if you have failing RAM or a bad hard drive).

I'm also not sure how many performance gains or bug fixes would need to be found to make it worth all the UI rejiggery and dumbification which have inevitably drawn from various types of telemetry data to justify their implementation. I can say it's a great many more than are delivered these days.

Reply Parent Score: 2