<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 19 August 2017 at 11:39, 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-m_-3177828812119121719gmail-m_3772403200487882662gmail-">On Friday, 18 August 2017 11:23:49 CEST Jaroslaw Staniek wrote:<br>
> On 17 August 2017 at 16:19, Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > On Wednesday, 16 August 2017 20:35:59 CEST Jaroslaw Staniek wrote:<br>
> > > On 16 August 2017 at 18:56, Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > > > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote:<br>
> > > > > On 16 August 2017 at 14:13, Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
[...]<br>
</span><span class="gmail-m_-3177828812119121719gmail-m_3772403200487882662gmail-">> > > > - Kexi seems to (optionally?) contain a unique identifier<br>
> > ><br>
> > > This is mostly related to cases when any kind of cloud storage is used.<br>
> > > These cases involve unique accounts already so users can be identified<br>
> > > very well even without having telemetry functionality.<br>
> > ><br>
> > > KEXI installations limited to open-core, used away from a cloud, do not<br>
> > > need identifiers.<br>
> > > However I understand that identifiers, independent of network or host ID<br>
> > > (basically a random-generated QUuids) are useful for even basic<br>
> > > telemetry needs. Without them it's easy to abuse the system using any<br>
> > > kind of bots to trick us that e.g. 99% of sessions happen on KDE 1.0 or<br>
> > > that given Linux distro has 90% of the global market :)<br>
> ><br>
> > Vandalism is a potential problem indeed (did you actually have issues with<br>
> > that on Kexi btw? if so, what counter-measures did you apply?). However I<br>
> > don't see how a UUID is helping here, the bot could just as well generate<br>
> > UUIDs for each submission?<br>
><br>
> UIDs indeed can't help with too clever bots but e.g. semi-evil use cases<br>
> such as executing apps in batch mode can be catch. I've mostly encountered<br>
> logs coming from test machines including myself so I probably should not<br>
> have used the term 'bots' but (as unrealistic as it sounds) real bots can<br>
> be created.<br>
<br>
</span>Ok, so that's more an accident scenario then vandalism/abuse. Wouldn't the<br>
more targeted counter-measure be to just disable telemetry for the development<br>
team?<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">In KEXI, in an anti-corporate fashion, we don't distinguish development team from non-development team. All users are in the team by definition after agreeing to support telemetry. That's one of the motivators.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div class="gmail-m_-3177828812119121719gmail-m_3772403200487882662gmail-h5"><br>
> > > Similarly app projects may need the IDs to answer question about most<br>
> > > and least used features. Most used as in "most users found it,<br>
> > > understood it and use it", not "most usage reports has been delivered<br>
> > > for it (maybe coming from a single user -- maybe even my very own co-<br>
> > > developer). There are many other examples probably already discussed.<br>
> ><br>
> > Sure this gets easier with unique ids, but it's not impossible without<br>
> > them.<br>
> > After all the goal here isn't to make our lives easier, but to agree on<br>
> > something that is acceptable for our users. And yes, that might imply more<br>
> > work and/or less accurate data.<br>
><br>
> My assumption when started with telemetry was having adequate level of<br>
> precision. Assuming no logs are fabricated as fake interesting questions<br>
> are for example: how many users actually run supported software and how<br>
> many run outdated one? Not how many executions per given period of time<br>
> because it may be that old software is executed by a few users very<br>
> frequently for some reason. e.g. because 3 years old sofware crashes on old<br>
> OS every minute and restart was needed :)<br>
><br>
> How to know that without unique (anonymous) identification?<br>
> Using extra fields such as OS+Desktop type/version would be indeed a form<br>
> of cheap UID.<br>
> But I would say disclosing OS+Desktop type/version for that discloses more<br>
> than the anonymous random UID represents.<br>
> In bugzilla and mailing list we're asking for all this information too<br>
> anyway and (at least I) do not like supporting anonymous users since I am<br>
> not anonymous.<br>
<br>
</div></div>The implementation in KUserFeedback addresses this by fixed interval data<br>
submission. If you then aggregate the received data by the same interval, you<br>
can see e.g. how ratios of application versions develop over time.<br>
<br>
This does have limits of course, you can't distinguish between the same person<br>
using the application every sampling interval, or two people using it every<br>
other interval for example. With a sufficiently long sampling interval the<br>
result should nevertheless be sufficiently accurate I think.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Volker, thanks for sharing this. I don't see how this as an approximation. Do you probe in given time intervals and/or measure time spent with the application? How do you handle time zones (e.g. zero usage of version X that is used only in the USA for some reason)?<br><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">KEXI sends the feedback data on startup only. I have no idea if this is compatible with any other approach but this helps to ignore different usage patterns, e.g. these two basic and typical to KEXI and many apps:<br><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">- user starts the app and keeps it open for half of the day<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">- user frequently starts the app multiple times (for any reason) and has multiple instances open<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">If I remember correctly we're not measuring how long the app is used, this can be perceived as quite private information, by the way. Interesting data but so far not collected.<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Moreover based on my specific experience giving up the IDs softens the data any more complex than app version: Alice can use module M of the app primarily and Bob can use module N mostly. Without IDs we have a set of mixed probes that include usage of both modules in no particular order (maybe per locale or timezone or other factor but this is not worth guessing IMHO). We don't even know if there are module-based preferences among the users.<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">I know you're well aware of all that given how long you spent to work on the topic. I am not pushing for obligation of all app projects to offer IDs (and especially with opt-out) but disallowing it in some manifest would bring negative results and alienate someone (also stays away from *GPL as stated above). So realism is needed here.<br><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">I've not heard privacy concerns from KEXI's user base but heard concerns about us not knowing the user patterns enough. YMMV.<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">The key for me is to know users' expectations, so here I would learn what's their perception on privacy too. No generalization. Otherwise there are comic situations such as when I encounter a post from someone who generalizes and calls to take a very strict privacy policy in general and make it a KDE's differentiator, BUT the post is all signed "Sent from iPhone". Or freedom warriors that happen to use Facebook. Evangelists would better start from themselves and offer consulting to projects they know from the inside. <br><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default"></div></div><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-m_-3177828812119121719gmail-m_3772403200487882662gmail-"><br>
> BTW, it's worth to remind, the UID is not even a hash of any host and user<br>
> info, it's a random number. I do admit that "hash of a host and user info"<br>
> would be even better as it allows to recreate the UID after e.g. OS has<br>
> been reinstalled or new account created. But I do not use hashing for KEXI<br>
> anyway.<br>
><br>
> > > Thus I would see the Anonymity is covered by KEXI's approach except that<br>
> > > it offers opt-in tracking of unique user for unique installations. KEXI<br>
> > > currently does not track unique installations at all until the user<br>
> > > agrees for any telemetry (the KexiUserFeedbackAgent::<br>
> > > AnonymousIdentificationArea value). This is required by nature of stats<br>
> > > computed (and abuses mentioned above are the reason).<br>
> > ><br>
> > > Is this a big deal? We're close to philosophy area here.<br>
> ><br>
> > Correct, this is about the philosophy behind our products :) And one very<br>
> > core part of that happens to be privacy.<br>
> ><br>
> > That basically leaves the question: do we want to additionally allow the<br>
</span>> > opt-in use of unique identifiers?<br>
<span class="gmail-m_-3177828812119121719gmail-m_3772403200487882662gmail-">><br>
> I would say yes. For example I see no reasons to reject any (inter)network<br>
> software having a concept of accounts from KDE. Our Phabricator and forums<br>
> and bugzilla are example of that. Well, our very own Akademy registration<br>
> software especially if it's "our" code base. All of them operate with<br>
> unique IDs. Even more: some software disclose some user-visible strings<br>
> (e.g. user names on the forums).<br>
> I think the key is to require that the apps, no matter what type, precisely<br>
> and clearly ask users for the agreement. And do not scare them.<br>
<br>
</span>That's mixing two different things though. Communication application for<br>
example of course need to uniquely identify the communication partner. That<br>
doesn't mean though that we should use the identification for anything but the<br>
absolute necessary, or that we can arbitrarily leak it (we e.g. add transport<br>
encryption wherever possible against that).<br></blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The benefit of unique identification for telemetry is IMHO too small to<br>
warrant the impact on privacy (and subsequently PR) here.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Strictly speaking it's possible to separate the two uses of ID and present them to users as separate. Then hope Bob and Alice understand and appreciate the complexity. But I can only imagine how small group of users will agree to register to some KDE service like a forum or bug tracking and won't agree to share name of the OS *they* use and app's version.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">My principle here is the generally known "design for typical case".<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">I see we are discussing the "offer opt-in or prohibit offering it for the KDE software at all". Just because there can be abuses or very strong opinions from people that may be not even be our real users.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div></div><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-m_-3177828812119121719gmail-m_3772403200487882662gmail-"><br>
> > > Before designing the stats engine I guessed: not more than installing an<br>
> > > email app or buying a SIM card and starting to use them; they allow me<br>
> > > to send email or make a call using protocols that disclose quite a bit<br>
> > > about me.<br>
> ><br>
> > Sure, but that is also where we can differentiate. Just because other<br>
> > applications weren't designed with privacy in mind doesn't mean we should<br>
> > follow their example IMHO.<br>
><br>
> Well, "weren't designed with privacy in mind" sounds s bit strong. Each<br>
> application has desired *level* of privacy hopefully defined maybe at<br>
> design time. I can imagine a storage for KEXI that is using public GitHub<br>
> account and repos in exchange for being free-as-beer cloud solution.<br>
<br>
</span>Email and GSM weren't designed with privacy in mind, that's what I was<br>
referring to. That just wasn't a topic at the time. But if a widely used<br>
communication protocol isn't targeted by current surveillance legislation<br>
attempts, something is probably wrong with that protocol ;)<br>
<br>
This doesn't imply we can't do software that is meant to use public cloud<br>
services for example, it's the users choice to use that after all.<br>
<br>
But you can't look at all that as being equal, I'm happy to share much of the<br>
source code I write publicly and have it attributed to me, but I'm certainly<br>
not ok with sharing my communication or activity data in the same way.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">I am also against ideas to openly share raw telemetry data, I've heard about them in this or sibling threads for the first time. All telemetry I worked on was based on the trust for given organization and only the organization processes the raw data being very careful what results are published.<br></div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">PS1: Regarding our "<cite><b>control over their digital life<span>" </span></b><span>part of KDE </span></cite><i>vi</i>sion
There's a whole new digital generation much younger folks than both of
us. Their
"digital life" is just their "life" what is shocking for us old guys. I am afraid that the group has not much representation in KDE. <br><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">PS2: Trivial, if there is any voting planned (?) it's important how do we ask. It's already hard enough that mostly the old generation votes...<br><br></div>PS3:
Organizations that support IDs can have two nice things: offer the
users ability to review and remove telemetry data upon request. Hard to do that without IDs, right?<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Cheers,<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Jarek<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Volker<br>
<div class="gmail-m_-3177828812119121719gmail-m_3772403200487882662gmail-HOEnZb"><div class="gmail-m_-3177828812119121719gmail-m_3772403200487882662gmail-h5"><br>
> Example. Our KDE software runs on hardware that is not assuring privacy<br>
> (emits signals that someone can easily decipher). "The apps weren't<br>
> designed with privacy in mind because they should block non-open CPUs" --<br>
> someone with high-enough expectations would easily say. "But we don't care,<br>
> we still want to develop them and see them used" -- we say, that's not our<br>
> level.<br>
><br>
> For most of the folks email has confidentiality are the SIM is OK.<br>
><br>
> Thanks for the notes and for working on the stuff, Volker.<br>
><br>
> > Regards,<br>
> > Volker<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail-m_-3177828812119121719gmail-m_3772403200487882662gmail_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/jst<wbr>aniek</a></div>
</div></div>