Talk:Privacy Policy

Email between users
What do you think of this? This should be placed after the current "email communications" text, in the same section.

In addition to the above automated messages sent by the Services, users with verified email addresses may wish to communicate with each other. By default, if you have a verified email address other users may use the EmailUser Special page (hereafter "EmailUser functionality") to send messages to other users. When you do this, the message you send will include a header and footer created by the Services, the text you choose to send, and a from address of your verified email address. You will not know the target users email unless they reply, in which case communications may continue by email. If you reply to anyone's sent emails, they will see your email. Under your user preferences there is an option called "Enable email from other users," unchecking this will disable the EmailUser functionality, but you will still receive emails generated by the Services.

-- Cheers, NDKilla ( Talk • Contribs ) 16:28, 26 September 2016 (UTC)


 * I updated the page because I didn't realize functionality was changed to make EmailUser messages appear as 'from' noreply@undefinedmiraheze.org but it can still reveal your email address. -- Cheers, NDKilla ( Talk • Contribs ) 00:38, 27 September 2016 (UTC)
 * Cool thanks bro, but the point of this is not to describe specific functionality, but explain the ways in which private data can become not-private data. Implementation details should not be in the language spec.  ...Uh wait this is not Perl 6. I mean, legal code should not describe the process, but the results.  Labster (talk) 08:14, 27 September 2016 (UTC)
 * Alright, I'm good with it as is. I dunno if I was tired or what but I just realized that (unlike my text above) you didn't say it was 'from' your email address, but that it includes your email address :p I just wanted to be clear that the message isn't coming directly from a user to you (or vice/versa) and I guess that is :) -- Cheers, NDKilla ( Talk • Contribs ) 13:58, 27 September 2016 (UTC)

Compare with other policies
How does this policy compare with other policies out there? RobertSter (talk) 17:07, 26 September 2016 (UTC)


 * Compared to ShoutWiki? "User information is stored on servers in the state of Chicago, USA."  I'd say pretty well.  Actually their policy is pretty terrible, as it has sections like this: "ShoutWiki wikis are provided "as is". ShoutWiki has no responsibility for lack of availability of any wiki or of any particular content. You should be aware that the wikis are editable by the public, and, as such, may contain inappropriate content at any time."  That's ToS territory and has zero to do with privacy.
 * And then there's Wikia's privacy policy: "We utilize the Krux platform and cookies to store Non-PII regarding our users. Krux uses a number of technologies, in addition to cookies, to collect Non-PII data based on its analysis of your interaction with our sites and to select advertisements or content to provide to you." It's in some ways shorter, a little less specific and uh, this:
 * Wikia only shares your information with others in the following circumstances:
 * 2. With our subsidiaries and affiliated companies, contractors, and vendors. We require these parties to process your information in compliance with this policy.
 * I'm pretty sure that this clause is recursive. Labster (talk) 19:55, 27 September 2016 (UTC)

How are the volunteers vetted
You mention:

"Miraheze personnel and a small number of vetted volunteers have access to content on private wikis as part of their role in assisting to provide our Services."


 * Who are the Miraheze personnel?
 * How are the volunteers vetted?
 * Hi, the personal are as follows
 * Southparkfan
 * Labster
 * Reception123
 * JohnLewis
 * NDKilla
 * MacFan4000 (talk) 17:41, 9 December 2016 (UTC)

