Thank you for the fast reply
I have read many of your posts where you say that ABE's primary aim is CSRF-protection and not privacy and I actually wanted to aknowledge that in my first post. I forgot to do it. I understand why you're willing to make that clear, and if I still ask privacy related questions that's because I feel ABE has potential for wider use provided it is configured properly by the user. The main reason I'm trying to use ABE for that purpose is that the less extensions in my Fx, the better it is. And because I trust your thoroughness and your working capacity.
I have a handful of disabled extensions that I enable on specific (uncommon) instances. Eventually I use the -no-remote tag to run several Fx profiles at once. In everyday use, I only enable NoScript carefully configured and Cookie Monster (CookieSafe was a lot slower when I tested it about a year ago, due to the fact that Fx had tons of stuff blacklisted by Spybot S&D. Don't know if CS Lite works better.). I use ABP too but I don't want to block advertising; what annoys me is tracking (unfortunately attempting to defeat the latter tends to defeat the former...). I'm also looking over RequestPolicy but it's apparently not been tested enough by the Mozilla team, so I'm probably going to wait.
What I am coming to is, if NoScript, with a careful configuration, can replace 2 excellent addons (ABP and RequestPolicy), I'm willing to spend some time informing myself. And if it appears that ABE isn't better in the privacy area than these addons, I won't be questioning your skills: I know that I'm trying to use the tool in a "secondary" way... I'm sure that RequestPolicy allows just what I'm looking for when I play around with ABE trying to see if it can isolate sites from one another unless I say otherwise. But I'm still reluctant to use a not reviewed addon, add yet another one, and do so when there's ABE that shall in the next few months be able to do the same. I want to give ABE a try in filling that privacy purpose.
Now that it's cleared up, a couple replies:
Giorgio Maone wrote:You currently cannot (there's no "subdomain of Site" meta-identifier), but I can evaluate something like that as an enhancement, e.g. something like
Site * Accept from *.SITE, where "SITE" would be replaced with the current Site match.
A SITE variable would probably be useful in several circumstances, that would be a nice addition.
Giorgio Maone wrote:What do you mean by "logging" here?
ABE display a notification for DENYed document loads only, and logs everything else in Tools|Error Console.
Do you refer to the former or to the latter?
The latter. For me, the error console ONLY logs denies (I was about to suggest it could be useful to have a toggle button that logs "allows" too).
As for DENY notifications, I get some when I try to open a link with very restrictive rules, but many denies go unnotified: No notification bar at all even though many things are denied... It could be because images and stuff like that aren't considered "documents" though, so it wouldn't be a bug.
In any case DENYs are still logged in the error console. But here in the first post, I was talking about a denied GET request that was not logged anywhere for some reason.
Giorgio Maone wrote:Working with IPs will be much easier in next release. At this moment it's quite hairy, and the only DNS resolution working really well is the one fueling the "LocalRodeo" SYSTEM rule.
In the case of youtube, when ABE will be able to recognize dns1.sjl.youtube.com as the everchanging IP for which I set up a separate rule in the first post, then this rule shall become useless because of the *.youtube.com rule. I'll wait until you've developped ABE further then
(Note that even my Firewall can't automatically recognize fixed domain names that keep switching IPs, so good luck with that
)
Giorgio Maone wrote:TestingABE wrote:Is it certain that these IPs are only given to those two servers during at least the next couple years?
Alas, you can only ask Youtube staff and they can always change their mind, too
At least they won't change domain names, which I guess makes it safer to use rules with domain names than rules with IPs....when it's possible that is.
As for clicking on links in websites, looks like...
Code: Select all
Site *
Accept from SELF
Accept GET from *
Deny
...isn't the rule I'm looking for... I wonder what could be good... I'll play a bit more and if I don't find anything fine I may give RequestPolicy a try.
Giorgio Maone wrote:Yes, ABE can surrogate all those tools.
However all them have their specializations, which may make them valuable even if used together.
But having the same things checked over and over and eventually modified by each addon... Is it really worth it having several addons that do similar things, once the downsides are taken into account? (i.e. slowdowns, potential conflicts, ???, ...)
And uh...LAST questions, I promise
8/ How does Noscript|Options|Advanced|Untrusted|Forbid "Web Bugs" work? Is it disabled on trusted sites even if "Apply these restrictions to trusted sites" is checked? And finally, won't it be rendered useless/redundant with a future ABE subscription that mimics EasyPrivacy?
9/ Is there a way for a webmaster to make revenue from advertising while ensuring his visitors are not tracked AT ALL? (and if yes, would it be a much lower revenue or would the difference be acceptable?)
That was one messy post. Thank you for your time and answers, your "customer support" is just too good to be true. It's like you're omnipresent or there are a dozen instances of you replying everywhere and working and doing researches at the same time. I don't know how you do that. Is it the secret recipe in your cup of coffee? I could use that.
Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)