<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 August 2017 at 14:13, Volker Krause <span dir="ltr"><<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wednesday, 16 August 2017 09:33:02 CEST Valorie Zimmerman wrote:<br>
> Hi all, Mozilla has done a lot of work on telemetry, and we might be<br>
> able to use some of their findings. On this page:<br>
> <a href="https://wiki.mozilla.org/Firefox/Data_Collection" rel="noreferrer" target="_blank">https://wiki.mozilla.org/<wbr>Firefox/Data_Collection</a> they break down the<br>
> data they might possibly collect into four buckets - technical (such<br>
> as crashes), user interaction, web activity, and sensitive (personal<br>
> data).<br>
<br>
</span>without making it that explicit, we basically have the same four categories of<br>
data too, and explicitly exclude the use of category 3 and 4, ie user content/<br>
activity and personal data, only technical and interaction data are allowed to<br>
be used (category 1 and 2).<br>
<span class="gmail-"><br>
> This bit might be relevant to our discussion: "Categories 1 & 2<br>
> (Technical & Interaction data)<br>
> Pre-Release & Release: Data may default on, provided the data is<br>
> exclusively in these categories (it cannot be in any other category).<br>
> In Release, an opt-out must be available for most types of Technical<br>
> and Interaction data. "<br>
><br>
> I think the entire page might be enlightening to this discussion. I<br>
> believe our analysis of needs should be more fine-grained, and that<br>
> some parts of what we need can be "default on" especially for<br>
> pre-release testing. For releases, we can provide an opt-out.<br>
><br>
> Other more sensitive data will need to be opt-in. I think it's a<br>
> mistake to treat all the data we might want all in the same way.<br>
<br>
</span>This again brings up opt-out, which so far doesn't seem to have a chance for<br>
consensus. Can we defer this to when we have some more experience with the<br>
opt-in approach and how much participation we get with that? Or are people<br>
feeling this would too strongly limit what they are allowed to do in their<br>
applications?<br></blockquote><div><br></div><div><span style="font-family:monospace,monospace"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">In addition maybe distributors can ​</div>​<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​sometimes make the decision based on opinions from given subprojects. </div></span><span style="font-family:monospace,monospace">For example </span><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​the option would be pre-set to ON in KEXI's installer for Mac and Windows itself and for Linux AppImages, not in the source code.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Just saying, KEXI has not yet switched to the new framework :)</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Seeing yesterday's blog from the Krita team (<a href="https://akapust1n.github.io/
2017-08-15-sixth-blog-gsoc-2017/" rel="noreferrer" target="_blank">https://akapust1n.github.io/<br>
2017-08-15-sixth-blog-gsoc-<wbr>2017/</a>), I'd particularly be interested in their<br>
view on this.<br>
<br>
Regards,<br>
Volker<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Sun, Aug 13, 2017 at 3:18 AM, Christian Loosli<br>
><br>
> <<a href="mailto:christian.loosli@fuchsnet.ch">christian.loosli@fuchsnet.ch</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > thank you very much for this work, sounds great!<br>
> ><br>
> > Only point I have: maybe make sure that the opt-in / default settings are<br>
> > not only mandatory for application developers, but also for packagers /<br>
> > distributions.<br>
> ><br>
> > Some distributions have rather questionable views on privacy and by<br>
> > default<br>
> > sent information to third parties, so I would feel much more safe if they<br>
> > weren't allowed (in theory) to flick the switch in their package by<br>
> > default to "on" either.<br>
> ><br>
> > Kind regards,<br>
> ><br>
> > Christian<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>