Some comments about the long-term changes this will require.

Certainly the translation drafts need to become public. It's such a bad idea to allow Wikimedia to be a secret storage and messaging service.

However, once these drafts become public, Risker's checklist for content-creation extensions comes into play. As fully described there (and read it) the translation content needs to be properly moderatable, including logging of changes, ability for admins to delete drafts and for oversighters to suppress it (and yes, there needs to be a distinction).

However, this extension is cross-Wikipedias. I can access on German Wikipedia the test translation draft I made on English Wikipedia. So which language sysops should have the power to delete, which language oversighters the power to suppress? Unless all WP language sysops are given the power, hence giving me as an EnWP admin some power over a DeWP user, the only sensible usergroup for moderators would be the Stewards, and that is so not their job.

So drafts need to be localised to a wiki (sensibly, that of the target language) to enable that Wiki's admins/functionaries to take moderation actions.

There are probably other problems I haven't mentioned as well.

P.S. In addition to my above comments, given that public drafts would require moderation, the question arises as to who would do it. The EnWP community strongly rejected the WMF's presumption it would moderate Gather. Perhaps since CX is more content-focused they would be more willing, but that is not a given.

Adding on from the detailed responses above by @BethNaught - could draft translations actually be saved to the Draft: namespace? Perhaps the following:

• once X % has been translated (which the current tool has the functionality to detect) it auto-saves to a "Draft:TargetArticleName-cx"
• any significant update would be auto-saved to the draft (as an edit, boilerplace summary with tag?)
• clicking publish moves the page to the target or alternatively submits it for AfC? Getting patrol/review etc

I'm working with the team on a more detailed response to these concerns, but I wanted to quickly clarify the legal position. As Luis stated in T39992#947108 , there is no legal prohibition on storing server-side private drafts.

I don't think anyone believed it was *illegal* to store sever-side drafts. There are strong concerns that it's a very bad idea and extremely undesirable. Current user-private data very limited, very low visibility, and very impractical/implausible to use. Private server drafts is an obvious and practically unlimited text store. It is trivially usable for modest size binary files, with only minor inconvenience. Large binary storage is possible but implausibly impractical.

I'm not sure if the WMF is following the community discussion, so I'll offer my view of the key points of significance. To aid in putting this in WMF terms, I'll also identify LIKELY ACTIONABLE BLOCKERS which (I think) will resolve community concerns, but I'm merely offering my personal interpretation.

• The community has effectively shut it off as provisional urgent response. Any user with less than 5,000 edits gets blocked with an explanation if they try to save to article space. The 5,000 limit was preliminary, to allow testing. Users are (currently) allowed to evade the block by saving to other spaces like Draft and User, which could then be moved to article space.
• The community is probably going to lower the 5,000 edit limit to ExtendedConfirmed (500 edits / 30 days) while we sort this out.
• The community is speedily deleting a significant number of pages created with CX, and some will almost certainly go through the normal slower deletion process. It will be <s>weeks before the WMF's basic stats for pages-not-deleted has any meaningful resemblance to actual useful pages created via CX</s>. EDIT: quite a few are becoming redirects. Looking at non-deleted stats is never going to represent productive new pages.
• LIKELY ACTIONABLE BLOCKER: The community is very interested in putting this under the UserRights system. The most likely EnWiki scenario seems to be including CX under ExtendedConfirmed, plus allowing admins to directly grant CX to any user with a demonstrated grasp of English and basic familiarity with article expectations. Other Wikis can establish whatever standards they see fit.
• LIKELY ACTIONABLE BLOCKER: Private server-side saves for work-in-progress are an issue. Most discussion is centered on changing this to public saves in draft/user space, but in my opinion that's the wrong fix. Any temporary private save should use local storage to avoid community labor and concerns over that "temporary" content, and avoid possible community deletion of works-in-progress. Any version of public saves, other than simply dumping to standard draft/userpages, would create major developer headaches duplicating the exact same set of required moderation and tracking functionality.

In T141576#2507883, @Alsee wrote:

I don't think anyone believed it was *illegal* to store sever-side drafts. There are strong concerns that it's a very bad idea and extremely undesirable.

Thanks for the clarification. I found your summary very helpful. I just want to avoid any misconception based on James's old comment in T39992 about possible legal risk, since it was incorrect and exaggerated.

This is ridiculous. This is the same logic of tapping into everyone's phones because THEY COULD BE SAYING BAD THINGS and surveilling that and punishing anything that insults the surveillers, when if they weren't tapping into their phones in the first place they'd not get insulted either.

