Telemetry Policy

[Volker Krause]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170814/15b463ef/attachment.sig>