Last modified: 2013-07-26 23:31:09 UTC
If 127.0.0.1 is autoblocked, [[Special:Contributions/127.0.0.1]] shows a link "change block" instead of "block", though there's no block log shown. However imagine there's only one autoblock listed in Special:BlockList, or a user is newly blocked with autoblock enabled, a malicious sysop may check contribution pages of all IP addresses for this link text change from "block" to "change block", and associate this IP with the user triggering this autoblock.
Imho is a harmless feature rather then a bug
(In reply to comment #1) > Imho is a harmless feature rather then a bug Really? I thought this information was supposed to be hidden.
(In reply to comment #1) > Imho is a harmless feature rather then a bug I agree. And only admins will see that, so don't see why this would be a problem.
Admins cannot see the details of autoblocks.
Besides, that IP *is* blocked (autoblocked or blocked by himself, but the IP is blocked), so the software should mention that at least imho. I don't see a bug or a problem, thus shouldn't be "solved" either.
(In reply to comment #4) > Admins cannot see the details of autoblocks. No, not the details, but they can see that an IP is blocked. Nothing more and nothing less.
It's a bug, and not very difficult to fix.
(In reply to comment #7) > It's a bug, and not very difficult to fix. This fix will prevent sysops from removing autoblocks on IPs?
No, the users should not be able to figure out the actual IP address behind the block.
But they won't be able to figure it out unless they have reasons to suspect that IP address is the one that was autoblocked in the first place. That is, you need to know what IP address to check first, and even then you can't actually be certain that it is the one under a particular autoblock unless you can observe the contribs page of that particular IP address both immediately before and immediately after the autoblock triggered. It's not really a problem if the software reveals little more than what you already know or have a good reason to suspect. The scenario described - an admin somehow going over the contribution pages of all 4 billion IPv4 addresses (not to mention the 2^128 IPv6 ones) to find the one that is under an autoblock - which also must be the only autoblock active at the time - is, to put it mildly, extremely unlikely.
(In reply to comment #10) > But they won't be able to figure it out unless they have reasons to suspect > that IP address is the one that was autoblocked in the first place. That is, > you need to know what IP address to check first, and even then you can't > actually be certain that it is the one under a particular autoblock unless > you > can observe the contribs page of that particular IP address both immediately > before and immediately after the autoblock triggered. It's not really a > problem > if the software reveals little more than what you already know or have a good > reason to suspect. > > The scenario described - an admin somehow going over the contribution pages > of > all 4 billion IPv4 addresses (not to mention the 2^128 IPv6 ones) to find the > one that is under an autoblock - which also must be the only autoblock active > at the time - is, to put it mildly, extremely unlikely. Autoblock <-> IP address associations is private data. Only checkusers should be to get any sort of information in this direction. The fact that it is somewhat hard to exploit is irrelevant. (And really, if you have some suspicion of where the user lives, you would have to go through significantly less than 4 billion IP addresses. Even with 4 billion IPv4 addresses, bots don't exactly get tired of looking through pages) This bug is a potential violation of Wikimedia's privacy policy and should be fixed
And it doesn't have to be the only autoblock. All you need to do is crawl the pages for a range of ips you guess the user may be in making note of the link text for each page by bot. Block the user with autoblock on. Then re-run the bot. For any link text the link text changed that ip is the user's ip.
There are dozens of autoblocks, bilions of IPs, most of IPs are dynamic, both leases and autoblocks are short , seriously we shouldn't get paranoid. Anyway it seems you want to change the "change block/block" feature? Well, do it, but sysop MUST have the possibility to unblock an IP address if an user says "hey my IP address is caught by an autoblock", privacy paranoia is harmless unless it destroys useful functionalities.
People, come on! I agree with Vito here. I mean, when an IP is blocked, an admin should know whether it is blocked or not if someone asks and without this feature you'll never know it. Autoblocks don't contain IP addresses of course and it's really *not* a bug. A simple "change block" never tells you why that IP was autoblocked and which user it used. Also per Timotheus Canens.
Hm, not really. Special:BlockList gets it right, Contributions and DeletedContributions get it wrong. The logic here should be the same and autoblocks are visible under the block number (also as such are reported to the blocked user). I had to remove an autoblock recently due to complaints of the shared IP users recently and knowing the actual IP address was not necessary at all to do this. And CheckUser was not required, of course - only block ID.
But when an IP address is blocked, the link on Special:Contributions should be changed from "block" to "change block", like how it is right now. The IP *is* blocked, no matter when it's directly or indirectly via an autoblock. So the software should mention it and nothing should be changed.
(In reply to comment #15) > Hm, not really. Special:BlockList gets it right, Contributions and > DeletedContributions get it wrong. The logic here should be the same and > autoblocks are visible under the block number (also as such are reported to > the > blocked user). > > I had to remove an autoblock recently due to complaints of the shared IP > users > recently and knowing the actual IP address was not necessary at all to do > this. > And CheckUser was not required, of course - only block ID. Note that sometimes block appeal is done by editing talk page. If the behaviour is changed, how would admin be able to tell if it is really blocked? Should one 'try to unblock it'? Asking for autoblock ID on the talk page also seem like a bad idea. Though it seems like a flaw in the current system as well.
(In reply to comment #17) > (In reply to comment #15) > > Hm, not really. Special:BlockList gets it right, Contributions and > > DeletedContributions get it wrong. The logic here should be the same and > > autoblocks are visible under the block number (also as such are reported to > > the > > blocked user). > > > > I had to remove an autoblock recently due to complaints of the shared IP > > users > > recently and knowing the actual IP address was not necessary at all to do > > this. > > And CheckUser was not required, of course - only block ID. > > Note that sometimes block appeal is done by editing talk page. If the > behaviour > is changed, how would admin be able to tell if it is really blocked? Should > one > 'try to unblock it'? > If you really think this is a reason to keep this behavior, I would say its too implicit to identify an autoblock in this way. > Asking for autoblock ID on the talk page also seem like a bad idea. > > Though it seems like a flaw in the current system as well.
Change 73923 had a related patch set uploaded by Legoktm: Prevent Special:Contributions from indicating that an IP address is autoblocked https://gerrit.wikimedia.org/r/73923
Change 73923 merged by jenkins-bot: Prevent Special:Contributions from indicating that an IP address is autoblocked https://gerrit.wikimedia.org/r/73923
Eh, why exactly is this done? I thought there wasn't consensus to do so...
Sorry if I merged prematurely. Did not realize there was an argument going on here. But if my understanding is correct, both Special:BlockList and Special:Unblock pretend as if autoblocks don't exist. In the former case, autoblocks aren't listed unless you specific the block ID directly, and in the latter case, the code even has a comment that says "don't show any distinction between unblocked IPs and autoblocked IPs", so I don't see why Special:Contributions should have different behavior.
(In reply to comment #22) > Sorry if I merged prematurely. Did not realize there was an argument going on > here. But if my understanding is correct, both Special:BlockList and > Special:Unblock pretend as if autoblocks don't exist. In the former case, > autoblocks aren't listed unless you specific the block ID directly, and in > the > latter case, the code even has a comment that says "don't show any > distinction > between unblocked IPs and autoblocked IPs", so I don't see why > Special:Contributions should have different behavior. Agreed. We don't use consensus to determine whether or not to violate our own privacy policy. This was a breach, and as Tyler points out, an inconsistent one at that.
(In reply to comment #23) > (In reply to comment #22) > > Sorry if I merged prematurely. Did not realize there was an argument going on > > here. But if my understanding is correct, both Special:BlockList and > > Special:Unblock pretend as if autoblocks don't exist. In the former case, > > autoblocks aren't listed unless you specific the block ID directly, and in > > the > > latter case, the code even has a comment that says "don't show any > > distinction > > between unblocked IPs and autoblocked IPs", so I don't see why > > Special:Contributions should have different behavior. > > Agreed. We don't use consensus to determine whether or not to violate our own > privacy policy. This was a breach, and as Tyler points out, an inconsistent > one > at that. Ofc, we cannot use consensus since it would be quite hard to find more people believing an harmless and useful feature breaks privacy policy
(In reply to comment #24) > Ofc, we cannot use consensus since it would be quite hard to find more people > believing an harmless and useful feature breaks privacy policy Like I said before, other special pages *already have this behavior*, so I don't see how this could be considered a "useful" feature. Furthermore, privacy aside, the fact that this behavior is different from the expected is alone a reason to consider it a bug.
One should consider removing *that anyone can edit* from Wikipedia, Commons and other Wikimedia projects and replace it with *that only logged-in users can edit without an extemely hassle*, though this one was just a small step in this direction, there was enough done towards this status in the past, including difficult captchas (not yet fixed), community decisisions and so on.
Rainer: Feel free to use https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum for high-level discussions.
(In reply to comment #26) > One should consider removing *that anyone can edit* from Wikipedia, Commons > and > other Wikimedia projects and replace it with *that only logged-in users can > edit without an extemely hassle*, though this one was just a small step in > this > direction, there was enough done towards this status in the past, including > difficult captchas (not yet fixed), community decisisions and so on. How is this related to the original bug?
(In reply to comment #28) > How is this related to the original bug? From what I read, admins are now unable to unblock autoblocked IP users if they just know their IP address.
(In reply to comment #29) > (In reply to comment #28) > > How is this related to the original bug? > From what I read, admins are now unable to unblock autoblocked IP users if > they > just know their IP address. See comment 15, comment 22, and comment 25.
(In reply to comment #29) > (In reply to comment #28) > > How is this related to the original bug? > From what I read, admins are now unable to unblock autoblocked IP users if > they > just know their IP address. If admins already know their IP addresses, can't they simply block that directly?
(In reply to comment #30) > See comment 15, comment 22, and comment 25. Yes, you have to ask the IP for the Block-ID. We have languages at Commons, I even didn't know that they exist before. But if you want to volunteer with translations to them, feel free to join. > If admins already know their IP addresses, can't they simply block that directly? I thought I was talking about the removal of an auto-block? Did I get something wrong? Thx.
Just to be clear, if you look at the patch, zero code was changed in SpecialBlock and SpecialUnblock. No functionality concerning blocking and unblocking was changed. All that was changed is that the links on SpecialContributions were made to be consistent with the behavior of SpecialBlockList.
*** Bug 31893 has been marked as a duplicate of this bug. ***
Will the blocked IP still see that they are blocked? How to find out whether an IP used by a bot is auto-blocked?
(In reply to comment #35) > Will the blocked IP still see that they are blocked? Yes, nothing changes on that end. > How to find out whether an IP used by a bot is auto-blocked? Using the normal block message? I'm not sure what you mean. In tl;dr form, the only thing that changed is that on Special:Contributions/ip address, in the user links ("For 127.0.0.1 (talk | block | block log | uploads | logs | deleted user contributions | abuse log)"), if the IP address was autoblocked, it would have shown "... | change block | unblock | ..." Now it will show "... | block| ..." ONLY if the block is an autoblock.
>> How to find out whether an IP used by a bot is auto-blocked? >Using the normal block message? I'm not sure what you mean. I was thinking about bots who's maintainers are not responsive any more. We have a couple of them running at Commons. The "normal block message" is only shown to the user who is affected by the block, correct?
(In reply to comment #37) > >> How to find out whether an IP used by a bot is auto-blocked? > >Using the normal block message? I'm not sure what you mean. > I was thinking about bots who's maintainers are not responsive any more. We > have a couple of them running at Commons. The "normal block message" is only > shown to the user who is affected by the block, correct? As far as I am aware no one can find out whether an IP address is blocked via an autoblock anymore if you don't have the block ID, which is very bad imho. We can only find out by performing a CU on people and I would that is way more of a breach of the privacy policy then this ever was. You only saw that an IP was blocked, not *when* it was blocked, *by who*, *why* or *who else* used that IP. As said, you can't find out without knowing the block ID. You could of course try to unblock it, but if you don't want it to unblocked I don't think that's a good idea. I saw that some people said that it wasn't consistent; that it wasn't mentioned on the block log or the block list (only the block ID of autoblocked IPs are mentioned there). Of course they aren't mentioned there. If they would, you could easily see which IP matches which user. With this tiny "bug" (which I wouldn't call a bug) you only saw that an IP was blocked, but only if you knew the IP. Otherwise it was impossible to find a 'match'. Anyway, I think this should be reversed - it helped us with our work and it was in no way a breach of the privacy policy. One more thing I would like to say: all people who opposed here are very active users. It seemed to me that you would listen to them; after all we are the ones who should work with all tools. Talk to us and communicate. And not just implement a change. That would be nice.
>it helped us with our work and it was in no >way a breach of the privacy policy I seriously do not understand this line argument. Being able to map usernames to IP addresses is not generally considered ok. Well it may seem to you that this was not possible before this change, a motivated attacker would be able to do it. Additionally, MediaWiki is not just used by Wikimedia. Its generally understood that the software is designed in such a way to not reveal IP addresses of logged in users. -------------- If this change is really causing hardship, the way forward would be to create an extension to reveal this information, and gain some sort of consensus on what sort of users should have access to the information.
This has been said multiple, multiple times already, but the functionality of Special:Block, Special:Unblock, Special:BlockList, etc. has *not* been changed whatsoever. Let me repeat: **not been changed whatsoever** If you couldn't find autoblocks before on the block page, you still can't find them. If autoblocks weren't listed before on the block list page, they're still not listed. Literally the only thing that has changed is that the words "change block" have been changed to just "block" on Special:Contributions. Note that not even the link has changed. Both cases still bring you to Special:Block; only the message that was used was changed.
If we checkuser every vandal we find, it may be helpful somehow, but that wouldn't be allowed by our policies as we can't check every vandal. The fact that this bug is helpful doesn't make it allowed by our policies. It helps to relate IP with user and, worse, for users who are not identified to foundation. I was once able to see the IP of an user who had never given reasons to be checked and while I was not a checkuser. Autoblock removals can still be done by using the block ID, that can be provided by a blocked user. I have already removed lots of autoblocks and I never used the IP for that.