Nobody else sees the private drafts. That's the whole point of private drafts. Why do you care if they're there? Why do you care what's in them, or if they have bad things? How does the contents of private, unsharable drafts affect you in the slightest?

@Isarra: it is explained at T39992#424332 I completely agree however that the concerns about this feature seem completely exaggerated.
Do you really think that the WMF will start getting hundreds of subpoenas to view the users drafts? Specially given the low quality that may be expected on what people writes.

WHEN the wmf gets overloaded from them, then I would consider removing the feature (with appropriate announcements on how the government requests for spying forced us to do so) but currently these seems worrying about a non-existent problem.

In addition to the legal concerns, on which we are now awaiting input from the legal team, has it occured to you that a) private drafts are inherently un-wiki (but that's a side issue here), b) that on a point of principle we find it highly concerning and disasteful that such activites could be carried out on Wikipedia. It is not like tapping people's phones, because Wikipedia is not a social network nor a telecommunications service; it is a collaborative project to build an encyclopaedia, and (theoretically speaking) all activity on it should be pointed in that direction. Also "insult" is a strawman, this isn't about trying to be Thought Police; note also that drafts are shareable (via shared passwords) and I believe (though I can't find the ticket) that the language team are planning to implement collaborative translation drafts in the future.

Any word back from the foundation staff on this @BethNaught ?

In T141576#2538735, @Xaosflux wrote:

Any word back from the foundation staff on this @BethNaught ?

No, I haven't heard anything. If they're writing a detailed legal opinion I wouldn't expect anything too quickly.

Can we get an update on this? It's been 2 weeks, Is WMF Legal still working on a statement?

In T141576#2587155, @Tazerdadog wrote:

Can we get an update on this? It's been 2 weeks, Is WMF Legal still working on a statement?

Hi @Tazerdadog, I'm preparing the statement for the Legal team, and we will share early next week.

In T141576#2507883, @Alsee wrote:

Current user-private data very limited, very low visibility, and very impractical/implausible to use. Private server drafts is an obvious and practically unlimited text store. It is trivially usable for modest size binary files, with only minor inconvenience. Large binary storage is possible but implausibly impractical.

Can't stashed uploads be used for the same evil purpose as described in T39992#424332, but even more explicitly, since you can just upload the image and not a base64 representation of it? They're private, can stay on the server for a period of time, and a single account with a shared password between people can be used to upload evil things to share between them.

Hi all,

I wanted to follow up with a more thorough response from the Wikimedia Legal department. We have taken a look at the legal considerations of hosting private drafts, and we reviewed and approved the feature before it went live. We are confident that we can respond to complaints and defend the Wikimedia Foundation if necessary. As Luis (Wikimedia Deputy General Counsel at the time) mentioned in T39992#947108, there is not a blanket legal prohibition on hosting private server-side drafts. When users save drafts, they are still required to comply with our Terms of Use—including not sharing their password with third-parties to misuse the service for an illegal purpose. If we receive a legal complaint about improper content in a private draft, we have the legal and technical resources to remove it swiftly if we are required.

I think it's helpful to understand the feature in the context of the processes we follow when we receive a legal request to remove content or provide user information:

• The legal team has an attorney who regularly responds to disclosure requests, takedown notices, and other legal threats to the Foundation, and he can respond to issues in content translation drafts if we are required to do so.

• We have transparent processes to respond to requests by the government or anyone else. You can see the DMCA policy (for copyright complaints) and guidelines for request for user information. These same processes will govern content stored in private drafts.

• The number of takedowns we receive is reported in our biannual transparency report. On the legal team, we closely monitor this data (and the corresponding internal data) to understand the trends in our legal issues. As @Platonides suggests in this thread above, if we ever find that private drafts are causing a problem, we can redesign the system to address the issue.

I want to note that we aren’t able to disclose too much detail of our legal assessment of specific issues here. This is to protect us from third parties, whether private or government, who might try to take advantage if they knew our exact process in detail. What I can say is that based on our assessment of the feature and our internal legal response process, we are comfortable with the potential compliance and defense cost of this feature. We can host private drafts and continue to keep the Wikimedia users and projects safe.

[I just randomly stumbled across this bug]

I just want to note that the statement by Alsee

There are strong concerns that [private content] a very bad idea and extremely undesirable. Current user-private data very limited, very low visibility, and very impractical/implausible to use

Is umm totally untrue. While the low visibility part is right, there are many low visibility ways to store private aribitrary data in Wikimedia projects even without the content translation extension.