Doom Wiki talk:Privacy policy

GDPR deficiencies - changes needed before May 25, 2018

Since pretty much anything with a web address falls under the purview of the EU's General Data Protection Regulation, we need to make some changes here. Upon a cursory review I find the following issues at minimum:

• First sentence: Participation on the Doom Wiki at DoomWiki.org, by design, rarely involves considerations of privacy - we cannot really say this any more; the EU now defines usernames and IP addresses as personal information and considers them subject to privacy laws, so they're now a full concern.
• Users that do register are identified by their chosen username. Since I believe MediaWiki 1.24, real name is an option for input on Special:CreateAccount and through user preferences and can be used instead of the username. This is also protected information and should be mentioned explicitly.
• the IP address used is publicly and permanently credited as the author of the edit. Under GDPR, if so requested, we will have to suppress IP address contribution by-lines using revision information suppression (aka oversight). So permanent is not necessarily the best choice of wording.
• Once created, user accounts will not be removed. It may be possible for a username to be changed, but there is no guarantee that a username will be changed on request - GDPR makes removal of accounts a legal right of EU citizens, so it would be necessary to merge a user's contributions into an anonymous account if a request for user deletion occurs - this is no longer optional for us.
• there is no expectation of any permanent deletion occurring. - Again also enumerated as a user right, and technologically possible however painful it may be under MediaWiki to have to run bespoke scripts to pull out and extinguish such information.
• When a visitor requests or reads a page, no more information is collected than is typically collected by web sites. MancuNET may retain raw logs of such transactions, including the originating IP addresses, but these will not be published nor used to track legitimate users. - We need to fully enumerate the information collected by Apache when a web hit occurs. WikiMedia Foundation has more complete wording in their policy now that we can borrow.
• This information is automatically deleted after a set period. - We need to figure out the actual retention lengths anywhere this wording is used, or, as an alternative use the language "for the minimum length of time technically required."
• Information transmitted to these third-party sites is limited to the minimum possible and is anonymized to the greatest extent possible. - Making this more explicit in the same manner as explaining what information is automatically collected by our own server is needed.
• Due to lack of participation and interest, however, the Doom Wiki has not constructed formalized procedures to handle such issues. Further, per the introductory paragraph, we have little or no empirical experience to inform best practices. The above text represents an educated guess as to what constitutes reasonable behavior by administrators and contributors. It has not been "ratified" by anyone, and individual administrators or database maintainers may disagree with some provisions. As in all cases of policy enforcement on DoomWiki.org, administrators are expected to use their common sense and good judgement to derive a workable solution.
  • None of this flies any longer unfortunately:
  • This needs to become a full-force official policy.
  • Users must be assured that staff members will comply by legal necessity.
  • Additional language and best practices can be borrowed from other organizations, such as WMF

--Quasar (talk) 08:38, 22 May 2018 (CDT)

Most of this is simply inexact language, which arises from condensing the WMF version [1].  The WMF version includes pages of detail about the applicable ethical principles and the technical remedies to be followed.  I know almost nothing on the server side, and everyone who does was busy with debugging and configuration.  I certainly did know that admins would disregard any enforcement procedure they disagreed with.  Therefore, I summarized the detailed statements into general ones.  Those can be improved, as you say, now that we're better informed.

The last part gets into a broader issue of what obligations go along with the admin position.  To my knowledge this is the first time a specific "legal necessity" has been stated.  If you're serious about this, then I assume (a) all admins must explicitly agree or be demoted, (b) the shell users' collective skill set must be known to include all of the corrective activities proposed, and (c) off-wiki contact information must be provided in case harm would be caused by a public request.

I agree this document should be changed first since it is visible immediately on the transition date, but I expect it will need tweaking as the above described inventory and tools become available.    Ryan W (living fossil) 17:56, 22 May 2018 (CDT)

I envision that bureaucrats should be the only ones burdened with any compliance activities (aside from helping get this document updated) - frontend admins should rarely have to deal with it by doing anything more than referring somebody to this policy and to my contact info (I'll be the "designated" information officer or whatever it is they're calling it, since nobody else really has the full amount of access required and is ever actually around here to deal with stuff). --Quasar (talk) 02:53, 23 May 2018 (CDT)

Highest priority improvements

Numbering these in advance in case of RL interruptions.  I will fill in any diffs I create.

