Community Help Wiki locked down

[Elizabeth K. Joseph]

On Mon, Jan 11, 2016 at 1:51 PM, Gunnar Hjalmarsson <gunnarhj at ubuntu.com> wrote:
> On 2016-01-06 01:02, Elizabeth K. Joseph wrote:
>> Bad news: In order to triage this attack, the wiki has been locked
>> down.
>
> Just saw this bug report:
> https://launchpad.net/bugs/1532959
>
> Lyz, do you know whether any progress has been made? Getting a decent
> short-term solution in place should be given high priority IMO.

Progress depends upon us providing a response to IS, which we haven't
done because there haven't really been solid proposals on how to move
forward.

I think there is consensus that we shouldn't just have them shut down
the help.ubuntu.com/community/ wiki.

Simply enabling all editing again is a recipe for the spam bots to
return, nothing has changed so they can just create a bunch more
launchpad accounts and start again.

We've never had a big enough administrative team to do any kind of
"review edit before approval" thing, even if the wiki had this support
(it doesn't).

So, I've been casually chatting with some folks to come up with
solutions, there have been a few suggestions that we'd need to run by
Canonical IS:

1, Require joining a moderated launchpad group in order to edit, this
would add them to a ContributorGroup (a group IS suggested) that can
edit the wiki.

This would have to somehow be communicated to users who log in and
can't edit (the Ubuntu Etherpad requires a group membership, but does
a poor job of informing users, so there's frequently confusion).

We'd also need volunteers to run this and figure out criteria for
approving (how are we to know whether we're just adding spam accounts
again?).

And it would create lag in when a user finds an issue and when they
can fix it. We'd probably lose one-off contributors who just want to
fix something quickly and go back to their life.

2. See if some kind of join launchpad/edit limiting can be put in
place (I think this already exists, but there may be some more knobs
for IS to fiddle with that don't hurt real users).

3. Some kind of two-factor authentication requirement on your account
required for editing the wiki. This would also need to be communicated
to the user when their regular auth fails for wiki logins. I honestly
have no idea whether this is feasible.

Anything else? At the end of the week, I'll update the ticket with IS
with our ideas and they can look into it.

The first is the only solid proposal I could see working with the data
I have. If the spam attack has stopped maybe they can open up editing
to everyone again, just locking it down to that group when a problem
crops up.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2