This could be extended with things like "blank.swf" and "blank.dcr" and even "blank.jar" but maybe they could all be taken care of with a simple "data:application/octet-stream," (with nothing after it); all this would be difficult because according to the documentation: http://code.google.com/chrome/extension ... uestFilterThe distinguished types are...main_frame (equivalent to Mozilla's "document")imageobjectscriptstylesheetsub_frame (equivalent to Mozilla's "subdocument")xmlhttprequestother...which are all also in nsIContentPolicy, but that also allows forcookiedtdfontgeoindexedDBinstallmedia (->object?)objectsubrequest (->object)pingpopuprefreshxblI suspect that most of these would be considered by WebRequest to be "other"

Anyway, I just uploaded a special build of ABP Experimental that makes a few useful changes...First, all icons are losslessly optimized.Next, the main document can be blocked too.Finally, all filtered request types are redirected to something: document/subdocument to about:blank, xmlhttprequest to "data:application/xml," (blank XML file), script to "data:text/javascript," (blank script), stylesheet to "data:text/css," (blank CSS), object/other to "data:application/octet-stream," (blank binary file).Get it here: https://jansal.googlecode.com/svn/trunk ... mental.crx

Basically, I made "main_frame" requests actually blockable, set up the redirections for various media types, and changed the redirection image from that PNG to the GIF I love so much; here some more conditionals on the URL or some other aspect of the request may help in using one of those other blank swap-outs...

In manifest.json I added "swap-out" after "experimental" and changed the update URL so that Palant's own experimental builds won't overwrite this; besides the aforementioned lossless optimization of PNG icons, I changed no other files in the extension.

Its "update URL" is now about:blank, so it doesn't update, but once I get the hang of making an update XML, I just might make one and then try as well as possible to follow the progress of Palant's updates...

EDIT: It now uses a set of regexp-matching conditionals on the file-extension if it's an "OBJECT" and then if it doesn't find anything defaults to the old "data:application/octet-stream,"

There's a buzzin' in my brain I really can't explain; I think about it before they make me go to bed.

I have updated that build a couple times since my last post, and I finally bothered to implement a proper update-seeking mechanism; I'm still not updating it as much as Eyeo updates the upstream extension, but from here on out, my experimental swap-out build will auto-update (and it still won't overwrite ABP development or release builds).

There's a buzzin' in my brain I really can't explain; I think about it before they make me go to bed.

Both of them are changed, because I saw in the source code to Gundlach's extension that he uses the same null image as ABP (at least as ABP once used) and Ghostery to avoid conflict errors, so instead of those clever custom images based on filetype, I just use that PNG; it is to Gundlach's credit that he still uses the strategy of redirecting to null content instead of just cancelling all the time.

Here is the diff for webrequest.js between the latest experimental build of ABP and my swap-out build...

After someone on the AdBlock support forum pointed it out to me, I hadn't realized that my approach wasn't working anymore, and I'm not sure why...

Apparently, my "experimental swap-out builds" no longer effectively block most HTTP requests, and I haven't figured out how to make them work again.Unfortunately, I hadn't noticed this, because my ad-blocking setup was generally so aggressive that even if ABP or AdBlock wasn't getting at the ads, something else was.

For now at least, I'm sticking with AdBlock, because it uses WebRequest just like ABP, and it still uses at least two kinds of null-content replacement, unlike ABP, which currently just cancels everything.

Maybe when or if we all move to declarativeWebRequest I'll re-visit the issue.

There's a buzzin' in my brain I really can't explain; I think about it before they make me go to bed.

I have found that in my custom build of AdBlock, the variable blocked, which determines whether a URL gets blocked, was always being set to false, and the method call that was setting it to false used code in a part of the extension that I didn't modify; oddly enough, however, when I loaded the extension unpacked, that worked: https://adblock.tenderapp.com/discussio ... t_29026692

I tried the same thing with my custom build of ABP, but whether loading it packed or unpacked, nothing in webrequest.js appears to be used; I've set breakpoints within that file and never hit them. Because I haven't gotten it to work, I won't post a ZIP file for you to unpack and load to see for yourself, the way I did on the AdBlock forum; when I do, I will.

