[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Telemetry Policy
From: Mirko Boehm - KDE <mirko () kde ! org>
Date: 2017-08-16 9:31:31
Message-ID: 318460D2-BA66-41BD-A4FB-D7C39593EBD7 () kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
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. 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?
Best,
Mirko.
On Wed, Aug 16, 2017 at 11:08 AM Volker Krause <vkrause@kde.org =
<mailto:vkrause@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@kde.org =
<mailto:vkrause@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. =46rom 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@kde.org | KDE e.V.
FSFE Fellowship Representative, FSFE Team Germany
Qt Certified Specialist and Trainer
Request a meeting: https://doodle.com/mirkoboehm
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; -webkit-line-break: after-white-space;" class=""><div dir="ltr" \
class="">Hi, <div class=""><br class=""></div><div class="">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. However, it can certainly be done correctly and in a way that \
protects individual privacy and supports the improvement of our \
software. </div><div class=""><br class=""></div><div class="">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?<br class=""><br \
class="">Best,</div><div class=""><br class=""></div><div \
class="">Mirko.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" \
class="">On Wed, Aug 16, 2017 at 11:08 AM Volker Krause <<a \
href="mailto:vkrause@kde.org" class="">vkrause@kde.org</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, 16 August 2017 \
10:21:11 CEST Ben Cooksley wrote:<br class=""> > On Mon, Aug 14, 2017 at 11:40 PM, \
Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank" \
class="">vkrause@kde.org</a>> wrote:<br class=""> > > I agree on the \
proposed wording changes, so focusing on your technical<br class=""> > > points \
below.<br class=""> > ><br class="">
> > On Monday, 14 August 2017 11:53:17 CEST Ben Cooksley wrote:<br class="">
> >> I've got two technical notes here:<br class="">
> >><br class="">
> >> 1) All products should fetch details on where to submit telemetry \
data<br class=""> > >> from an online configuration file similar to<br \
class=""> > >> <a href="https://autoconfig.kde.org/ocs/providers.xml" \
rel="noreferrer" target="_blank" \
class="">https://autoconfig.kde.org/ocs/providers.xml</a><br class=""> > \
>><br class=""> > >> This would give us the capacity to version the \
telemetry server api,<br class=""> > >> and potentially even "kill" \
telemetry submissions from older<br class=""> > >> application versions if \
needed.<br class=""> > >><br class="">
> >> 2) No software product should use the QNetworkAccessManager family \
of<br class=""> > >> classes due to known defects in it's operation within \
some versions of<br class=""> > >> Qt which cause infrastructure \
problems.<br class=""> > ><br class="">
> > The current implementation uses QNAM, but actually has code to handle \
HTTP<br class=""> > > redirects correctly (with unit test coverage), I assume \
that's the issue<br class=""> > > you are referring to? This also has been \
tested all the way back to Qt4.8<br class=""> > > as part of the existing \
deployment in GammaRay.<br class=""> ><br class="">
> That's one of the considerations yes. I'm hopeful that nothing else in<br \
class=""> > it will be found to be broken behaviour wise but have much more \
faith<br class=""> > in KIO here.<br class="">
><br class="">
> > I don't mind adding the extra indirection with the configuration file,<br \
class=""> > > although just from the XML I don't see yet what that would \
provide beyond<br class=""> > > HTTP redirects. Are there certain information \
(e.g. the app version)<br class=""> > > passed already as part of the request \
for the configuration file? Or can<br class=""> > > there be conditional \
aspects not currently present in the above example?<br class=""> ><br class="">
> The extra indirection is basically to give us the option to shift the<br \
class=""> > endpoint elsewhere at some point without having to keep the old one<br \
class=""> > alive even as a redirect.<br class="">
<br class="">
Isn't that just shifting the requirement for the "stable" endpoint to the<br \
class=""> configuration one? But if that's easier we can of course add that. Are \
there<br class=""> any formats/standards you have in mind for this, or any parameters \
the GET<br class=""> request should contain?<br class="">
<br class="">
> I'm also concerned that we could potentially run into issues if the<br class="">
> system doesn't do any GET requests. From what I recall unless the<br class="">
> server and client support a specific RFC then redirecting POST<br class="">
> requests isn't something one can rely on here (your code might handle<br \
class=""> > this properly, I certainly wouldn't trust QNAM to do so given their<br \
class=""> > stance on optional behaviour in HTTP RFCs)<br class="">
<br class="">
Correct, QNAM doesn't support POST redirects itself. But since we deal with<br \
class=""> redirects ourselves anyway, that's not really an issue. On the server I<br \
class=""> haven't run into issues yet, even the super primitive HTTP test server \
built<br class=""> into PHP can handle it. POST redirects aren't particularly elegant \
though, as<br class=""> you are sending the payload multiple times. So the extra GET \
might be a better<br class=""> solution anyway.<br class="">
<br class="">
Regards,<br class="">
Volker</blockquote></div><br class=""><br class=""><div class="">
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; \
word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; \
text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; \
widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space;" class="">-- <br class=""></div><div style="orphans: auto; \
text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; \
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Mirko \
Boehm | <a href="mailto:mirko@kde.org" class="">mirko@kde.org</a> | KDE e.V.<br \
class="">FSFE Fellowship Representative, FSFE Team Germany<br class="">Qt Certified \
Specialist and Trainer<br class="">Request a meeting: <a \
href="https://doodle.com/mirkoboehm" class="">https://doodle.com/mirkoboehm</a><br \
class=""></div></div> </div>
<br class=""></body></html>
["signature.asc" (signature.asc)]
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlmUEPMACgkQYSSaITCTnKUYjACguoudSSvMGM3RA7SvQVHHFYLP
xBcAoJn77Aya7ksKbh9kDX+M4qod3NVR
=OYn5
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic