Support for data:image

Everything about using Adblock Plus on Mozilla Firefox, Thunderbird and SeaMonkey
p2u
Posts: 39
Joined: Fri Feb 20, 2009 10:43 am

Re: Support for data:image

Post by p2u »

vasa1 wrote:Paul, when you've loaded news.google.com, what do you see with View Page Source with and without using your method?
As far as I can tell, they look absolutely identical (I saved them as separate documents to compare them; only did a search around the "data:image" stuff). The size is the same: 360KB.

I also looked in the Error Console.
When the block rule is on, I get this type of warnings:

Code: Select all

Warning: Unknown property 'zoom'.  Declaration dropped.
Source File: http://news.google.com/news?cf=all&ned=us&edchanged=1&ict=lbe_ru_ru
Line: 23
When ABP is disabled, I get this type of errors [HttpFox can't catch what's happening, likely because of the huge links that are now requested by the browser]:

Code: Select all

Error: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: file:///C:/Users/---/AppData/Roaming/Mozilla/Firefox/Profiles/uwfsb74b.default/extensions/%7B4093c4de-454a-4329-8aff-c6b0b123c386%7D/components/HttpFoxService.js :: anonymous :: line 1741"  data: no]
Source File: file:///C:/Users/---/AppData/Roaming/Mozilla/Firefox/Profiles/uwfsb74b.default/extensions/%7B4093c4de-454a-4329-8aff-c6b0b123c386%7D/components/HttpFoxService.js
Line: 1741
NoScript gives this kind of messages:

Code: Select all

[NoScript] Blocking refresh on unfocused tab, http://news.google.com/news?cf=all&ned=us&edchanged=1&ict=lbe_ru_ru->http://news.google.com/news?cf=all&ned=us&edchanged=1&ict=lbe_ru_ru
Paul
p2u
Posts: 39
Joined: Fri Feb 20, 2009 10:43 am

Re: Support for data:image

Post by p2u »

Adblock Plus Fan wrote:The positive thing about base 64 encoded images is that there are no privacy issues in any of these examples
I'm not so sure about that. I've had this weird experience, which gives me the feeling this implementation is used by Google for "device fingerprinting"; something like an evercookie. I'll try to explain it:
With one and the same User Agent under the same conditions (Adblock DISabled on that page), I can't reproduce the trick to show the pictures in Cache Viewer, even when the cache is cleaned out and notwithstanding the fact that my IP is dynamic. But when I either disable NoScript (protects somehow against device fingerprinting) or when I change the HTTP headers (User Agent and system info), the images from *.ggpht.com appear again in cache.

Paul
Wladimir Palant

Re: Support for data:image

Post by Wladimir Palant »

@Michael: What kind of support do you expect for data: URLs? They are not associated with downloads, so nothing to be blocked there. The URLs themselves have no semantic meaning - it is the raw image data, no way to distinguish images in a meaningful way. On the previous occasions I said that in the cases where data: images are offending hiding them is good enough as a solution. From what I can tell, in this scenario a blocking mechanism would offer no advantages over hiding whatsoever. Am I missing something?
User avatar
Adblock Plus Fan
Posts: 1255
Joined: Sat Feb 24, 2007 11:08 am

Re: Support for data:image

Post by Adblock Plus Fan »

@Wladimir
The familiar website Michael is talking about uses some tricks that makes it hard for EHH to target the images directly, and a few randomization tricks too. These tricks forces the EHH user to make very risky rules.

Agreeing with Michael, I actually also want the data:image whitelist removed by default, as it allows 100% reliable ways to target the individual images. It also allows filters like ;base64,$domain=familiar.website
Wladimir Palant

Re: Support for data:image

Post by Wladimir Palant »

Doesn't this have the same effect?

Code: Select all

familiar.website##img[src^="data:image/png;base64,"]
User avatar
Adblock Plus Fan
Posts: 1255
Joined: Sat Feb 24, 2007 11:08 am

Re: Support for data:image

Post by Adblock Plus Fan »

No effect, the image is inside <style> tag.
vasa1
Posts: 76
Joined: Wed Apr 14, 2010 8:59 am

Re: Support for data:image

Post by vasa1 »

Wladimir Palant wrote:@Michael: What kind of support do you expect for data: URLs? ... From what I can tell, in this scenario a blocking mechanism would offer no advantages over hiding whatsoever. Am I missing something?
For a less technically adept user, it may be easier to hide data URLs if they are listed in blockable items.
User avatar
Adblock Plus Fan
Posts: 1255
Joined: Sat Feb 24, 2007 11:08 am

