
<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>