Windows 10 Telemetry - Some questions, and how does it work?

First up I have to say that I don't mind Microsoft collecting telemetry data from my computer. They can take anything they want, within reason of course, and as often as they like, but I would like to know the following:

  • How often is telemetry data taken, depending on the different telemetry level setting?
  • Can we see examples of the datasets taken? It's nice to see everything listed in TechNet, but I'd like to see an example also.
  • What is the size datasize of the dataset taken?
  • If the FULL setting for telemetry is set (which all insiders have by default and can't change), it says Microsoft could run diagnostics on our computers, get registry data and even documents, if they are related to a crash/bug. How would we know this was happening? We should be able to at least know when this happened. Is this done via the telemetry client by a Microsoft Engineer?
  • Can we have a telemetry frontend GUI where we can at least see what data was sent, and when.

So, I've read through the TechNet article here which explains a lot but doesn't answer the questions above. Here's the bit on Full Level:

I've been doing some digging to try to work out what controls the telemetry client in Windows 10, and where any information might be stored on the computer. So far, I've not found too much, so was wondering if anyone else has done any analysis?

I've worked out that when you change the telemetry setting in the settings app, it invokes the telemetry.desktop.dll but I imagine that merely calls the telemetry client and I don't know anything about decompiling dlls to even find out what might be in there.

Where is the telemetry client in Windows 10? Does it run as a Service? There are a few services that could be the telemetry client, like those beginning with "Diagnostics" in their titles but I'm not convinced. Or is it simply an upgraded Windows Error Reporting Service being used?

Has anyone found out any more information regarding the telemetry client?

This thread isn't about stopping Microsoft taking telemetry, but to understand what's going on, and get answers to some questions about how it works.

 

Discussion Info


Last updated July 24, 2019 Views 4,077 Applies to:

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

Hello namesake!

Well, 'concern' is of course subjective. There's new insight into how the telemetry client works. We know not only is HTTPS involved, but SSL and certificate pinning when data is transferred. More interestingly to me, it's stated that the client uses Event Tracing, which makes it somewhat easier for me to detect ... hopefully.

There's a fair few nuggets for enterprise customers to chew over, but I'm guessing we're coming from a consumer aspect here. There's a typo i think in my information. The Retention section now suggests that a fair amount of data is retained longer than 30 days. Which makes sense in some respects as they do say they supply anonymised data to third parties and vendors. Would be hard to do that without keeping data longer than a month. Of course, they don't say what they do keep specifically.

Equally interesting to me, and somewhat expected I guess, is that if you run any virtual machines, they too will be sending telemetry back, including all the apps they have installed. They also make it clearer to what I already suspected, which is that pretty much every aspect to the use of an app is recorded too.

Not a biggie, and somewhat also unsurprising, the text now says that they can take crash dump files too from your computer via telemetry client.

The ability at enhanced level to take content that might include user sensitive information is now not in the documentation at all, but I'd be surprised if that means they don't do that anymore.

There's mention that data is taken at a "fractional sampling rate" which can be as low as 1%. I don't really know what that means. Suggests that telemetry likely targets only specific devices perhaps? Also, doesn't say what the average sampling rate is, only what the minimum could be.

 

Muchos gracias, now that I find just as interesting as a mere list of changes. Both are useful so let's just say I find your work is enhanced by it. I have some remarks about this and that, but for now I have to walk the dog, do other work, and slave, slave, slave away...Later more quite probably but no promises....

Founder of the STI Project

New telemetry blog post by me here http://reviewsofblah.blogspot.com/2016/07/windows-10-telemetry-documentation.html with excact details of changes but my blurb is here:

My Summary

The latest significant change in to this documentation in over a month sees an undeniable greater emphasis on how telemetry is not only of great benefit to Microsoft but also to customers and enterprises. As if to underline all that, we have a reminder of Microsoft Privacy Principles now positioned within the first few paragraphs of this documentation and an array of "Additional resources" at the very end of the documentation that points to various privacy pages for various windows components. It's clear to me that Microsoft must be getting feedback from enterprises that they see no value in the extra traffic from telemetry and that there are strong concerns over the privacy aspect of telemetry. The documentation now reminds us of the transparency, security, legality laws and minimisation of customer related content that Microsoft's privacy principles underpins in the use of telemetry, It is, however, somewhat amusing that the first principle of privacy that they list is "Control". Enterprises have that granular control to essentially turn off telemetry, but not us consumers.

Away from the reminders about privacy, we now have a decent amount of new content in the documentation to remind us about the concept of telemetry and what exactly telemetry is, and isn't. I'm not sure this really needed spelling out, but there must have been many who were baffled by this. In the documentation, Microsoft refers to 'Functional Data' as the types of things that people mistake for telemetry. They list weather location, wallpaper and desktop settings as examples, including bing searches, which anyone should be able to deduce isn't telemetry. It's good that they remind everyone though and thus it's helpful to have this clearly spelt out. However, knowing what isn't telemetry isn't my problem. Know exactly what telemetry they are taking, when, and seeing examples of it, is my problem.

Previously this documentation had a section all about the ways Microsoft uses telemetry, but that's all gone in this update, with some of that content being reused and reworded, and also reshaped to remind us that it's because of the telemetry that we all have a better Windows OS much quicker. The sections on driving higher app quality and improving end-user productivity add little new to the debate but are useful real-world reminders of how telemetry is used by microsoft.

Sadly, they do say several times that telemetry gives users a voice but I disagree with that. There's no implicit voice in the telemetry data, of which data can always be misinterpreted. The true indicator that Microsoft should be using as a voice of the customers is via the feedback app. Telemetry is supplementary data in terms of a user's voice. Sure, this data is vital and necessary for understanding the operational and functional operations of windows but it shouldn't be used in any way as representing our voice.

Hi Stephen,

Thank you for all that, I certainly find that interesting and I completely agree with your closing remark that is utter nonsense spouted by MS that it is in any way a user's voice. That's just spin, nothing else, how can it be when I have no control and/or insight into what and when telemetry is being collected. Like you, I see the need and have no fundamental objection to it. What so irks me is that it all happens behind my back. But alas, there are too few who think that way and when mentioned to others, all I get is shoulder shrugs. Oh well, I am quickly becoming too old for this world, that much is clear.

Keep up the good work!

Founder of the STI Project

Recently came across an article from February about the telemetry client by Ed Bott. This guy had also been through the documentation, talked to Microsoft and done some investigations. See http://www.zdnet.com/article/windows-10-telemetry-secrets/

Key bits from his article that helped confirm a few matters for me are:

  • The telemetry client service name is called DiagTrack (Display Name = Connected User Experiences and Telemetry), so assumingly one could just turn this service off to stop telemetry? I'd found many services with the words telemetry and diagnostics in the name but was never sure which was the right one. Now, I know.
  • The telemetry client process name is utcsvc. So if you want to monitor what goes on, this is the process to follow.
  • The telemetry client stores its data in folders under C:\ProgramData\Microsoft\Diagnosis which I had figured out by watching processes but this confirms it.
  • Data sent by the telemetry client is claimed by Microsoft to be about 1.2k in size.
  • On a PC running at the basic telemetry level, tests by Ed Bott suggest that data transmissions occurred 32 times in an eight hour period.

Also, a recent update to the documentation I've blogged about here http://reviewsofblah.blogspot.com/2016/07/windows-10-telemetry-documentation_27.html

My Summary

Only one change in this latest update and it's the inclusion of a new section entitled "Insights into your organisation".

This is obviously more ammunition to convince organizations to leave telemetry turned on but not looking just at the knock-on benefits for organisations, by way of telemetry improving Windows. Now, it's about how that telemetry data comes straight back to the organisations by way of analytics. It's undoubtedly a tempting prospect, especially if the organization has no current data inventory technology in place, such as SCCM. I'm sure Microsoft will make the data look nice and useful but how much value it'll add if you have SCCM I'm not sure, or if it's enough to warrant turning on telemetry.

It might just be the start of some extra analytics that'll convince organizations to think seriously about telemetry as I'm sure there's much more to come in this area of bringing telemetry back to the organisations. Will it lead to a Telemetry Client Dashboard? If so, it might just get closer to delivering what I think Microsoft should have delivered in first place, which is a way to monitor and control closely what the telemetry client is up to on each PC.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.