On a note that I also posted on the AdBlock support forum, it's clear that null-content redirection is the wave of the future, as evidenced by the built-in methods for redirecting to an empty page or a transparent image from the still-experimental declarativeWebRequest API; it would be nice to support more types of null content in the API itself, but the "empty page" is probably a good enough substitute for any text-based file, while attempts to define the minimal content for each binary media type are difficult judgment calls (and maybe it's easiest to just use "empty page" for generic binary files too).

There's a buzzin' in my brain I really can't explain; I think about it before they make me go to bed.

I've had a null redirect mod of ABP up and running for a while now. I also stripped out crap like acceptable ads and the secret check for the "disable adblock" header that websites could potentially purchase. Maybe you can use it to see where your bug is.

What it does is add an otherwise completely unnecessary event listener so that every time a site loads, it checks the site's response headers to see if it contains the "x-adblock-key" header and a valid key. If it does, it effectively disables ABP on the site. I believe this was an early idea to monetize ABP that was abandoned. Still, it remains active in the code with no way for users to disable it. I removed it just to be safe. Just goes to show you can't automatically trust open source.

I would argue that it is "secret" and sneaky since "acceptable ads" carries the implication that specific ads/ad networks are whitelisted, not entire sites. Correct me if I'm wrong, but it looks to me like even filters that aren't directly ad-related such as EasyPrivacy would fail to work on a whitelisted site. And suppose two sites use the same non-intrusive ads. One pays for a key and the other doesn't. How is that fair? Then what if a whitelisted site goes rogue and puts up malware or other obnoxious ads? How vigilant do you think the ABP crew will be in monitoring and enforcing their (mostly nebulous) standards against the people cutting them checks? The whole site whitelisting system stinks and should be scrapped.

ReallyAnomymous wrote:Correct me if I'm wrong, but it looks to me like even filters that aren't directly ad-related such as EasyPrivacy would fail to work on a whitelisted site.

That's correct. You cannot have specific whitelists for parked domains since you would need to know every parked domain the company has. That's what the sitekey is for.

ReallyAnomymous wrote:And suppose two sites use the same non-intrusive ads. One pays for a key and the other doesn't. How is that fair?

How do you know who pays and who doesn't?

ReallyAnomymous wrote:Then what if a whitelisted site goes rogue and puts up malware or other obnoxious ads? How vigilant do you think the ABP crew will be in monitoring and enforcing their (mostly nebulous) standards against the people cutting them checks?

Anomymous wrote:I've had a null redirect mod of ABP up and running for a while now. I also stripped out crap like acceptable ads and the secret check for the "disable adblock" header that websites could potentially purchase. Maybe you can use it to see where your bug is.

Other than that, it makes the same sorts of redirections that Gundlach's AdBlock now does and ABP experimental once did: subdocuments to about:blank, images to a 1x1 transparent image, and everything else to "cancel"

EDIT: I notice, upon inspecting the generated background page, that there is an "Uncaught Syntax Error: Unexpected End of Input" on line 1 of webrequest.js, where the opening of the comment containing the copyright notice is, and I have no idea what is causing it (normally it's caused by unclosed parens).

This was retained instead of the new return defaultMatcher.matchesAny(url, type, documentHost, thirdParty); from line 188 of webrequest.js in the stock builds; I'm not sure why the part of the code hiding all blocked elements was removed, but for the longest time I had }); there instead of });}, leading to an unbalanced brace.

I found that syntax error with the help of JSHint, which also recommended using the typesafe comparisons === and !== for comparisons with null and 0, and removing the var keywords from the redefinitions of the variables key and signature, in the section of code that implements sitekey: http://jshint.com/

With all that straightened out, all that null-content redirection worked (however, even though it does redirect Hulu ads to minimal MP4s when EasyList is disabled, it does not work around Hulu's adblock-detection). For this reason I've switched from AdBlock back to my ABP custom builds.I still wonder whether it's worth it to start looking into how to alter the extension to use declarativeWebRequest even though it's still experimental...

EDIT: I've decided to replace all of those regex comparisons with string comparisons, using a single regex to pull out the file extension and using something like

blank.jpg (125 bytes, causes errors in most graphics programs and in IE, but it's not so important because I've moved to just using the PNG for redirection of images, to avoid conflicts with Ghostery and ScriptSafe)