Page MenuHomePhabricator

MediaWiki:Autoblocker etc. reveals to third party that a (blocked) user has used the same IP address
Open, HighPublic

Description

Certain MediaWiki: pages will reveal that a (blocked) user has been using that IP address, to any third party using the same IP.

In particular:

  • MediaWiki:Autoblocker
  • MediaWiki:Cantcreateaccount-text

As far as WMF projects are concerned the information relating a user to an IP should only be available to designated WMF staff and checkusers.

Worse the current text of

  • MediaWiki:Autoblockedtext

encourages the third party to publish the IP and account name on the Internet, unsing the {{unblock-auto}} template, which will remain publicly available in history, and archives, effectively for perpetuity.

Therefore the following steps should be taken:

0. A list of affected MediaWiki: pages should be created.

  1. On all WMF projects the pages should be re-written with a more neutral message, excluding any identifying information.
  2. The mechanism that passes the identifying information to the pages should be removed.
  3. Each project, with support where necessary, should perform an audit/oversight on uses (including uses in history) of the following templates (or their equivalents)
  • Template:Unblock-auto
  • Template:Unblock-auto reviewed
  • Template:Unblock-auto on hold

You can see where this has been done correctly, though possibly the private data is still visible to administrators, by viewing the history of wp:en:User talk:Leodj1992.


Version: 1.22.0
Severity: normal
URL: https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=5729964#Privacy_violation
See Also:
T44345: Blocks from AbuseFilter show up as performed from the target's IP address in Checkuser
T58227: Provide original user name as "intended blockee" in case of autoblock
T15131: Allow admins to correlate autoblocks to originating block (currently admin cannot see IF in fact the IP is autoblocked)

Details

Reference
bz53008

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:56 AM
bzimport set Reference to bz53008.
bzimport added a subscriber: Unknown Object (MLST).

If you're going to use "Violation of WMF Privacy policy" in the bug summary, you should directly quote the relevant portions of [[wmf:privacy policy]] that are allegedly being violated.

I'm not sure why MZMcBride is against privacy for our editors but should anyone need a direct quote to see that this is a Bad Thing:

"Except as described above, Wikimedia policy does not permit distribution of personally identifiable information under any circumstances."

