On Monday, 14 August 2017 14:49:18 CEST Bhushan Shah wrote: > On Mon, Aug 14, 2017 at 02:32:46PM +0200, Thomas Baumgart wrote: > > What does keeping the local data in encrypted form help here? The > > application (KUserFeedback function?) must be able to display the > > transferred data to the user upon his request, so it needs to decrypt it. > > The key material must be known on both ends (application and KDE server), > > so it can be treated as public since it must be delivered with the > > applications source code. That does not make sense to me. > > While you are true about the need to show decrypted data in the > KUserFeedback applications, it is also important to note that not all > the application/process running on user's computer is provided by the > KDE. > > For example, > > I as a user trust KDE community to provide the telemetry data but > might not trust the 3rd party developer whose (closed source) app I've > installed, and I don't want them to read AND/OR write to the telemetry > datastore without me knowing.
If that's the threat model, you have a far far bigger problem than access to the telemetry data. Those apps have full access to your data, your passwords, all your keyboard input (assuming X11), etc. > I know that is extra hassle and one more layer of indirection but this > ensures that only trusted application have read-write access to the > data. Also I am not sure if this is actually technically possible > without complicating things too much or not.. but it's something worth > investigating. I'd say it's not just a technical complication, it's conceptually impossible. Where would you store the encryption key if you have to assume local file system access of an untrusted process? I can only think of one safe place that's not either compromised or would violate the rules of the telemetry policy: the user's head. But I doubt we'd want to bother them with a password for the telemetry data. That aside, this would also conflict with the audit log proposed by Martin S earlier in this thread I think. > > Transporting the data in end-to-end encrypted form (TLS) to avoid MITM is > > a > > different story which I already mentioned. > > Yeah, I read your message above, it's just it was related to my point so > I repeated it here as well Transport security is so obvious I hadn't even thought about mentioning it in the policy :) It has been implemented from the start already. Regards, Volker
signature.asc
Description: This is a digitally signed message part.