As I said on IRC, each paragraph imported from the WMF version is not ipso facto incrementally better compliance, as tempting as that is to believe, because the WMF has not yet audited its policies for compliance [2].  Some points might well be steps backward, at least regarding the spirit of the regulation.

1. Permitted uses section: The current policy takes great pains to confine these to specific reactive steps that protect the project (malicious editing, downtime, imminent legal proceedings).  Are we now broadly allowing proactive research with no identified risks?  help you share your knowledge with the world; create new features; learn more about how the Project Site is used — that could mean anything.  If this is to encompass ongoing development activity like extension maintenance or SEO, I suppose that's unavoidable, but mention them as narrow exceptions.
8. Will MancuNET have its own public document?  If so, that should be enumerated in the warning text about offsite privacy policies applying concomitantly.  If not, we should avoid reference to actions that only Manc has permissions to do, unless Manc indeed agrees to do them.
10. To Protect You, Ourselves and Others: It is hardly tenable to instantly elevate all policies to privacy-superseding status!  Our historical practice is for one contributor to write a document with no discussion and very little research.  If we wish a public commitment to be legally bound by a particular policy, which is probably a sign of the project's maturing, then we must actually review it first (as we did with the ToU and are doing here).  This is in contrast to the WMF process which not only involves a legal team, but a place where they can establish global policies which override community-authored pages in case of inconsistency (the Meta-Wiki).  Therefore, incomplete or outdated pages on a specific project are not a legal risk in the same way.  to protect our organization, employees, contractors, users, or the public — as with #1 above, this is an invitation to fishing expeditions.  Investigatory laws in the US are already incredibly broad, so what is the motivation for proactively going beyond them?  assess and address — at face value this seems a bit excessive also, but if shell users find it an accurate description of their day-to-day tasks, so be it.  imminent and serious bodily harm or death — IIRC this was added in response to the Michelle Carter case, where it was found that protection of one person superseded constitutional rights in an entire state.  From that wording you can probably guess my opinion, but I am also against risking our project's existence in breaching experiments, so I left it in.  All that said, if the GDPR specifically mentions such situations as NOT being exceptions, then this sentence doesn't belong.
12. Project Staff: Per the above post regarding bureaucrats should be the only ones burdened with any compliance activities and related IRC discussion, I've attempted to make this less ambiguous.  I'm not sure how much it would help with an actual legal filing or police investigation, since we would have zero control over who was investigated, but at least the language should be clear enough now for straightforward cases.  A reader with a request should go to the staff, not to a random user with any level of enhanced permissions, who may or may not even be active...  The biggest hole was the COPPA wording, which I've never liked, but could make the argument that (per the disclaimer section) I had no additional legal obligations beyond what I had the instant I became an admin.  Now I can't assume that.  The wording might still be incomplete; how do large social media outlets or forums apologize for not being able to moderate all traffic in real time?  Do we need "report abuse" links everywhere like Doomworld has?  Does the COPPA statute itself specify response times?  A GDPR request made on behalf of a child would be especially important to get right the first time, because no good faith on our part would be assumed whatsoever.  :P   More immediately, the GDPR seems to include some detail about how requests should be handled slightly differently for children, which might suggest wording tweaks here.

Ryan W (living fossil) 14:24, 26 May 2018 (CDT)

For number one, those were precisely some of the use cases I had in mind by adopting those statements, and ones I feel have already occurred in the past, ie, with the roll-out of Google Analytics in order to understand our site usage metrics, we're effectively using some of the protected data in this way just to make the site work. These are almost unavoidable in the course of running a website.

I do not follow on your point about MancuNET, so I need further explanation. "MancuNET" is just a group of servers for which the maintenance accounts are owned by Mike Lightner. If you believe inclusion of the name in this document is overcomplicating matters, then I would suggest it be removed entirely.

--Quasar (talk) 14:30, 26 May 2018 (CDT)

Ah, OK.  I thought it was more centralized than that.  You have mentioned in the past that you didn't have enough access to perform some maintenance task, and everything seems to stop short until manc can be found.  If such would be a sticking point in responding to a request, I would think the staff should discuss that.  Assuming you do, though, IMO it's fine to just keep saying "the Project" instead.    Ryan W (living fossil) 15:48, 26 May 2018 (CDT)