[freeflight]

> I don't doubt that Windows collects and transmits telemetry data (hell, text editors do that nowadays), but if an analysis of that exists, it is not in this article.

Such an analysis does not exist because that traffic is encrypted. Which is also the reason why using Windows 10/11 is not fully compliant with EU privacy laws in places like Germany, as there is no telling what Windows is actually phoning home.

Officially Windows 10/11 can be used but only after jumping through a lot of hoops that involve turning off the telemtry and phoning home, but even then only with an "acceptable residual risk" [0]

The only reason this isn't a bigger topic is because there is no realistic alternative; Everything is tailored to MS, and MS spends absurd amounts of money and effort to prevent anything from changing that.

So the majority just goes with the "easiest" and most convenient solution, even when it might actullay be an "illegal" solution that enables a ton of industrial espionage.

[0] https://www.heise.de/news/Datenschutzkonferenz-Hohe-Huerden-...

[p-e-w]

> Such an analysis does not exist because that traffic is encrypted.

... by software that resides on the same system, with keys that are in memory on the same system.

I'm not saying it's trivial to decrypt the traffic, but it's certainly possible, and much, much harder reverse engineering is routinely being performed.

[freeflight]

Then go right ahead and do that, there will be a myriad of official government instutions, from all over the world, that would be very interested in your findings.

Or MS could simply share the keys with those government institutions there have been literally asking for it, to see wether Windows is actually sending home privacy relevant data.

But the matter of fact is it's a very real issue and still on-going problem.

Just because investing a lot of effort could shed some further light on it does not really change anything about that or the non-compliant behavior MS engages in.

Security only being as good as the effort lobbed at it to break it, is not really a novel or useful insight in this scenario.

[MikusR]

What addresses are connected: https://learn.microsoft.com/en-us/windows/privacy/manage-win...

What data is sent: https://learn.microsoft.com/en-us/windows/privacy/required-d...

The Diagnostic Data Viewer is a Windows app that lets you review the Windows diagnostic data your device is sending to Microsoft, grouping the info into simple categories based on how it's used by Microsoft. https://learn.microsoft.com/en-us/windows/privacy/diagnostic...

[pieter_mj]

Yes we know all that. What I want is a demonstration of live decryption of telemetry data traffic.

[gnomewascool]

> with keys that are in memory on the same system

I'm not sure that actually holds — the encryption keys are in memory, but the decryption keys don't necessarily have to be.

The pre-encrypted payloads definitely are in memory at some point; however snatching them probably involves larger-scale reverse-engineering.

[heinrich5991]

If they're using standard TLS, the actual data encryption is symmetric, so the encryption keys are the decryption keys and must be in memory during the encryption process.

[jborean93]

If it is TLS you can get the keys used in the session from lsass’ memory. I’ve even written a tool to do so in PowerShell https://gist.github.com/jborean93/6c1f1b3130f2675f1618da5663.... This will generate a log file that contains the keys needed for Wireshark to decrypt TLS traffic.

[pieter_mj]

My claim is it's not standard TLS or there's an additional layer (external encryption key) because an actual decryption of telemetry traffic has never been demonstrated.