Last modified: 2014-09-12 22:25:06 UTC
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.
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.
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.
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§ion=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.
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.
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.
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. # $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. # 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. #* 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. #* 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".
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.
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.
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. 2. 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".
