Image URLs containing "/ad/" trigger some ad blocking filters
Closed, DeclinedPublic

Description

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/".


Version: unspecified
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz5402.
Ilmari_Karonen created this task.Via LegacyMar 30 2006, 8:23 PM
brion added a comment.Via ConduitMar 30 2006, 8:36 PM

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.

bzimport added a comment.Via ConduitApr 23 2006, 3:34 PM

dbenbenn wrote:

[[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.

bzimport added a comment.Via ConduitApr 23 2006, 3:47 PM

brianna.laugher wrote:

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.

brion added a comment.Via ConduitApr 23 2006, 8:09 PM

PLEASE REPORT THE BUG TO THE MAINTAINER OF THE BROKEN AD
BLOCKER SOFTWARE.

bzimport added a comment.Via ConduitApr 23 2006, 8:15 PM

mrbillcollector wrote:

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
bzimport added a comment.Via ConduitMay 6 2006, 6:00 AM

dbenbenn wrote:

(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.)

Hendrik_Brummermann added a comment.Via ConduitMay 6 2006, 6:43 AM

Five years ago all common ad-blockers had an exception for a/ad/. I strongly
recomment reporting this problem to theses no new programms.

bzimport added a comment.Via ConduitMay 6 2006, 3:20 PM

robchur wrote:

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.

bzimport added a comment.Via ConduitMay 6 2006, 4:16 PM

dbenbenn wrote:

(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.

Hendrik_Brummermann added a comment.Via ConduitMay 6 2006, 4:37 PM

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.

brion added a comment.Via ConduitMay 6 2006, 7:08 PM

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.

Nikerabbit added a comment.Via ConduitMay 19 2006, 11:37 AM
  • Bug 6020 has been marked as a duplicate of this bug. ***
Dragons_flight added a comment.Via ConduitJun 24 2006, 3:42 PM

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.

Raymond added a comment.Via ConduitOct 25 2007, 6:40 PM
  • Bug 11765 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitOct 25 2007, 10:14 PM

ssanbeg wrote:

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.

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:58 AM
Gilles moved this task to Closed on the Multimedia workboard.

Add Comment