[alkonaut]

Microsoft’s own telemetry solutions (AppInsights/LogAnalytics) seem perfectly capable of handing async/buffering/backoff etc.

I agree there should be a single place, at least in Windows to control Microsoft telemetry on a per app basis. It should be very easy to accomplish. On other platforms less so.

In a desktop product I do for work we had the dilemma of opt in/out and showing the query clearly and hiding it in settings. We ended up with the middle ground of showing it but having the checkbox checked (so uncheck to opt out). We were still worried this would leave too few opting in but it meant over 95% did.

For command line I’d be 100% happy with a note on first use describing that telemetry is enabled and how it is disabled. Leaving it disabled by default and requiring user action to enable is not realistic in such a situation.

[g-b-r]

A pre-enabled checkbox is invalid for obtaining gdpr consent

[alkonaut]

We are assuming here (incorrectly or not) that since no PII is transmitted or stored, the GDPR doesn’t come into play, and the consent is just asking for permission and not “gdpr consent”

Of course it’s impossible to actually transmit anything anywhere without including the source IP in the http header - a fact we are ignoring completely. But that’s similar to the topic of this discussion: Microsoft does exactly this under the same assumption, that non-PII data can be sent (even via http) without gdpr coming into play. Otherwise they couldn’t have it enabled by default. If there is a ruling that says otherwise then everyone will need to change.

It could also be that first party servers (Microsoft app talking to Microsoft servers) is acceptable and then everyone would route telemetry to their own servers.

[g-b-r]

I haven't checked how they handle it for VS Code, but you probably agreed to some term before using it, and they're probably relying on legitimate interest

My gdpr is quite rusty anyhow