From Mageia wiki
Jump to: navigation, search
m (MUST)
m (WILL NOT, NEVER)
Line 62: Line 62:
  
 
=== WILL NOT, NEVER ===
 
=== WILL NOT, NEVER ===
*  
+
*
  
----
 
 
== Proposals ==
 
== Proposals ==
 
It's not a black or white world. To improve our understanding of users and usages, we could need to use some info usually delivered transparently by users. So we need to list any type of user data we may be using at some level, to explain what we would use, why, or why not, and in what scope. Goal is to be explicit.
 
It's not a black or white world. To improve our understanding of users and usages, we could need to use some info usually delivered transparently by users. So we need to list any type of user data we may be using at some level, to explain what we would use, why, or why not, and in what scope. Goal is to be explicit.

Revision as of 19:28, 2 November 2011

Privacy policy (draft)

See Policies.

These are draft notes, to be improved and discussed.

Current situation

As of July 29th 2011.

  • www.mageia.org uses:
    • Google Analytics to track anonymous traffic data
    • a Facebook widget
    • a Google +1 button
    • a Twitter button
  • blog.mageia.org uses:
    • Google Analytics to track anonymous traffic data
    • wordpress.com to track anonymous blog traffic data
    • akismet to detect/filter spam comments
  • wiki.mageia.org uses:
    • Google Analytics to track anonymous traffic data
  • mageia.org mailing-lists use mailman and publishes public archives of mailing-lists
  • forum, wiki, bugzilla, subversion and other code repositories track and publishes users commits/comments
  • LDAP users directory stores all user accounts (username, public name, email, (encrypted) password, other data) for: association members management, community members management, non-commercial email notifications, and authentication purposes through all Mageia services
  • most (if not all) web services keep access logs, that include: IP address, browser user-agent (and potentially any request header your user agent send to our servers); these logs retention policy is not set yet (but likely to fit French law requirements) and are not to be used for anything else than local service stats and audit.

In project:

  • a dashboard may gather and cross some of this data to build: group/team pages, user pages, and on each, link to related docs through mageia.org resources (all packages/bugs relative to someone, or a team/group for instance) (see https://bugs.mageia.org/show_bug.cgi?id=1045)
  • a contributors' map may publish users location (opt-in only) (see https://bugs.mageia.org/show_bug.cgi?id=998)
  • a service to aggregate logs (web, mirrors, bugzilla, buildsystem, code repositories) and provide the possibility to visualize/extract useful patterns/info from it

This is subject to change/improve, one way or the other.

Regarding Google Analytics:

All aggregated, anonymous, non-personally-identifying data are meant to be released within a metrics publishing/understanding system.

General principles

Orientations for the privacy policy for the project. Valid for web site, distribution/software, community tools.

MUST

  • be highly careful about users account, data
  • users can register, edit and remove their account at any time (with proper consideration regarding consequences)
  • educate users about their privacy, their public life online and netiquette
  • educate users, before and after their registration, about their involvement in the project and the publication of related data (commits, archives, forums, blogs, IRC logs, etc.):
    • "Chat rooms, forums, and/or news groups are available to our community. Any information that you disclosed in these areas becomes public information. Please exercise caution when deciding to disclose any personal information in those areas."
  • no redistribution of users personal identifying data outside of Mageia.org scope
  • user data must only be accessed per user approval and for its own use/benefit
  • disclose in detail what data is collected, by whom, why, what for, how long
  • disclose how to prevent some of this data to be collected anyway (opt out)
  • disclose who to contact in case of data abuse, leak, doubt, account forced removal, etc.
  • actual official privacy policy will be written/committed in a editable plain text format (rendered afterwise for better display, but source version is still available); each update/revision of this policy must be notified (blog/ml) with a rationale about the change and the related diff between the old and new versions.

SHOULD

  • user account removal should not harm apps and contents consistency

COULD

WILL NOT, NEVER

Proposals

It's not a black or white world. To improve our understanding of users and usages, we could need to use some info usually delivered transparently by users. So we need to list any type of user data we may be using at some level, to explain what we would use, why, or why not, and in what scope. Goal is to be explicit.

To be notified to users when using such services/software (through a privacy policy, a warning, terms of use, whatever), we would like to:

Type of information Intended usage Note
IP address Adapt Web sites or services to user location (local server, locale, other) A remote/local service may be queried to associate this IP address with a country/city location
Gather usage/downloads statistics (country/city level at most)
Browser headers Adapt Web sites or services to user preferences (locale, other)
Gather usage stats (locale, browser, device)
Cookie Keep user sessions on our Web apps
Cookie/events Collect anonymous traffic data for usage statistics and discovery A remote/local service may be used to collect and munch this data

Anonymous here means: not linking behaviour data to discovered/known user account (better definition?).

Remote/local service may be:

  • maxdata geodb
  • google analytics
  • piwik
  • other?

Other privacy policies