Last modified: 2011-03-13 18:05:19 UTC
A number of users with some form of adblocking software installed have reported that they are unable to view images such as http://upload.wikimedia.org/wikipedia/en/a/ad/OL0026.jpg whose URL contains the string "/ad/". As these directories are chosen by random hashing, the end result is that such users are unable to view a seemingly random set of about 0.1% of our images. While this is certainly not our fault, such occurrences are common enough (and confusing enough to the users experiencing them) that a workaround at our end would be desirable. A simple solution would be to change the image hashing system to remove the redundant first letter from the subdirectory name, so that the URL would contain "/x/y/" instead of the current "/x/xy/".
This is a known bug with those broken blocking programs. We're keeping it in mind for proposed changes to the image infrastructure but won't change purely for that reason.
[[Adblock]], of course, is the most popular extension for Firefox, and is one of "those broken blocking programs". (I.e., a user of Adblock is not unlikely to put "*/ad/*" in their filter. Adblock itself is not at all broken.) Another way to implement this fix is to just change the hashing algorithm so that when it would normally return /a/ad/, it returns /a/ae/. Then move images in /a/ad/ to /a/ae/. That's not as elegant as Ilmari's idea, but the benefit is that most images don't change URL under that scheme.
I really wish there was a chance this might be changed. A few times now I have been involved with trying to help users figure out why they can't see some vital image while all others seem fine. After going through the usual suspects we are left to ponder... until I happen to remember this stupid problem. Undoubtedly this problem happens for many other users who /don't/ contact us, and undoubtedly many of the admins they try to contact about this have no idea about it, because they don't have the problem and it's only one in every 200 (or whatever). Basically it would be great if we could avoid randomly refusing access to users just by disallowing one subdirectory.
PLEASE REPORT THE BUG TO THE MAINTAINER OF THE BROKEN AD BLOCKER SOFTWARE.
Brion Vibber take a hike. And it is not Adblock that is broken. It is the most popular filters for it that is cause it to be broken. This is called FilterSet.G available at http://www.pierceive.com/ Since just using that has a nice set of regex rules that blocks most users it is what is causing it. Maybe if you wanted this fixed contact the owner of that and tell him to fix it in his next update. Cheers, - Vikram Mohan
(In reply to comment #4) > PLEASE REPORT THE BUG TO THE MAINTAINER OF THE BROKEN AD > BLOCKER SOFTWARE. Brion, please don't yell, and please try to understand the bug that's being reported. [[Adblock]] is not broken, the problem is simply that many people have told their ad blocking programs to filter out /ad/. (For what it's worth, I use FilterSet.G and it doesn't appear to block /ad/.) The Commons Picture of the Day for June 3 will not display for many people unless we fix this simple bug. Is there any reason why it's necessary to keep that one directory, /ad/ ? Let's just fix the hashing algorithm, move that one directory, and get on with our lives. (Or implement Ilmari's earlier suggestion, which is more elegant but would require a little more work.)
Five years ago all common ad-blockers had an exception for a/ad/. I strongly recomment reporting this problem to theses no new programms.
For the *last time*. This is not a bug with our software. This is an issue with those users who use ad-blocking software and don't follow our workarounds for making certain files available. It's no different than a user using, say, lynx, complaining that JavaScript-based preferences aren't working or that images can't be viewed. We could implement workarounds, indeed. But that *is* a hackish solution to a problem we didn't cause in the first place, and a tech. more senior than I has already (correctly so, in my view) vetoed it.
(In reply to comment #8) > For the *last time*. Oh good. I'm glad you won't be reiterating this misconception again. > This is not a bug with our software. This is an issue with those users who use > ad-blocking software and don't follow our workarounds for making certain files > available. Yes, it's possible to lay the blame on the users. That's true of many bugs. But it isn't helpful. This issue harms users of MediaWiki, and in that sense it is a bug. We can continue laying blame on others, or we can pragmatically accept that we can't possibly fix all routers, firewalls, and ad blocker filter sets in the world. > It's no different than a user using, say, lynx, complaining that > JavaScript-based preferences aren't working or that images can't be viewed. Yes, it is. The difference is that there's an easy solution that can be implemented in MediaWiki. (If we could make a tiny change to MediaWiki that would allow Javascript to work in Lynx, would you veto that, too, by blaming Lynx?) > We could implement workarounds, indeed. But that *is* a hackish solution to a > problem we didn't cause in the first place, and a tech. more senior than I has > already (correctly so, in my view) vetoed it. Again, it's easy to blame users, but that doesn't help anyone. Can you provide any technical argument why it's impossible or undesirable to fix this genuine problem? If not, it's simply obstructive to refuse to allow us to fix it. MediaWiki developers could learn something about the open source model from Wikipedia.
> We can continue laying blame on others, or we can pragmatically > accept that we can't possibly fix all routers, firewalls, and ad blocker filter > sets in the world. Again: Almost all add blockers have an exception for "a/ad". Those few new one that don't have it, should be changed. Please open a feature-request in their bug-tracker.
David, we're not blaming users. We're blaming the poorly configured software hacks known as "ad-blocking software". Please note that sooner or later we *will* change how uploads are arranged in the filesystem and what their URLs look like. And for that future change, we will keep this poorly configured software in mind. But we're not going to change the existing system *just* for this. Period. So please stop wasting your time on this bug. Thanks.
*** Bug 6020 has been marked as a duplicate of this bug. ***
The developers apparently don't want to do anything about this on the online software, but I have patched my personal copy of the Wiki software to move everything in /ad/ to /ae/. If anyone wants help doing this with their own copy, I'd be willing to help.
*** Bug 11765 has been marked as a duplicate of this bug. ***
Just my 2 cents: From what I've seen, the developers generally refuse to hack around problems in other software, or to screw over search engines by arbitrarily moving large numbers of URLs. Since this fix asks for both, there wouldn't be much hope for it.