Re: Support for data:image

Post by Adblock Plus Fan »

Hmmm, now that you mention it, I'm actually a little scared of the thought of inexperienced users using entire base64 strings to block each image. That could end up really messy really quick.

I wonder how the new filter matching algorithm would fare after a while... Now I'm scared even more since it does like long keywords :shock:
Last edited by Adblock Plus Fan on Tue Mar 01, 2011 4:51 pm, edited 1 time in total.
Reason: Hurrah for the 27000th post of the forum.
Wladimir Palant

Re: Support for data:image

Post by Wladimir Palant »

@Fan: Ok, if the images are defined in CSS then this makes sense. But I am pretty sure what follows - the instant you block all the data: images on this site all the regular images will be turned into data: images as well. And given that there is no proper way to distinguish them...

PS: Sometimes if a self-proclaimed "security expert" insists on promoting scareware you just have to let it go - after all, his software is itself scareware.
PPS: lol, example.com##a[rel="nofollow"]
Michael
Posts: 1361
Joined: Sat Dec 19, 2009 12:29 pm

Re: Support for data:image

Post by Michael »

The filter familar.website##a[rel="nofollow"] hides the link "X-Content-Type-Options: nosniff" in the main good news section. Furthermore, I expect that committing this filter to EasyList would result in all links having this attribute added.
Wladimir Palant

Re: Support for data:image

Post by Wladimir Palant »

Yes, it wasn't a serious suggestion.
fred

Re: Support for data:image

Post by fred »

Hello,

- The ultimate solution to hide the images loaded directly into the code of web pages is the implementation of the technique of "Visual Pattern Recognition" ((basic) OCR for texts + (basic) Recognition form for images) inside of Adblock Plus (or with external API (TinEye, ..., Goggles) ? Privacy problems !).

What is the size of the code needed and what amount of resources used for analysis ? The first analysis should obviously take longer, and the following analysis should simply check if the mask (or the alternative content) is positioned correctly and there must be a quick scan to check the contents of the masked area = "Basic Visual Pattern And Structure Web Page Recognition". The user would be notified in case of change, especially if the mask is placed over the web page regardless correctly inside the code.

- Does the code of web pages must be loaded in a linear fashion from their respective server ? The idea would be to bypass the parties that we do not want to load (such as download managers that open multiple streams to load a file). The page will be downloaded once completely in the browser for the add-on Adblock Plus analyzes the byte position of the parties that we do not want to load, then the next time, Adblock Plus load only the appropriate sections of the page web. Is it possible to charge what they want from the server : One part or several parts of a web page contained in a single file ?

Thank you.
lanced ads

firefox extension to rewrite code snippets?

Post by lanced ads »

Adblock Plus Fan wrote: dict.leo.org, the data image is loaded from stylesheet file. You could block them from ABP by blocking http://dict.leo.org/css/top.b64-B1FoY2.css .

Is it a feature of ADP or perhaps another extension to rewrite content akin to privoxy?
magnus
Posts: 3
Joined: Thu Jul 18, 2013 12:16 pm

Re: Support for data:image

Post by magnus »

Wladimir Palant wrote:@Michael: What kind of support do you expect for data: URLs? They are not associated with downloads, so nothing to be blocked there. The URLs themselves have no semantic meaning - it is the raw image data, no way to distinguish images in a meaningful way. On the previous occasions I said that in the cases where data: images are offending hiding them is good enough as a solution. From what I can tell, in this scenario a blocking mechanism would offer no advantages over hiding whatsoever. Am I missing something?
Yes you are missing something.
You are missing something called "user Preference" if a person wants to block not hide then he should be able to block.
Not every one has or has the option of getting high speed, a person with a slow connection needs to block because then he can load the web page he wants to see in a reasonable time. Many people that do have high speed do not have "unlimited access" if they go over their allotted bandwidth they pay thru the nose so they need to block to conserve their allotted bandwidth. "hiding" does not help because the unwanted content is still downloaded. A web page can have many large data:image images embedded in it making the user download several megabytes of content he does not want, so ABP should provide and easy way to block data:image images. Dont say "theres nothing to block, its basically just text" yes I know that, but ABP should find a way to block data:image. The element hiding rule ##img[src^="data:"] will hide all data:image, but the page will not download any faster because its hidden not blocked.

A bad example of data:image is here http://newworldordernews.com/page4.php I have a slow connection it takes me a coons age to download that page, I want to block all data:image on that page, and that page is not the worst example.
Post Reply