RFC: draft of new privacy policy

[Adam Holt]

On Wed, Sep 2, 2015 at 4:22 PM, Pierre-Yves Chibon <pingou at pingoured.fr>
wrote:

> On Wed, Sep 02, 2015 at 12:36:48PM -0400, Máirín Duffy wrote:
> > On 09/02/2015 11:58 AM, Pierre-Yves Chibon wrote:
> > >""
> > >we may disclose personally identifiable information about you to third
> parties
> > >in limited circumstances, including:
> > >...
> > >- for research activities, including the production of statistical
> reports (such
> > >aggregated information is used to describe our services and is not used
> to
> > >contact the subjects of the report).
> > >""
> >
> > I think this is talking about stuff like the 'State of the Fedora' FPL
> > slides from conferences, those pie charts and stuff. But that kind of
> data
> > isn't personally identifiable so I wonder why that is there. It seems
> like
> > the research purposes bullet should be under another paragraph in the
> > sharing section that says "aggregate user data may be..." blah blah.
>
> Just to be clear, my concern wasn't about the stats aspects but about the
> 'third
> parties' in combination with stats.
> So kinda like using google analytics to get stats while in fact we're
> specifically avoiding all third party services that could provide us with
> more
> accurate info in favor of products/tools we can run ourselves and thus
> where
> there are no '3rd party' involved.


What procedures are being put in place so that EU residents (and hopefully
everyone) can contact Fedora or Red Hat to obtain/understand/verify/delete
their machine data, beyond obviously personal data?  When even a London HIV
clinic just lost control of highly protected medical information (
http://www.bbc.com/news/uk-england-london-34127740) what technical and
personnel safeguards are being put in place to prevent and audit leaks of
the spectrum of personal-to-impersonal data that will increasingly become
property of Red Hat?

What precautions are being taken to ensure "Anonymous" and "Non-Personal"
info is truly guaranteed to remain so, as advertised in the Privacy Policy,
whether or not there are future mergers/acquisitions/divestitures?  Similar
to Matt Miller's Aug 12th Flock State-of-Fedora statement that machine
UUID's should be rotated monthly (not naively linked to prior UUID's) if
there are concerns?  Are UUID's, geolocation, IP addresses all listed as
"Non-Personal" forever, or just until the next sysadmin / management
decides otherwise?

Mass leaks of ostensibly unimportant data can impact many
students/citizens/staff through diverse unintended consequences.  If we
believe in open architectures: how frequently will this data be updated
please, how many employees will generally have access to this data?  And
hence vulnerable to coercion from US/China/Russia/Israel/etc intelligence
agencies, perhaps to index a targetted list of non-updated Fedora systems
for their proxies' secondary attacks?  If the purpose is purely (as stated)
to gather usage statistics snapshots (private or public) as described, when
might source "census" data be fully deleted after the fact, including from
unstated (hence unaccountable, no matter how sincere) 3rd parties, and if
so how?

More Mysteriously: why was the entire paragraph "Our Commitment to Privacy"
removed from Aug 14, 2008's
https://fedoraproject.org/wiki/Legal:PrivacyPolicy, along with sentence "To
make this Statement easy to find, we have made it available on our homepage
and at every location where personally-identifiable information may be
requested" which until now had make such a commitment appear real?  Why
this silent de-emphasizing of privacy going forward?

More Neutrally: Paul Frields is on the right track when he says "Perhaps a
wiki page for privacy increasing customizations is called for, where we
could consolidate such settings or tweaks" and yet pushing this evolving
burden out into wiki wilderness swampland is the very definition of a
Unfunded Mandate.  Who will take the bull by the horns, before Fedora's
brand is permanently tarnished, when yet more antiprivacy "openwashing" we
can easily avoid? (openwashing == having an appearance of open transparency
for marketing purposes, while continuing proprietary/hidden practices)

More Optimistically: how can Fedora genuinely take the bull By The Horns,
and expand into education, human rights and civil society applications used
by social enterpreneurs in good conscience, in all kinds of countries
(repressive and non, and in-between) during this post-Snowden era --- yes
showcasing new use patterns --- but with broadly authentic, thoughtful and
tangible treatment of humanity/privacy is absolutely paramount ?  In
developing world edutech, here's a common response we all face, when
conventional firms cannot go beyond legalese lip-service to privacy, hence
we so badly need help (from communities like Fedora especially!) to
overcome the growing distrust:
http://hackeducation.com/2015/06/29/is-it-time-to-give-up-on-computers/

Disclaimer: I don't speak for One Laptop per Child, but I actively work
with OLPC community groups distributing Fedora on school servers and OLPC
laptops in many countries, to citizen groups who justifiably ask for clear
transparency even around incidental data flows (permacookies of all kinds,
intentional AND incidental).  Since heartless exploitation is so often the
norm today, online or off, where is the inner soul, in the face of cynics'
claim that privacy is now a luxury good, as obsolete as democracy?  Can we
instead kick off new understandings thanks to Matt Miller's legit and
intentional efforts, beyond sweetly-worded smallprint, adding boldy
forthright human-readable explanation/risks/summary as to where Fedora's de
facto default (purposeful, pray) dataveillance flows are headed over the
coming years?  *Would Be Far Better~*

(Forwarded separately to Harvard's http://dataprivacylab.org)

--
Unsung Heroes of OLPC, interviewed live @ http://unleashkids.org !

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/council-discuss/attachments/20150902/fbc918d9/attachment-0001.html>