Last modified: 2011-03-13 18:05:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7402, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5402 - Image URLs containing "/ad/" trigger some ad blocking filters
Image URLs containing "/ad/" trigger some ad blocking filters
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Lowest normal with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6020 11765 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-30 20:23 UTC by Ilmari Karonen
Modified: 2011-03-13 18:05 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ilmari Karonen 2006-03-30 20:23:40 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/".
Comment 1 Brion Vibber 2006-03-30 20:36:16 UTC
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.
Comment 2 David Benbennick 2006-04-23 15:34:49 UTC
[[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.
Comment 3 brianna.laugher 2006-04-23 15:47:59 UTC
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.
Comment 4 Brion Vibber 2006-04-23 20:09:44 UTC
PLEASE REPORT THE BUG TO THE MAINTAINER OF THE BROKEN AD 
BLOCKER SOFTWARE.
Comment 5 Vikram Mohan 2006-04-23 20:15:05 UTC
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
Comment 6 David Benbennick 2006-05-06 06:00:17 UTC
(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.)
Comment 7 Hendrik Brummermann 2006-05-06 06:43:08 UTC
Five years ago all common ad-blockers had an exception for a/ad/. I strongly
recomment reporting this problem to theses no new programms.
Comment 8 Rob Church 2006-05-06 15:20:16 UTC
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.
Comment 9 David Benbennick 2006-05-06 16:16:48 UTC
(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.
Comment 10 Hendrik Brummermann 2006-05-06 16:37:09 UTC
> 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.
Comment 11 Brion Vibber 2006-05-06 19:08:22 UTC
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.
Comment 12 Niklas Laxström 2006-05-19 11:37:34 UTC
*** Bug 6020 has been marked as a duplicate of this bug. ***
Comment 13 Robert Rohde 2006-06-24 15:42:36 UTC
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.
Comment 14 Raimond Spekking 2007-10-25 18:40:32 UTC
*** Bug 11765 has been marked as a duplicate of this bug. ***
Comment 15 Steve Sanbeg 2007-10-25 22:14:27 UTC
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.



Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links