Telemetry Policy

[Thomas Baumgart]

Hi,

On Montag, 14. August 2017 17:46:12 CEST Bhushan Shah wrote:

> Hello Volker,
> 
> First of all thanks for working on this topic, I've some comments I
> would like to add.
> 
> On Sun, Aug 13, 2017 at 11:47:28AM +0200, Volker Krause wrote:
> > ## Control
> > 
> > We give the user full control over what data they want to share with KDE.
> > In particular:
> > - application telemetry is always opt-in, that is off by default
> > - application telemetry settings can be changed at any time, and are
> > provided as prominent in the application interface as other application
> > settings - applications honor system-wide telemetry settings where they
> > exist (global "kill switch")
> > - we provide detailed documentation about how to control the application
> > telemetry system
> 
> This is kind of technical point but here it goes,
> 
> I think we should include the point in policy that, this data is stored
> and transferred in encrypted format only, on both user's machine and the
> KDE's server. This prevents Man in middle attacks and also prevents
> unwanted/unauthorized access to user's data by third party application
> on local machine.
> 
> So how I think this should happen is,
> 
> -> Application starts
> -> Writes encrypted data to storage file
> -> Encrypted data is transferred to KDE server
> -> They are decrypted on KDE server when needed

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.

Why would we need to encipher something and protect it, when we tell the user 
providing the data is transparent and does not contain non-anonymized values?

Transporting the data in end-to-end encrypted form (TLS) to avoid MITM is a 
different story which I already mentioned.

> > We will provide a designated contact point for users who have concerns
> > about the data they have shared with KDE. While we are willing to delete
> > data a user no longer wants to have shared, it should be understood that
> > the below rules are designed to make identification of data of a specific
> > user impossible, and thus a deletion request impractical.
> 
> Can we have policy on how long we can store data? It's just random idea
> but I think it makes sense to tell users that after X period of time
> your data will be invalidated?
> 
> This gives the "part-solution" to problem where user wants to delete
> their shared data.
> 
> > ## Compliance
> > 
> > KDE only releases products capable of acquiring telemetry data if
> > compliance with these rules has been established by a public review on
> > [kde-core-devel| kde-community]@kde.org from at least two reviewers. The
> > review has to be repeated for every release if changes have been made to
> > how/what data is collected.
> 
> In addition to kde-community/kde-core-devel there should be public
> webpage at e.g. https://telemetry.kde.org where we explain what
> application collects what data and where it is used for clear
> transperancy.
> 
> I think that's all points I wanted to add.
> 
> Thanks

-- 

Regards

Thomas Baumgart

https://www.telegram.org/       Telegram, the better WhatsApp
-------------------------------------------------------------
Progress isn't made by early risers. It's made by lazy men
trying to find easier ways to do something. -- Robert Heinlein
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 846 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170814/62aadec6/attachment.sig>