Page MenuHomeMiraheze

Audit user rights blacklist
Closed, ResolvedPublic

Description

Given recent incidents, I'm going to audit the blacklist and post results on this task.

AbuseFilter

  • abusefilter-privatedetails
  • abusefilter-privatedetails-log
  • abusefilter-hidden-log
  • abusefilter-hide-log
  • abusefilter-private
  • abusefilter-private-log

ArticleFeedbackV5

  • aft-oversighter

CentralAuth

  • All Rights blacklisted as appropiate

CheckUser

  • checkuser
  • checkuser-log
  • investigate (not yet used, behind config flag, added by @Paladox)

CreateWiki

  • createwiki

Flow

  • flow-suppress

GlobalBlocking

  • globalblock
  • globalblock-exempt

IncidentReporting

  • editincidents

ManageWiki

  • managewiki-restricted
  • managewiki-editdefault

MediawikiChat

  • viewpmlog

OATHAuth

  • oathauth-api-all T5768
  • oathauth-disable-for-user
  • oathauth-view-log
  • oathauth-verify-user

OAuth

  • all except propose & manageown

StopForumSpam

  • stopforumspam

Event Timeline

RhinosF1 updated the task description. (Show Details)Jun 11 2020, 16:21
RhinosF1 updated the task description. (Show Details)
RhinosF1 updated the task description. (Show Details)Jun 11 2020, 16:24
RhinosF1 updated the task description. (Show Details)Jun 11 2020, 16:27
RhinosF1 updated the task description. (Show Details)Jun 11 2020, 16:34
RhinosF1 updated the task description. (Show Details)Jun 11 2020, 16:43
RhinosF1 updated the task description. (Show Details)Jun 11 2020, 16:50
RhinosF1 added a subscriber: Paladox.

Got up to collection for now:
1 non-blacklisted right with no impact now found

@RhinosF1 can this task be resolved? It seems like all the rights have been audited

@RhinosF1 can this task be resolved? It seems like all the rights have been audited

No, I've only checked up to the collection.

RhinosF1 updated the task description. (Show Details)Jun 16 2020, 09:22
RhinosF1 updated the task description. (Show Details)Jun 16 2020, 09:30
RhinosF1 updated the task description. (Show Details)Jun 16 2020, 09:33
RhinosF1 updated the task description. (Show Details)Jun 16 2020, 09:35
RhinosF1 updated the task description. (Show Details)
RhinosF1 updated the task description. (Show Details)Jun 16 2020, 10:03
RhinosF1 updated the task description. (Show Details)Jun 16 2020, 10:10

Not done Social Profile as I can't find the ext.json for UserProfile

RhinosF1 updated the task description. (Show Details)Jun 16 2020, 10:28
RhinosF1 updated the task description. (Show Details)Jun 16 2020, 10:36

Checked upto and including StopForumSpam now

Progress? High priority tasks should be resolved as soon as is practically possible, not at a leisurely pace

In T5735#113027, @John wrote:

Progress? High priority tasks should be resolved as soon as is practically possible, not at a leisurely pace

Will get on it and finish on Wednesday

The only things left to check are titleblacklist once/as T5798 is resolved, work out what Wikibase's 'viewuserlang' right is but it seems disabled and SocialProfile which I'm not comfortable reviewing.

Everything else looks good to me.

RhinosF1 removed RhinosF1 as the assignee of this task.Jun 24 2020, 09:24
Paladox added a comment.Jun 28 2020, 01:05

viewuserlang comes from WikimediaIncubator. From the looks of it, it looks safe to me.

Void added a comment.Jun 28 2020, 02:33

We've both blacklisted titleblacklistlog and disabled the functionality of the extension that generates those logs. For future reference, the wgTitleBlacklistLogHits seems to only log titleblacklist hits that prevent account creations, which reveals the IP address that attempted to create the account. This is somewhat of an edge case, but I do not believe we will need those logs for anything, nor do I believe anyone (without an NDA) should be able to access which logs that do exist (which should only be on test2wiki right now).

RhinosF1 closed this task as Resolved.Jun 28 2020, 07:43
RhinosF1 claimed this task.

Closing then

RhinosF1 reopened this task as Open.Jun 28 2020, 07:44

Sorry, just SocialProfile left to audit

Southparkfan edited projects, added Security; removed acl*security.Jul 1 2020, 21:58
RhinosF1 removed RhinosF1 as the assignee of this task.Jul 2 2020, 09:37
John added a comment.Jul 2 2020, 10:39

Something not right here, either this isn’t a high priority security issue, or we’re not taking this issue seriously. Can someone please confirm which it is, and do the necessary steps to resolve it as this is way past a reasonable SLA.

In T5735#114295, @John wrote:

Something not right here, either this isn’t a high priority security issue, or we’re not taking this issue seriously. Can someone please confirm which it is, and do the necessary steps to resolve it as this is way past a reasonable SLA.

It's waiting on someone more confident with SocialProfile to check over that. I'll ask @Paladox later.

Paladox changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 2 2020, 14:31
Paladox changed the edit policy from "Custom Policy" to "All Users".

Seeing as how my comment at R9:40ce6aedcc660ec5435c2039ec9cb0eb7e1ef0e1 went unanswered, I will post it here as well: if the TitleBlacklist Log reveals private information (which per Void, who is trustworthy, apparently it does) - should this be reported Upstream given the fact that sysops have the titleblacklistlog right by default when adding the extension?

Paladox added a comment.Jul 2 2020, 16:00

No, since sysop basically means admin. We've already blacklisted this right.

And the config is switched off by default anyways (that logs).

@Paladox no, what I'm asking/saying is that should the fact that the log reveals PII be reported upstream, so that if needed the developers can take away the right from sysops by default. I'm not sure it's a good idea to have an extension that automatically grants access to private data to general administrators.

Void added a comment.EditedJul 2 2020, 16:54

If I may clarify here:

The collection of this information is not inherently a privacy/security issue. There is a very legitimate use case in that it may be used by administrators to track and handle abuse cases, as well as easily verify account creation requests where the user is reporting that they hit the Titleblacklist. There is also potential reason to be concerned that an admin may create an overly sensitive blacklist for the purposes of collecting this information (which, to my knowledge, is stored permanently).

In our case:

  1. The use of these logs is fairly limited, as global aggregation of their contents is difficult/not practical, and the information we'd need from these logs can be privately obtained from the reporting user.
  2. From the standpoint of our Privacy Policy and requirements for storing private data (IPs, not even counting the potential link to a username), we cannot store this information without a valid use case, which we do not have.

However, other situations do exist, and the individuals working with those situations can handle them accordingly.

TLDR; no need to report, other people handle things differently.