Everyone in the global Steward group or the global sysadmin group can access private wikis. Although this should probably be at Meta talk:Privacy policy/Draft. -- Cheers, NDKilla ( Talk • Contribs ) 17:59, 9 December 2016 (UTC)
 * Well, not anymore, this is now the correct talk page. Anyway, we don't have a lot of process for vetting here -- the current process is more or less "we all knew each other from other wikis/wiki farms, and we seemed like good chaps with some technical knowledge."  There's no explicit NDAs with regards to private data, but this could change.  On the other hand anyone leaking private data will end up out of Miraheze pretty quickly, as we take privacy seriously.
 * Right now Stewards are an even more exclusive group than sysadmins. I expect that they'll have to be approved by the community, as well as by existing Stewards.  We'll be looking for people who had a long history in a sysop or bureaucrat role, who are generally known to have served with distinction.
 * Personnel at this point means sysadmins (and me, a programmer and pretend sysadmin). In the future it could expand to include other technical support, but also community support.  This could be community help, outreach, legal support, etc.  These people will be approved by the Miraheze board -- which again, right now, are the syadmins.  We're a very technical-heavy group right now.  Future personnel may or may not get access to personal information, depending on our needs.
 * Right now there are no plans to expand either of these groups, but we'll keep you informed. Labster (talk) 08:33, 12 December 2016 (UTC)

Policy template
Can we add the policy template to the top? MacFan4000 (talk) 20:20, 10 December 2016 (UTC)
 * Ping @ admins. MacFan4000 (talk) 13:39, 11 December 2016 (UTC)

A well-drafted policy
Just read through the privacy policy. It gets to the point a lot quicker than other privacy policies so great work to all those involved in drafting this policy. Borderman  talk 13:44, 11 December 2016 (UTC)
 * You really need to thank Philip Neustrom of localwiki.org for letting us use the privacy policy from his wiki. He had some lawyers help to draft it, but he graciously licensed it CC-0 so we could reuse it. Obviously I've made some alterations for our use and our software, but it is mostly the same.  The core values of our wiki farms are very much the same, it's just they're much more focused on geographic communities.  Labster (talk) 08:15, 12 December 2016 (UTC)

translations
I have prepared a translatable version of this policy here. Could it be implemented? MacFan4000 (talk) 13:53, 29 August 2017 (UTC)
 * Since these policies are sensitive, we need to have a clear message that the translation does not represent the official policy and if there are any discrepancies between languages English is always the correct version, like here. Reception123 (talk) ( contribs  ) 17:14, 29 August 2017 (UTC)
 * ✅ MacFan4000 (talk) 17:53, 29 August 2017 (UTC)
 * That's good, but personally I don't like the fact that it's also mentioned on the English version, and it feels pointless to me. I'm not sure if it can only be done for translate pages, but I'd prefer it that way. Reception123 (talk) ( contribs  ) 17:56, 29 August 2017 (UTC)
 * I altered it a bit. MacFan4000 (talk) 21:20, 9 September 2017 (UTC)

GDPR
So, we're going to need a few changes here thanks to EU law. Worst case scenario they try to fine us, I go "lolnope, U.S. citizen", and then I never get to visit Europe again. But hey, I want an exit plan once this Trump thing heads south, so let's try actually complying with the law first.

If people aren't familiar with it, the European Union is enacting the General Data Protection Regulation. It's kind of a big deal. There are several requirements that we should meet that we aren't quite doing yet:
 * Special:CreateAccount doesn't ask for explicit "consent" to logging. Quotes because that word should be used.  We should probably have a checkbox here, but not sure how we would log/enforce that.
 * Develop a process for breach notification. I assume that process is:
 * Create a security ticket
 * Identify and deploy threat mitigation measures (upgrades, software config)
 * Try to understand what sort of data may have been leaked
 * If possible, identify which users were affected, with a preference for assuming the worst-case scenario
 * Contact those users and identify to them what kinds of data were breached
 * Email, when we have it
 * Can we push a notification on everyone's queue?
 * Sitewide notice, with link to more info
 * We have a twitter too, I guess
 * Edit the privacy policy to provide a specific right to request all personal data we have on a user/IP
 * Figure out how the heck to do that. I'm guessing users tables and mysql?  Whatever it is, it's gotta be in a machine-readable format, so like CSV, sqlite, or openssh RSA randomart.
 * Identify which extensions store data on users.
 * Make a process. We get 1 month to comply to a request.
 * Edit the privacy policy to provide a specific right to delete all personal data we have on a user/IP
 * Edits are out of the question, because rights are granted to publish under CC* licenses.
 * We may be able to delete some edit metadata, figure out what this is. But without any form of attribution, Miraheze would be in violation of the BY clause of the licenses, so perhaps not PII can be legally deleted.
 * Should add an explanation on the processing of PII to the privacy policy, or basically the lack thereof. Something something piwik.
 * There's a right of rectification too. Do we have to do anything to allow users to change their data?  Perhaps explain in policy.
 * Privacy by design sounds great, but since 99+% of our designs depend on other people's software, there's only so much we can do.
 * Anyone want to be a Data Protection Officer? There will be cake.

