Talk:Privacy Policy

Email between users

@Labster: 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)

@Labster: I updated the page because I didn't realize functionality was changed to make EmailUser messages appear as 'from' noreplymiraheze.org but it can still reveal your email address. -- Cheers, NDKilla ^{( Talk • Contribs )} 00:38, 27 September 2016 (UTC)

@NDKilla: 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)

@Labster: 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)

• @RobertSter: 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 | contribs | email} 13:44, 11 December 2016 (UTC)

@Borderman: 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)

 Added a note 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:
  1. Create a security ticket
  2. Identify and deploy threat mitigation measures (upgrades, software config)
  3. Try to understand what sort of data may have been leaked
  4. If possible, identify which users were affected, with a preference for assuming the worst-case scenario
  5. 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, @Labster: 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.

— 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)

Typo in GDRP message

Due to the GDPR, Miraheze has updated it's privacy policy effective 25 May 2018.

"it's" should be "its". SelfCloak (talk) 14:10, 27 May 2018 (UTC)

•  Done Paladox (talk) 14:14, 27 May 2018 (UTC)

Concerns

I am concerning that people of any age will join and edit this wiki. Ofreporter_{Send me a message!} 11:10, 20 January 2019 (UTC)

Question

If not because of COPPA, why exactly does the age rule exist? FatBurn0000 (sandbox | CentralAuth) 08:28, 25 June 2022 (UTC)

GDPR. There are ways to deal with underage users but between the international liabilities and general best practice on the internet, it's far preferable to simply disallow them and keep our hands off any potentially personal information. --Raidarr (talk) 13:23, 25 June 2022 (UTC)

I disagree. I think that prohibiting children from signing up or editing is ageist. Children need a voice online. I know that misguided privacy laws like COPPA and GDPR can complicate matters, but simply prohibiting children is a very lazy approach. Shouldn't websites follow Google's lead and allow parents to create accounts for their children in order to comply with these laws?

I think that this is still ageist, as children should have the right to create their own account without getting a third-party involved, just like adults do. I believe that children can consent to having their data collected, just like adults. But websites have to follow the law. Sometimes this requires policies that would otherwise be immoral, like not letting children create accounts on their own and TikTok not allowing Indians to access the platform.

But laws that require otherwise immoral policies should be complied with in an ethical manner. Just like TikTok should show a polite, descriptive error message to Indians, not insult them; websites should allow parents to create accounts for their children, not ban children completely. --Prunella (talk) 00:17, 14 November 2022 (UTC)

It does not matter how 'ageist' it appears: individuals under 13 represent a legal liability beyond the basics that come with parents involved in a platform like this or the general maturity of children at that age (which is another reason why such a block may be in place in the first place). If you think the law is an issue, advocate in a legal avenue where this may be changed so a more accepting policy is feasible for platforms. This platform can go nowhere with such advocacy and it does not have the volunteering power nor frankly interest in jumping the hoops required to permit with caveats having under 13 individuals. Google does what is within its means: Miraheze follows the practice of websites that work within their means.. --Raidarr (talk) 01:45, 14 November 2022 (UTC)

Are children welcome to create accounts/edit?

Is there an age limit for this wiki farm? Miraheze is non-profit, so that means COPPA doesn't apply. But GDPR (both EU and UK) still does. As I understand EU GDPR, it requires companies/organisations to only collect the data of under 16s with parental permission. This means that Miraheze is obligated to not allow under 16s in the EU to edit/sign up unless their parents have given permission.

But since Miraheze is hosted in the UK, UK GDPR applies worldwide. Its age limit is 13 rather than 16. The result is that Miraheze is obligated to prohibit children from signing up/editing without parental permission, with people being counted as "children" only if they are under 13, unless they live in the EU, in which case it is 16.

Additionally, if Miraheze ever finds that a child has signed up/edited without parental permission, it must delete their account/hide their IP address. If the child has revealed any personal information, it must be deleted.

And parents must be given the right to have their children's data erased. Adults (13 or over, 16 or over for EU) must be given the right to have their own data erased. --Prunella (talk) 00:53, 14 November 2022 (UTC)

You seem to have answered your own question, "are children welcome to create accounts/edit?" As you answered, only if they're over 13. Is there anything in particular that you want us to answer? Agent Isai ^{Talk to me!} 01:18, 14 November 2022 (UTC)

But I'm confused, because the sign up page doesn't ask for age or date of birth. And Miraheze doesn't have any age-related policies apart from the erasure one.

I really want all ages to be welcome, because I'm really disappointed about Fandom not allowing under 13s and I want an alternative that does. Can't under 13s be allowed with parental permission? --Prunella (talk) 01:31, 16 November 2022 (UTC)

See Underaged users. It would be too costly for us to verify parental permission and frankly, we don't have the resources to do it adequately. Agent Isai ^{Talk to me!} 02:05, 16 November 2022 (UTC)

Just wondering: Although sign-ups are verboten to those under 13, that doesn't prevent them from merely visiting Miraheze sites, right? (Asking as a long-fledgling children's author.) --Routhwick (talk) 03:39, 16 November 2022 (UTC)

No, not at all. The issue is collecting their data (which would occur if they sign up) but merely browsing the site is fine. Agent Isai ^{Talk to me!} 03:46, 16 November 2022 (UTC)

So parental permission needs to be verified? What would that involve? It may be costly, but it would be essential. Children deserve a voice online. Ageism against young people (adultism) is a significant human rights issue. Allowing children on Miraheze would be worth every cent. You don't allow children due to GDPR, but GDPR's rule about children was intended to protect them. Banning children from platforms reinforces adultism. Which leads to society not listening to children. Which is why many schools start too early, depriving children of sleep. Allowing children should be top priority. --Prunella (talk) 08:12, 16 November 2022 (UTC)

You are free to make a Request for Comment that makes this process a consideration, but until one succeeds and there is clearly community favor to pull it off, it will not be humored by platform volunteers. I suspect the argumentation you use would come under heavy fire in such a request, which would need to be addressed for this to be considered. --Raidarr (talk) 14:24, 16 November 2022 (UTC)

I would add that I believe it is highly unlikely that the community would be in favor of such a move but even so as it has been said above Miraheze has limited resources and it would not be able to handle that. I would also point out that both Facebook and Twitter require users to be at least 13 and I am sure many websites do the same. Reception123 (talk) (C) 20:25, 16 November 2022 (UTC)

Mathematical error in Privacy Policy

the number after one is two, not three, right?

this mistake is sort of obvious, I don't know why nobody's noticed it yet. Heerxingen (talk) 11:10, 1 March 2024 (UTC)

 Fixed --1108-Kiju/Talk 11:15, 1 March 2024 (UTC)