Telemetry Policy
Volker Krause
vkrause at kde.org
Sat Aug 19 11:02:03 BST 2017
On Saturday, 19 August 2017 05:37:58 CEST Nicolás Alvarez wrote:
> Enviado desde mi iPhone
> >> El 16 ago 2017, a las 20:46, Thomas Pfeiffer <thomas.pfeiffer at kde.org>
> >> escribió:
> >>
> >> On Mittwoch, 16. August 2017 09:33:02 CEST Valorie Zimmerman wrote:
> >> Hi all, Mozilla has done a lot of work on telemetry, and we might be
> >> able to use some of their findings. On this page:
> >> https://wiki.mozilla.org/Firefox/Data_Collection they break down the
> >> data they might possibly collect into four buckets - technical (such
> >> as crashes), user interaction, web activity, and sensitive (personal
> >> data).
> >>
> >> This bit might be relevant to our discussion: "Categories 1 & 2
> >> (Technical & Interaction data)
> >> Pre-Release & Release: Data may default on, provided the data is
> >> exclusively in these categories (it cannot be in any other category).
> >> In Release, an opt-out must be available for most types of Technical
> >> and Interaction data. "
> >>
> >> I think the entire page might be enlightening to this discussion. I
> >> believe our analysis of needs should be more fine-grained, and that
> >> some parts of what we need can be "default on" especially for
> >> pre-release testing. For releases, we can provide an opt-out.
> >
> > Hi Valorie,
> > Even if opt-out for some data is legally and even morally fine, it does
> > not
> > align with the values we communicate to our users:
> > Unlike Mozilla's Mission, our Vision mentions privacy explicitly, and
> > we're
> > striving to make privacy our USP.
> >
> > Therefore I agree with others who replied in this thread: We should
> > respect
> > privacy unnecessarily much rather than too little.
> >
> > In the end, of course, it's a matter of how we present this opt-in. If
> > it's an option buried in some settings dialog, we might as well not do it
> > at all.
> >
> > If we, however - like Firefox does -, pfominently present that choice to
> > users the first time they run one of our applications or desktop
> > environment and try to make clear why that data collection is important
> > for us, I don't see why we could not convince a relevant number of users
> > to opt in.
> > Sure, we'll get less data than with an opt-out scheme, but let's try it
> > out
> > first before we go for the option that carries a significant PR risk.
>
> I think discussing this as "opt-in" vs "opt-out" may be misleading. In
> terms of amount of data collected, there would be a big difference
> between going to Preferences and ticking a checkbox hidden somewhere,
> and a first-run pop up that asks you, yet both could be reasonably
> called "opt-in".
>
> Similarly, in terms of privacy, there is a big difference between
> opt-out by un-ticking a checkbox hidden somewhere vs opt-out via a
> passive banner that says "we collect anonymous usage information,
> click here if you don't want that" before any data is sent.
>
> In slightly different words, as said in #kde-devel:
> <argonel> opt-in doesn't mean "unadvertised"
> <nicolas17> and opt-out doesn't mean you have to dig in settings
> to turn it off
> <nicolas17> so I think putting it as an opt-in vs opt-out binary
> discussion is too simplistic
>
> We need to talk about the specifics of what opt-in or opt-out *means*.
> Is there a first-use prompt? Is it a passive banner or a modal popup?
> What happens by default if I ignore it? What happens by default
> between starting the app and answering the prompt? How do I change the
> choice later?
Good point, I clarified the intended meaning of "opt-in" in the wiki, that is:
off by default and only activated by explicit action of the user (inaction is
not good enough).
The "advertisement" or "encouragement" (as it's called in KUserFeedback) isn't
regulated in the current policy draft beyond obvious things like the setting
to turn telemetry off again can't be arbitrarily hidden, and you can't force
opt-in by tying the setting to unrelated features for example.
The current implementation in KUserFeedback is showing a passive popup after a
bit of usage, a blocking first start dialog asking for your data would give
the wrong impression on priorities IMHO. But that can depend on how an
application is structured in general of course, and I'd assume PR self-
preservation to prevent overly aggressive approaches.
Regards,
Volker
-------------- 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/20170819/0503a14b/attachment.sig>
More information about the kde-community
mailing list