Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated filenames trigger AdBlock blocking #9

Open
elescondite opened this issue Apr 2, 2014 · 4 comments
Open

Generated filenames trigger AdBlock blocking #9

elescondite opened this issue Apr 2, 2014 · 4 comments

Comments

@elescondite
Copy link

After spending hours wondering why only some images on a page were rendering, I discovered that AdBlock was blocking them.

It appears that the generated thumbnail filenames trigger AdBlock's scanner in some cases as they appear similar to typical banner ad filenames (with dimensions).

These 2 get blocked for example:

  • Ludlow_Group_Platinum_Marketing_Effectiveness_Award_For_GKD_Advertising_Campaign_2.thumb_zoomcrop_w150h150q85.jpg
  • 4specs-timber-rev.thumb_zoomcrop_w150h150q85.jpg

Off the top of my head, I am thinking that maybe we can hash the preset, dimensions and quality in some way that will still allow us to detect if a thumbnail has already been generated. For example:

4specs-timber-rev.thumb_zoomcrop_dzE1MGgxNTBxODU=.jpg

Just a simple base64 encode of "w150h150q85". Now it looks more like some cache-busting scheme rather than a 150x150 banner ad.

Thoughts?

@rantecki
Copy link
Contributor

rantecki commented Apr 2, 2014

That's interesting. I haven't run into that problem myself with AdBlock.

The hash strategy seems reasonable. I'm just trying to think of any reason why it would be bad for the image parameters to not be human-readable...

In any case I guess the hashing could be optional?

@elescondite
Copy link
Author

Drove me crazy for a while ;-) All legit images on a legit site and yet a few just disappeared. Of course, the site went live two hours ago :(

Another idea would be to pass another parameter with a user-defined string:

<%= @getThumbnail(featured.url, "zoomcrop", {w: 150, h: 150, q: 85, name: 'my-readable-name'})

Then it's up to the developer to manage their own unique strings for each combination. If done in docpad.coffee presets, the chances of messing up would be limited.

@rantecki
Copy link
Contributor

rantecki commented Apr 2, 2014

Well it could also just use the preset name if it's available. I think I was originally planning to do that, but then things got complicated. E.g. It's possible to specify multiple preset names for a single thumbnail that overrides parameters in the order specified (e.g. "small", "low-quality"). It's also possible to specify a preset name, and then override individual parameters (e.g. "small", {q: 85}). My head is hurting already...

So if a name is specified directly in the parameters to getThumbnail(), using that is a no-brainer. In the cases where it's specified in presets (or we just use the preset name), things can get messy.

@elescondite
Copy link
Author

I would be worried about clobbering (even accidentally) other combinations if we just use a preset name. Callback that is passed preset, h, w, q etc. and returns a name? Let the developer decide. I vote we sleep on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants