Telemetry Policy

[Volker Krause]

On Wednesday, 16 August 2017 11:31:31 CEST Mirko Boehm - KDE wrote:
> before this gets completely out of hand: The cited German data protection
> regulations are often misunderstood, even by people that pose as experts.
> They are also often (mis-)used as killer arguments to support political or
> personal opinions. If we start collecting telemetry data, we should get an
> assessment by a lawyer (!) that the way we handle the data is correct.

yep, let's bring this up on e.V. level once we have agreement on what we 
actually want to do in detail, there are still some very relevant questions 
for this open (such as the publication/licensing of the data).

> However, it can certainly be done correctly and in a way that protects
> individual privacy and supports the improvement of our software.
> 
> Technical argument: If IP addresses are a concern, would it be an option to
> run them through a one-way hash function on the client side before
> submitting the data?

It's not about IP addresses we submit (we shouldn't be doing that in the first 
place), but about the one the web server sees inevitably when receiving data. 
We can't avoid that, we just need to make sure this is kept separate from 
telemetry, to avoid being "tainted" as personal data.

Regards,
Volker


> On Wed, Aug 16, 2017 at 11:08 AM Volker Krause <vkrause at kde.org
> <mailto:vkrause at kde.org>> wrote:
> On Wednesday, 16 August 2017 10:21:11 CEST Ben Cooksley wrote:
> > On Mon, Aug 14, 2017 at 11:40 PM, Volker Krause <vkrause at kde.org 
<mailto:vkrause at kde.org>> wrote:
> > > I agree on the proposed wording changes, so focusing on your technical
> > > points below.
> > > 
> > > On Monday, 14 August 2017 11:53:17 CEST Ben Cooksley wrote:
> > >> I've got two technical notes here:
> > >> 
> > >> 1) All products should fetch details on where to submit telemetry data
> > >> from an online configuration file similar to
> > >> https://autoconfig.kde.org/ocs/providers.xml
> > >> <https://autoconfig.kde.org/ocs/providers.xml>
> > >> 
> > >> This would give us the capacity to version the telemetry server api,
> > >> and potentially even "kill" telemetry submissions from older
> > >> application versions if needed.
> > >> 
> > >> 2) No software product should use the QNetworkAccessManager family of
> > >> classes due to known defects in it's operation within some versions of
> > >> Qt which cause infrastructure problems.
> > > 
> > > The current implementation uses QNAM, but actually has code to handle
> > > HTTP
> > > redirects correctly (with unit test coverage), I assume that's the issue
> > > you are referring to? This also has been tested all the way back to
> > > Qt4.8
> > > as part of the existing deployment in GammaRay.
> > 
> > That's one of the considerations yes. I'm hopeful that nothing else in
> > it will be found to be broken behaviour wise but have much more faith
> > in KIO here.
> > 
> > > I don't mind adding the extra indirection with the configuration file,
> > > although just from the XML I don't see yet what that would provide
> > > beyond
> > > HTTP redirects. Are there certain information (e.g. the app version)
> > > passed already as part of the request for the configuration file? Or can
> > > there be conditional aspects not currently present in the above example?
> > 
> > The extra indirection is basically to give us the option to shift the
> > endpoint elsewhere at some point without having to keep the old one
> > alive even as a redirect.
> 
> Isn't that just shifting the requirement for the "stable" endpoint to the
> configuration one? But if that's easier we can of course add that. Are there
> any formats/standards you have in mind for this, or any parameters the GET
> request should contain?
> 
> > I'm also concerned that we could potentially run into issues if the
> > system doesn't do any GET requests. From what I recall unless the
> > server and client support a specific RFC then redirecting POST
> > requests isn't something one can rely on here (your code might handle
> > this properly, I certainly wouldn't trust QNAM to do so given their
> > stance on optional behaviour in HTTP RFCs)
> 
> Correct, QNAM doesn't support POST redirects itself. But since we deal with
> redirects ourselves anyway, that's not really an issue. On the server I
> haven't run into issues yet, even the super primitive HTTP test server built
> into PHP can handle it. POST redirects aren't particularly elegant though,
> as you are sending the payload multiple times. So the extra GET might be a
> better solution anyway.
> 
> Regards,
> Volker
> 
> 
> --
> Mirko Boehm | mirko at kde.org | KDE e.V.
> FSFE Fellowship Representative, FSFE Team Germany
> Qt Certified Specialist and Trainer
> Request a meeting: https://doodle.com/mirkoboehm

-------------- 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/20170816/7d0f8555/attachment.sig>