[userbinator]

No, crash reporting is easily done with logs, preferably in some format you could redact any sensitive information from. This seems more like the "I will secretly phone home and not tell you about it or what I'm sending" kind of thing.

These are GPU drivers. It's not at all unreasonable that there may be something sensitive shown on the screen when a crash occurs. It might not even be shown on the screen but still present in GPU memory:

https://news.ycombinator.com/item?id=10873059

I would not be surprised if the telemetry included some parts of GPU state which could contain sensitive data.

[KirinDave]

> No, crash reporting is easily done with logs, preferably in some format you could redact any sensitive information from. This seems more like the "I will secretly phone home and not tell you about it or what I'm sending" kind of thing.

It's not terribly secret, now was it? It was... you know... immediately discovered and I'm pretty sure my driver changelog AND firewall asked about it.

> These are GPU drivers. It's not at all unreasonable that there may be something sensitive shown on the screen when a crash occurs.

Pardon me, could you please explain exactly what in the telemetry or common crash logs might reflect "sensitive" information? You seem to me like you're arguing from some sort of grand final consequence, "Well I assume there is sensitive data here!" And while perhaps that's not an unreasonable default policy to take, you might want to state it as such rather than implying (as you have) that it's been observed already.

In general, telemetry doesn't include bulk memory dumps. The technology for collection strongly discourages this, as the endpoints collecting standard telemetry need to run at the scale of your customer base. I'd be much more concerned about sharing log dumps if you've filled your framebuffers with confidential information.

[shostack]

I think this is a case where we need to assume guilty until proven innocent.

You see, there's no way for users to know what data is being collected and sent today, or what they might change and decide to collect tomorrow.

What if government wants access to this data? What if some hacker gets access to the data or their methods of collecting it (MitM)?

As such, they need to prove we can trust them before we accept this at face value. They have not done so.

[KirinDave]

> As such, they need to prove we can trust them before we accept this at face value. They have not done so.

This is ultimately a trust relationship with your vendor. There is nothing they can do but be trustworthy.

Don't say, "open sourcing." Open sourcing code doesn't assert much of anything about the binaries you have running. sourceless propagating binary behavior is 30 year old technology.

[lukeschlather]

I'm playing a game, I alt-tab out, game crashes, and literally anything can end up in the framebuffer related to a crash.

[alkonaut]

So apps shouldn't send any dumps/buffers as part of crash reports. They are still useful.

Also: crash reports should be accepted individually and not part of "telemetry" (anonymous usage and hw/os stats).