(In reply to comment #2)

I'm not sure why MZMcBride is against privacy for our editors

No need to put words into other's mouths which were never said/written.
You were asked for a clear & specific quote. Nobody is "against privacy".

(In reply to comment #0)

Worse the current text of

  • MediaWiki:Autoblockedtext

encourages the third party to publish the IP and account name on the
Internet,
unsing the {{unblock-auto}} template, which will remain publicly available in
history, and archives, effectively for perpetuity.

Of course this applies only to en.wiki, I suggest to split non-MediaWiki issues to a report in Wikimedia>General.

Nemo is quite correct - The default appears to be:

"Your current IP address is $3, and the block ID is #$5. Please include all above details in any queries you make"

Step 2 will assure that the information is not leaked.

en: is not the _only_ wiki with this part problem, see for example http://vi.wikipedia.org/wiki/B%E1%BA%A3n_m%E1%BA%ABu:B%E1%BB%8F_c%E1%BA%A5m-t%E1%BB%B1_%C4%91%E1%BB%99ng

I will notify a few people of this bug and see if splitting it is a useful option.

(In reply to comment #3)

(In reply to comment #2)

I'm not sure why MZMcBride is against privacy for our editors

No need to put words into other's mouths which were never said/written.
You were asked for a clear & specific quote. Nobody is "against privacy".

MZMcBride has derided this as a non-problem on Meta, and followed it here. No explanation of why he has opposed having this fixed, has been given, except to hint that blocked users probably deserve to be outed, as do those who's user names bear some relation to their real life.

To me this attitude is very strange, and not helpful.

MZMcBride has derided this as a non-problem on Meta, and followed it here.
No
explanation of why he has opposed having this fixed, has been given, except
to
hint that blocked users probably deserve to be outed, as do those who's user
names bear some relation to their real life.
To me this attitude is very strange, and not helpful.

Be that as it may, his request to quote the section was not unreasonable.


Nemo is quite correct - The default appears to be:

If it was against the privacy policy, we would want to make it so that its not an option for people to do (privacy policy should be enforced in software where possible)

(In reply to comment #7)

If it was against the privacy policy, we would want to make it so that its
not
an option for people to do (privacy policy should be enforced in software
where
possible)

Indeed. Step 2 makes it impossible (by a code change) for the personal information to be leaked this way.

Steps 0 and 2 are wholly suited to being done by MediaWiki developers, steps 1 and 3 would ideally have community involvement, but should be managed on a Wikimedia-wide basis, and particularly step 3 overseen by WMF, whose policy it is.

In any case, I think we (devs) should wait for a comment from wmf legal team before doing anything on this bug.

Given that its somewhat useful to have this info in the block message, we would probably turn disabling it into a config option.

(In reply to comment #9)

In any case, I think we (devs) should wait for a comment from wmf legal team
before doing anything on this bug.

Did someone write legal@wm.o then?

Can someone give me an example of the supposed leakage? I'm looking, for example, at https://en.wikipedia.org/wiki/MediaWiki:Autoblockedtext , but it doesn't seem to say who was blocked- only that "someone" was blocked, why they were blocked, and what the IP was. Am I misreading the template? Are there other templates that do include the blocked user name?

[Tangentially, given the frequent completely fact-free speculation about the terms of the privacy policy, and that it is always good bugzilla policy to have complete information in bugs, in order to make good use of the time of the people who are responding to the bug, MZ's request seems quite reasonable.]

(In reply to comment #11)

Can someone give me an example of the supposed leakage? I'm looking, for
example, at https://en.wikipedia.org/wiki/MediaWiki:Autoblockedtext , but it
doesn't seem to say who was blocked- only that "someone" was blocked, why
they
were blocked, and what the IP was. Am I misreading the template? Are there
other templates that do include the blocked user name?
[Tangentially, given the frequent completely fact-free speculation about the
terms of the privacy policy, and that it is always good bugzilla policy to
have
complete information in bugs, in order to make good use of the time of the
people who are responding to the bug, MZ's request seems quite reasonable.]

Indeed some more clarity wouldn't harm, but you can look at translatewiki.net to have documentation on messages and their default wording: https://translatewiki.net/w/i.php?title=MediaWiki:Autoblockedtext/qqq&oldid=4580214

We have:

$7 - the intended target of the block (what the blocking user specified in the blocking form)

plus these two from which finding $7 is easy (but not for the clueless parent in the hypothesis and it need active action):

$6 - the expiry of the block
$8 - the timestamp when the block started

In the en.wiki message, perhaps Richard is referring to

$2 - the reason for the block

which may contain a mention of the username in question, especially for non-obvious cases (a link to user talk or other discussion and so on), right?
But I don't feel very smart tonight.

For autoblocks the reason is filled with message 'autoblocker' which contains

Autoblocked because your IP address has been recently used by "$1". The reason given for $1's block is "$2"

where $1 is the *other* username.

Possibly dumb question: why doesn't https://en.wikipedia.org/wiki/MediaWiki:Autoblockedtext show $7 and $8?

Less dumb question: what process would you go through, if given $6 and $8, to get $7?

The autoblocker text certainly looks problematic from db's description, but if I'm reading translatewiki correctly, is no longer used? ( https://translatewiki.net/wiki/MediaWiki:Autoblocker )

But this is my first experimenting with translatewiki, so feel free to correct.

enwiki has customized the message and does not use $7 and $8, that a local decision.

the local page on translatewiki is no longer requiered but https://translatewiki.net/wiki/MediaWiki:Autoblocker/en still exist and therefor the message. You can see that also an the fact, that under the logextract the text is and not a "no page text" hint.

(In reply to comment #15)

enwiki has customized the message and does not use $7 and $8, that a local
decision.

Ah, thanks.

the local page on translatewiki is no longer requiered but
https://translatewiki.net/wiki/MediaWiki:Autoblocker/en still exist and
therefor the message. You can see that also an the fact, that under the
logextract the text is and not a "no page text" hint.

Great, thanks for clarifying.

(In reply to comment #14)

Possibly dumb question: why doesn't
https://en.wikipedia.org/wiki/MediaWiki:Autoblockedtext show $7 and $8?

Probably just because it has not been substantially updated since 2008 when the default message was changes adding some parameters: https://translatewiki.net/w/i.php?title=MediaWiki:Autoblockedtext/en&diff=prev&oldid=644885

If you just want to hide private information, then the solution seems trivial: go to Translatewiki and modify [[MediaWiki:Autoblockedtext]] and related messages in all languages so that $2, $6, $7 and $8 aren't used. Also update the local [[MediaWiki:Autoblockedtext]] on all Wikimedia projects where the message has been modified locally.

saper added a comment.Oct 26 2013, 9:54 AM

One thing is the template issue which can be rectified locally but I guess the core of the problem is the [[MediaWiki:Autoblocker]] (block message) that gets populated to the templates together with the IP address.

I would like to point out that this information is also available in [[Special:BlockList]] - note that Autoblocker gives only the username, but no IP address (only block number).

If I understand correctly, the core of this problem is that both $3 and a $2 (possibly containing some user name) are made available to the MediaWiki message.

In the context of autoblocks we usually give out only block number ($5) and that should be enough for the administrators to handle the case.

So, one way to fix it is to stop giving $3 of [[MediaWiki:Autoblocktext]] together with $5 and $2 ($2 and $5 should be fine).

Probably for the sake of migration we should depreciate Autoblocktext and introduce a new message without $3, but I think i18n guys are best qualified to judge this.

Note to self: while pondering to have another Autoblocktext, consider using auto block also for extensions like AbuseFilter, see bug 42345. (subclassing of block)?

Additionally, in case of [[MediaWiki:autoblocktext]] $7 reveals the IP address as the "intended blockee" even in case of autoblock. I think this is another bug.

Another logged-in user sharing IP address with "Test1" tries to edit the page:

You do not have permission to edit this page, for the following reason:

Your IP address has been automatically blocked because it was used by another user, who was blocked by Saper. The reason given is:

Autoblocked because your IP address has been recently used by "Test1".

The reason given for Test1's block is "testing autoblock message"

• Start of block: 22:55, 27 October 2013
• Expiry of block: 22:55, 28 October 2013
• Intended blockee: 2A01:198:200:15F:0:0:0:2

Shouldn't "intended blockee" be "Test1" in this case?

Change 92254 had a related patch set uploaded by saper:
Don't expose blocked IP address in error message

https://gerrit.wikimedia.org/r/92254

(In reply to comment #21)

• Start of block: 22:55, 27 October 2013
• Expiry of block: 22:55, 28 October 2013
• Intended blockee: 2A01:198:200:15F:0:0:0:2

Shouldn't "intended blockee" be "Test1" in this case?

Filed bug 56227 for this case for discussion.

saper added a comment.Nov 1 2013, 2:57 PM

I think that policy question here is who is responsible for maintaining privacy policy:

(1) To what level should software prevent disclosure of IP addresses of contributors? (I think that removing any possibility to include an IP address in MediaWiki message is too much)

(2) Are sysops responsible for keeping MediaWiki namespace free of features breaching privacy? Just like it is possible to install Google scripts in MediaWiki:Common.js, I think it is ultimate responsibility of sysops to make sure the templates do not use too much information.

According to Jackmcbarn [https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Autoblockedtext&action=edit&section=17 here], even if we change the on-wiki messages on en:, it is possible for users to read the message by using the "uselang" paramter, (or indeed by setting their language preferences).

The required code is:

return array(
     '',
     '',	
     '',
     $context->getRequest()->getIP(),
     '',
     '',
     '',
     '',
     ''
)

Only the IP address should be returned, in theory the autoblocked user knows her own IP address. All the other information is likely to directly identify the blocked user.

(Possibly $0 is required)

As Bawolff has said, I don't think we should change this behavior unless WMF Legal agrees that we need to.

I feel like I'm missing something here - is there any reason *not* to fix this, other than the basic "fixing bugs takes time"? e.g., is there an impact on translations? information that admins will be deprived of? ...?

I'm a little worried that I'm being asked to weigh costs/benefits without having a clear understanding of what the costs are.

Thanks...

The block ID is absolutely necessary for them to be able to ask an admin to lift the block. Given the block ID, the rest of the information (except their own IP address, which as Rich pointed out, they already know anyway) is visible at Special:BlockList.

Ah, I see, thanks for putting all the pieces together for me. I need to chat with Michelle about this but will try to respond soon.

It would need more than current admin powers to investigate an autoblock. Ideally it should be a trusted person only (i.e. someone who has self-identified to the WMF,and is considered trustworthy, as OTRS, checkusers, arbitrators and certain others are).

Rich, with the solution you propose here, it would be completely impossible for anyone to investigate an autoblock, except people who can query directly against private fields in the database.

saper added a comment.Apr 20 2014, 7:39 PM

After reviewing this again I came to conclusion that the problem is not with the MediaWiki code and the parameters it discloses to the user trying to edit;
it is the sample template code that is proposed in the message that is responsible for the problem.

In short,

{{unblock-auto|1=$3|2=<nowiki>$2</nowiki>|3=$1|4=$5}}

should be changed to

{{unblock-auto|1=|2=<nowiki>$2</nowiki>|3=$1|4=$5}}

(provide empty parameter #1 to unlock-auto).

I think that parameter #1 to unblock-auto should just go away.

https://en.wikipedia.org/wiki/Template_talk:Unblock-auto#Remove_.241_parameter

https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Autoblockedtext&diff=605054578&oldid=605053301

I am tending to close this bug here and refer it to enwiki users that have "editinterface" right.

Indeed, that sounds reasonable, though rather than setting parameter 1 to a blank value, it should be removed and the rest pushed down a number. That isn't something to worry about here though; enwiki can handle that.

saper added a comment.Apr 21 2014, 5:48 PM

The template has been updated. I thin enwiki community might want to discuss whether Template:Unblock-auto and friends (Template:Unblock-auto_on_hold, Template:Unblock-auto_reviewed) should accept IP address as $1 parameter. But that should be left to the local discussion.

Closing as RESOLVED/WONTFIX.

INVALID would mean fixing it is outside of power of MediaWiki development, which isn't fully true - in theory we are able to remove the parameter supplied to the template, but for reasons listed above we don't want to.

Change 92254 abandoned by saper:
Don't expose blocked IP address in error message

Reason:
From the bug comments:

After reviewing this again I came to conclusion that the problem is not with the MediaWiki code and the parameters it discloses to the user trying to edit;
it is the sample template code that is proposed in the message that is responsible for the problem.

https://gerrit.wikimedia.org/r/92254

Marcin: I think I'm missing something - if we're able to fix[1] something globally by blanking $1, shouldn't we do that instead of requiring each individual community to fix their templates (guaranteeing that particularly in many smaller communities the problem will remain unresolved?)

[1] I realize it is not a complete fix, but at least makes the problem less likely to happen accidentally.

$1 is the user's own IP address, which they already know anyway. All we did on enwiki was remove one of our customizations that told them they needed to post their IP to get the block removed.

Elvey added a comment.May 23 2014, 2:09 AM

But Jackmcbarn,

https://en.wikipedia.org/wiki/MediaWiki:Autoblocker is:

[[Wikipedia:Autoblock|Autoblocked]] because your IP address was recently used by "[[User:$1|$1]]". The reason given for $1's block is: "$2".

We're not just giving the user their own IP address. We're giving users of that IP address the identity of other users of that IP address. That's a Privacy Policy violation.

I don't think a template fix can or did change that, so for that and other reasons, see: https://meta.wikimedia.org/wiki/Wikimedia_Forum#Is_the_Foundation_serious_about_privacy.3F for further discussion of them, I'm reopening. But feel free to override me.

If that information weren't available, it wouldn't be possible for admins to decide whether or not to lift the autoblock.

Jack: Whatever. We need to stop violating the privacy policy. From the policy:

"we consider at least the following to be “personal information” if it is otherwise nonpublic and can be used to identify you:
at least
(a) your real name ... IP address ....
(c) [your IP address] when associated with your user account
Information available through public logs will not include personal information about you.

We keep IP addresses confidential, except as provided in this Policy.
"

An example and legal analysis of the legal quagmire violating one's privacy policy gets one into:

http://arstechnica.com/tech-policy/2012/12/judge-oks-20-million-privacy-deal-for-facebooks-sponsored-stories/

http://www.lexology.com/library/detail.aspx?g=1f6ea195-aded-4199-8ada-91325aba8d0c

We're giving users of that IP address the identity of other users of that IP address. I think that's a Privacy Policy violation because we don't need to do that in order for it to be possible for admins to decide whether or not to lift an autoblock.

Then what procedure should be followed to unblock a user who is autoblocked?

(In reply to Jackmcbarn from comment #43)

Then what procedure should be followed to unblock a user who is autoblocked?

Autoblock ID is the only really necessary one.

  1. $wgAutoblockExpiry is variable; it would probably not be that hard (though not trivial either) to make MediaWiki silently reduce it temporarily (even to 0 seconds) for a specific block once a dependent autoblock is manually revoked.
  2. Otherwise, to keep it manual: on unblocking, Special:Block could simply offer a checkbox to also unblock the autoblock's parent blocks (or the block's dependent autoblocks), a feature sysops would appreciate because they often forget.
    1. If the block-autoblock connection is shown to the unblocking sysop, well that's only one person. Not strictly necessary anyway, but unblocking sysop probably wants to know.
    2. If both block and autoblock changes are logged, anyone can draw the connection from log timestamps. Do they both need to be logged?

(In reply to Jackmcbarn from comment #30)

is visible at Special:BlockList.

Which IIRC just reuses the same message, hence would automatically be fixed if MediaWiki:Autoblocker was.

I didn't mean "how would an admin be able to hit the unblock button". I meant "how would an admin be able to decide whether or not they should be unblocked".

Elvey added a comment.Jun 4 2014, 4:11 PM

Jack: If the user needed to be blocked for some reason other than the possibly significant connection to the blocked user, they would be blocked for that reason soon enough. The admin would know that the reason for the autoblock had expired.

In other words, an admin don't 'decide'; autoblocks occur automatically, and corresponding autounblocks can occur automatically too.

The admins do have to decide whether or not to grant the user's request to lift the autoblock, and they need this information in order to decide that.

Elvey added a comment.Jun 4 2014, 10:40 PM

Can you flesh that out, with an example (BlockedUser uses IP 10.9.8.7...OtherUser... other user on IP ... admin needs to know the actual IPs of ... to look at because... )?

The IP is the one piece of information he doesn't need. The block ID is needed for lifting the block to be technically possible, and the rest of it (all tied to the block ID) is needed to make the decision.

Elvey added a comment.Jul 4 2014, 6:16 AM

Again, please flesh that out with a (fictitious) example. _Show us_ what else is needed, please; I'm asking for more than just the bald claim that you've made twice now.

I provided blanks for you to fill...:BlockedUser uses IP 10.9.8.7...OtherUser... other user on IP ... admin needs to know the actual IPs of ... to look at because...

I specifically said they don't need the actual IPs.

  1. The text on Autoblocker, according to translatewiki

Autoblocked because your IP address has been recently used by "[[User:$1|$1]]".
The reason given for $1's block is "$2"

"English is the source language and must be changed in the MediaWiki code. Changes here will be lost. Suggest improvements at Support."

For Autoblocker the parameters are

$1 - target username
$2 - reason

both of which should be suppressed.

Therefore the automatic transclusion of this should be removed form the software.

  1. Ideally the message in MediaWiki:Autoblockedtext/en should be something like

Your IP address has been automatically blocked because it was used by another user, who was blocked by an administrator.

The  block expires in approximately $9

You may contact any administrators to discuss the block.

Note that you may not use the "email this user" feature unless you have a valid email address registered in your user preferences and you have not been blocked from using it.

The block ID is #$5. Please include this number in any queries you make.


$5 = block ID
$9 = remaining time for block in the largest greater than unity units, rounded up. E.G. 8 days 7 hours becomes 9 days, 3 hours 45 minutes becomes 4 hours.

Note: Even giving the time in this form leaks information, repeated enquiry will give the exact expiry time, and certainly on smaller wikis this will be unique per block even with a granularity of a day, so perhaps a better solution could be found.

HTH

Hiding $1 and $2 would be totally pointless, since knowing the block ID ($5) allows you to see those anyway.

To be clear, the privacy policy allows disclosure of this sort of information when necessary to operate the site, so this is not a privacy policy violation. That said, if we can figure out how to operate the site without disclosing it, we should do that. It is not clear to me if Rich's proposal does that or not.

I would second Elvey's structuring of the question: it would be helpful both to me and to whoever has to resolve this technically to know what the process is, and exactly what data points are necessary when in the process. And it's really hard to do this right now from the (very extensive) discussion on this bug- might make sense to write up the process/steps as a wiki page somewhere?

"[W]hen necessary to operate the site" - absolutely - and the point is that it is not necessary in this case. (Some of it can be removed trivially, other parts require some software work.)

https://meta.wikimedia.org/wiki/Privacy_policy/Fix_block_messages

Is for building a draft process.

I hope others will pitch in, as, even when I had the power, I was not much of a one for blocking people, so my knowledge of these parts is limited.

Rich: thanks for creating the page, appreciate it. I'll ask James Alexander (who has had this power for a long time, and works closely with me on a variety of things) to take a look at it. Thanks!

I'm not sure what you guys are talking about with having powers. This is a MediaWiki feature, anyone can set up a wiki (or use existing open test wikis) and try it out.

It sounds to me like this issue is inherent in the design of the autoblock system, so I doubt there's any simple solution.

Rich Farmbrough:

  • Why have you made a meta.wikimedia.org page to advocate a MediaWiki change?!
  • I noticed you made a comment there about translatewiki editors and admins. There are many places translatewiki editors can currently cause security issues, e.g. via bug 43646 but also presumably via many other messages.
  • Admins can do that and even worse - e.g. they are (somewhat stupidly) allowed to set JavaScript code run by other users. They could simply add all kinds of tracking code (which has happened) or otherwise malicious code (as a scary example, since highly privileged users typically run admin-set JS anyway, the suppression system and restrictions around CU/userrights might as well not exist) if they wanted. This is a very widely known and very obvious issue.
  • You realise that simply removing parameters from the message (your proposed code for which has a pattern of syntax errors, and even removes the name of the message to be used, which is required for the code to function) doesn't change the fact that knowing a block ID allows you to look up the rest of the information (obviously your own IP is available to the blocked users - i.e. the intended blockee and everyone else on the same IP - anyway)?

(In reply to Alex Monk from comment #58)

obviously your own IP is available to the blocked
users - i.e. the intended blockee and everyone else on the same IP - anyway

"obviously the IP*", I meant to say.

Rich, I've read your proposal. It seems that what you're basically requesting is to make it so only CheckUsers (or members of a new group that would essentially be CheckUser-lite) can review requests to lift autoblocks. Am I correct?

Also, keep in mind that it isn't enough to have enough information to perform the technical action of lifting the autoblock. You also need enough information to decide whether or not the autoblock should be lifted.

@Alex: I have pointed out a violation of WMF's privacy policy, with possibly life threatening implications. Somewhat naively I expected that this would be prioritised as an urgent fix. Expecting me to set up my own test bed to evaluate my proposed fixes (which are partly other peoples proposals, of course) is like expecting me to dig up the road when the water company has a mains leak.

I made the page at Meta, because this is a WMF issue, it affects more than the software, it affects process, it affects self-identification with the WMF and it affects the configuring of WMF projects, including creating new translations. Louis who asked for the page seems perfectly happy to have it there.

Generally I prefer not to tangentially mention other security problems, per WP:BEANS.

Yes I was sort of aware that there should be a $0, and meant to fix that. It's a wiki, you could have fixed it. :)

Of course knowing the block ID still allows you to see the block information, if you know how to access the block log. However this is better than being told "The user was Fred Bloggs".

The later part of the proposal suggests reconfiguring the Block Log interface so that the Block ID number is only visible to administrative users who will be using the log to consider removing autoblocks.

@Jackmcbarn

No, I suggested that it is a reasonable compromise for Administrators to review requests to lift autoblock.

Technically this is a breach of the Privacy Policy, since Admins aren't identified to the Foundation in general. Pragmatically the chance of this being exploited seems small to me, though I may be wrong.

The information relating to the block that is not in the block log currently has to be found by examining talk pages, contacting blocking admins, looking at contribs etc. I don't see how these proposals change that for better or worse.

(In reply to Rich Farmbrough from comment #62)

@Alex: I have pointed out a violation of WMF's privacy policy, with possibly
life threatening implications. Somewhat naively I expected that this would
be prioritised as an urgent fix. Expecting me to set up my own test bed to
evaluate my proposed fixes (which are partly other peoples proposals, of
course) is like expecting me to dig up the road when the water company has a
mains leak.

Luis already pointed out that it's not a privacy policy violation. Also, please explain how it has life-threatening implications.

Yes I was sort of aware that there should be a $0, and meant to fix that.
It's a wiki, you could have fixed it. :)

What?

Of course knowing the block ID still allows you to see the block
information, if you know how to access the block log. However this is
better than being told "The user was Fred Bloggs".
The later part of the proposal suggests reconfiguring the Block Log
interface so that the Block ID number is only visible to administrative
users who will be using the log to consider removing autoblocks.

I still don't see a clear threat model to justify making autoblocks even less transparent.

@Jackmcbarn
No, I suggested that it is a reasonable compromise for Administrators to
review requests to lift autoblock.
Technically this is a breach of the Privacy Policy, since Admins aren't
identified to the Foundation in general. Pragmatically the chance of this
being exploited seems small to me, though I may be wrong.

If it's technically a breach, then we can't "fix" this by doing this either.

The information relating to the block that is not in the block log currently
has to be found by examining talk pages, contacting blocking admins, looking
at contribs etc. I don't see how these proposals change that for better or
worse.

Because it takes it from being "you can see it, but you have to dig for it" to "you can't see it".

@Rich_Farmbrough: Could you answer @Jackmcbarn's questions in the last comment?

@Rich_Farmbrough: Could you answer @Jackmcbarn's questions in the last comment?

@Aklapper - best to ping me via my en:wp talk page

Jack didn't really ask any questions, so I have simply responded point for point, though the substance of all the replies should already be evident from the discussions.

  1. Jackmcbarn "asked":

Luis already pointed out that it's not a privacy policy violation.

Luis had said

" the privacy policy allows disclosure of this sort of information when necessary to operate the site,"

to which I replied :

"[W]hen necessary to operate the site" - absolutely - and the point is that it is not necessary in this case. (Some of it can be removed trivially, other parts require some software work.)
https://meta.wikimedia.org/wiki/Privacy_policy/Fix_block_messages
Is for building a draft process.
I hope others will pitch in, as, even when I had the power, I was not much of a one for blocking people, so my knowledge of these parts is limited.

  1. Jackmcbarn "asked":

Also, please explain how it has life-threatening implications.

Allowing someone to be identified with their Wikipedia edits, can have major implications. For example if you are revealed to be gay in many states your life is in danger. Or if you are revealed to be Jewish or an apostate or to have links with South Korea, or whatever the local version of "witch" is. Examples were given in the original meta discussion linked to in the bug: https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=5729964#Privacy_violation

  1. Jackmcbarn "asked" apropos of "Yes I was sort of aware that there should be a $0, and meant to fix that.

It's a wiki, you could have fixed it. :)":

What?

I covered the possibility of $0 being required in my comment of Apr 16 2014, 4:59 AM. As far as the proposed process for resolving this issue at https://meta.wikimedia.org/wiki/Privacy_policy/Fix_block_messages which I believe Jack was referring to, it (meta) is a wiki and Jack can, and indeed has, edited that page to improve it.

  1. Jackmcbarn "asked" :

I still don't see a clear threat model to justify making autoblocks even less transparent.

I hope the above examples and the example in https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=5729964#Privacy_violation make this clear.

  1. Jackmcbarn "asked":

If it's technically a breach, then we can't "fix" this by doing this either.

It's true that we are making information available to administrators (proposal) instead of the world (currently). And it's true that administrators are not necessarily self-identified to the Foundation.
However pragmatically.
a) Administrators are approximately as trustworthy as self-identified apparatchiks
b) We have reduced that actual risk from a first order smallness to a second order smallness (metaphorically if you are a real mathematician)
c) We are covered, potentially, by Luis's "when necessary to operate the site"
d) We have the option to follow the same process with a tighter requirement on those allowed to see the association of block-log ids with accounts, either by using an existing user group (check-users has been suggested) or by creating a new group (self-identified admins, for example - or as Jack says "checkuser-lite").

  1. Jackmcbarn "asked":

Because it takes it from being "you can see it, but you have to dig for it" to "you can't see it".

This is not correct. the proposal does not affect the visibility of standard information around the blocking of a user that is recorded in their block log, on talk pages, noticeboards, etc. It only affects the access to information that links the IP that is autoblocked to the user who's blocking caused the autoblock.

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptApr 18 2016, 5:54 PM
ZhouZ moved this task from Backlog to Assigned on the WMF-Legal board.Apr 18 2016, 7:04 PM
ZhouZ added a subscriber: ZhouZ.
jayvdb added a subscriber: jayvdb.Apr 19 2016, 3:43 AM

What we need is a solution which will allow an autoblocked user to give enough information so that an admin can see which account caused the autoblock, without allowing other people to see it. This information could certainly be the autoblock number, if it was possible to keep the autoblock number's connection to the account visible to admins but not to everyone; unfortunateely, as the software is now, it's not possible.