Telemetry Policy
Bhushan Shah
bhush94 at gmail.com
Mon Aug 14 13:49:18 BST 2017
Hello Thomas,
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.
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.
> 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
Thanks
--
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170814/951debb3/attachment.sig>
More information about the kde-community
mailing list