Only the Chrome extension of Privacy Badger uses ABP code. And it only uses it for managing the blocklists it creates. Most of the function of Privacy Badger is run separately from the ABP code, and to be honest my first task for the next version is to get rid of ABP completely :)
Privacy from OS creators is likely outside of the scope of your project, but I thought I'd pass along recently observing that filtering using the hosts file on older Intel OS X which works for other browsers does not seem to be effective for Safari. I'd long ago read of MS using their own DNS for IE, perhaps Apple is doing something similar? It could be done for performance reasons, but it certainly has privacy implications.
I hope you consider things like blocking loading of webpage icons, and something to deal with data being appended to redirects or even CSS calls when cookies are disabled. I'd read about detecting caching of slightly different colored versions of icons and beacons. Sneaky offsite https accesses (analytics etc) are commonly bundled in a pages JS and NoScript doesn't alert to that. Also, some browsers seem to make accesses to a number of sites on startup, before even going to open a page.
Widening the view from "advertisers" to data-mining contractors that even do drive-bys, it might also be worthwhile to study what could block local data broadcasts by code designed to modulate r.f. noise leaking from our machines. Tune across the A.M. broadcast band on a nearby battery operated radio. I've noted that sometimes there's much more pulsed/bursty noise that doesn't seem to be tied to any obviously more demanding content.
Some of the insideous Ad-Choices content seems to go beyond Flash for hiding data. From the plugin being called when there wasn't any visible content needing it, I think even Quicktime is being used to cache data.
It would really help if scripts from one tab could not be accessed by another, and were killed on closing the parent tab. I guess the litterboxing would best be done by a trusted browser? Bring on the worming tablets!
> filtering using the hosts file on older Intel OS X which works for other browsers does not seem to be effective for Safari
Could you clarify this point? I may well simply be misunderstanding, but a quick check of a hosts-blocked site using Safari, in El Capitan, does indeed not resolve (or rather, resolves to localhost, as specified).
Privacy Badger currently detects tracking via regular cookies, HTML5 local storage 'cookies', and canvas fingerprinting, with more methods aimed to be supported in future releases
What other tracking methods does Privacy Badger plan to block in future releases? One can always test against evercookie.[0] And perhaps EFF could host a trustable demo site, along the lines of Panopticlick. I do get that this is an arms race, and that proprietary methods may be running under the radar, as Verizon's UIDH did for two years.[1]