We have a lot of things already done, like we document and inform users about what data we do collect. We made sure to write everything in clear language. We don't target children, so there's nothing to worry about there.

So that's my thoughts and todo list. I guess we need to get to work. --Labster (talk) 08:05, 20 May 2018 (UTC)


 * For consent to logging, we could either manually do an edit, or use that extension (forgot its name right now) which adds checkboxes. In any case, this is something that the WMF also needs to do presumably, so they might implement this themselves.


 * For breaches, we definitely have numerous ways of altering users (email - a script can be written, Twitter, Facebook, Sitenotice, mass-message).


 * Editing the Privacy Policy is your department, so I guess we'll leave you to that.


 * As for the MediaWiki-specific things that you mention (such as providing information on a user and such) my belief is that the WMF will create some sort of system for that, which should be public soon, so let's wait and see.


 * For the Data Protection Officer, what exactly does that imply? I guess any sysadmin willing to learn more about data protection and the GDPR can volunteer for that one. Reception123 (talk) ('C' ) 09:01, 20 May 2018 (UTC)
 * CheckUser stores the data for latest 90 days of edit, logged actions, password reset. (No log-in log.)
 * Proving ownership of account (for the sake of accessing information of the user) - edit on wiki is fine.
 * Proving ownership of IP address (for the sake of accessing information of the IP address) - I believe only reliable way to confirm this is sending an email from WHOIS database or other definite way of proving static IP's ownership. (Residential IP address changes, just editing can reveal other's PII. C.f. GDPR text (63) "That right should not adversely affect the rights or freedoms of others")
 * Breach notification: There's Special:MassMessage, but that depends on the user visiting the wiki.
 * Right to be forgotten - GDPR (65) : "However, the further retention of the personal data should be lawful where it is necessary, for exercising the right of freedom of expression and information, for compliance with a legal obligation, for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, on the grounds of public interest in the area of public health, for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, or for the establishment, exercise or defence of legal claims." ( This underline is mine ) For the underlined part, we can't simply remove the CCL'ed part (i.e. Username) from the database, IMO, IANAL.
 * &mdash; revi  14:08, 20 May 2018 (UTC)
 * Out of curiosity, would something like enwiki's courtesy vanishing be adequate for the right to be forgotten stuff? Also:
 * "DPOs mustbe appointed in the case of: (a) public authorities, (b) organizations that engage in large scale systematic monitoring, or (c) organizations that engage in large scale processing of sensitive personal data (Art. 37). If your organization doesn’t fall into one of these categories, then you do not need to appoint a DPO."
 * -- Void  Whispers 17:01, 20 May 2018 (UTC)
 * Some replies:
 * For the Special:CreateAccount case, because we have real name and email address as optional, if we modify the headers to note that the data is optional and providing it will be taken as consent, we satisfy the GDPR requirement as it is a free choice, it's opt-in, it's clear plain language and we're not taking a "default consent" approach.
 * For breach information, Tech:Compromised Handling covers this as an internal policy and it will be up to Operations to notify the community and anyone affected. The notification method for an issue is contacting operations whom will then notify through the channels of social media, on-wiki break down and then contacting users en-masse if their information is compromised.
 * John (talk) 18:45, 22 May 2018 (UTC)