Add a request blacklist with priority over the whitelist #6
Comments
From navjotjsingh (http://forums.mozillazine.org/viewtopic.php?p=7662825#p7662825): Say I have a site mysite.com and I have installed Google Analytics on it. Now I want to allow all requests to Google Analytics except from !MySite.com since I would like to exclude my own visits. So, there is clearly a use case for origin-to-destination blacklists. |
With considerations of policy types and site specificity, the implementation will have to consider priority at each level. For example:
This will permit exclusive explicit exceptions from the blacklist, if the whitelist policy is more specific. For example: DENY example.com EXCEPT ALLOW !http://important.example.com It will also preclude "Temporary" (non-explicit) policies from overriding explicit policies, regardless of specificity. One question yet to be addressed is origin-to-destination policies of different strictness settings on the whitelist versus the blacklist. Perhaps:
Should 3 to 6 be refactored to prioritize higher specificity of the origin or destination? |
There's clearly a use case where people want !RequestPolicy's UI but want the extension primarily as a cross-site request blacklist rather than a whitelist (default allow rather than default deny). Rather than just having the solution be that they should "temporarily allow all requests" and rely on the blacklist still being enforced, it should possibly be a mode the user chooses to use !RequestPolicy in. I'm not sure how this should be represented in the UI if the user is in such a mode. |
To further complicate the issue, users may want to specify default policy as well as identify sites to feature the opposite policy: ALLOW, DENY default, but or DENY, ALLOW default, but #174 seems a decent short-term compromise for simply implementing a blacklist, but still hoping for a iptables-esque rule based policy... |
|
Another use case would be if I would want to e.g. whitelist all requests from ebay.com (as there are often external services for pictures and alike) but at the same time blacklist requests to google-analytics and such. Similar case with some forums where there are many pictures posted by members which are hosted externally. If I had the possibility to do so I would be very ok with whitelisting "all" requests from certain forums except for google-analytics and similar services. The new comfort of only blacklisting a few domains instead of doing it the other way around would of course increase the necessity of the user's self responsibility as he/she would have to check from time to time if new unwanted services have started being in use by the whitelisted site in the meantime. Compared to whitelist everything it's a plus anyway I think. Now, one might state that you can whitelist certain requests one by one and as time goes by and I say: That's completely true. The blacklisting thing to me is really nothing more than a bit more of convenience, especially for rather experienced users. If there are experienced users who have a demand for a blacklist (and obviously there are) I would vote for that. In my case for example I would want to use it for sites I otherwise trust.. Other use cases have been stated above. Having more options to finetune in general is a plus I think. Other than that I still feel finetuning RP in most cases it's main purpose (compared to go the easy way and just whitelist). I regard security and security awareness very important and place it above user convenience. So, a blacklist feature might contain both, the risk to be tempted to do it the lazy way but also the chance to be able to configure everything to better meet one's needs. Technically I cannnot say much on how it should work as I'm not a programmer. I still want to contribute my humble two cents.. The most important feature to be implemented would be blacklisting on a per-site basis (i.e. specifically forbid certain requests from otherwise whitelisted domains). In the long run it might also be useful to additionally be able to blacklist requests to/from certain domains in general (i.e. if I once blacklisted google analytics I don't have to care to blacklist it over and over again on every site that I whitelist. In turn, one should be able to whitelist a generally blacklisted domain on a per-site basis as there are some sites which in order to work correctly require services which are usually undesired). Thank you. |
|
You might make this feature as general as the arbitrary Application Boundary Enforcer feature in NoScript http://noscript.net/abe/ , which should be able to do what this issue describes. The major benefit with blacklists in RequestPolicy will be the UI, as NoScript doesn't provide an ABE UI so it is virtually useless for random browsing. |
|
I'm not sure about it but NoScript might do something about ABE's usability in future versions as stated here: http://forums.informaction.com/viewtopic.php?p=32446&sid=ed6f2927531f012d8aa307e46d0efcf4#p32446 |
|
About 2 years ago I sent in a request for this feature via email and it still hasn't been implemented. It should have been done by now. When is the blacklist going to be implemented? |
|
A blacklist has been implemented in version 1.0 which is currently in alpha: https://www.requestpolicy.com/1.0.html --- note that I won't have time to focus on version 1.0 again (including issues with it) until some time next month. The current plan is to have 1.0 ready for production by the end of this year. |
|
Really, this has baffled me ever since installing RequestPolicy (I'm using 0.5.27 right now). AFAICT there is no 'blacklist' feature at all -- requests are "blocked" by default and can be added to a whitelist but there is no way for me to express "disallow any request from any site to even when I select Temporarily allow all requests." I can imagine a case where users would wish to blacklist requests to a domain from only a specific domain but I think the existing behavior handles this adequately (so long as they don't whitelist it, the site will be blocked). Rather, a blacklist would most sensibly operate at the global level. What I would like to see is a new section on the menu above "Blocked Destinations" called "Blacklisted destinations". The per-site submenu would be "Remove from blacklist" and "Temporarily allow requests to ". The per-site submenus for allowed/blocked destinations would have an additional option "Add to blacklist". Finally, an option "Temporarily disable blacklist" at the bottom of the blacklisted destinations section. This idea may produced cumbersome menus though if there are a lot of blacklisted domains. Maybe it gets rendered as a submenu to the menu if more than X domains will be listed (or all the time?) Demanding... I know. And posting to a stale thread, geez. I'll point out I haven't tried v1.0 so I can't say how it meshes with these ideas. Still, a blacklist feature could dramatically reduce the time I spend approving domains and it looks like I'm not the only one wishing for it! |
|
Hi @patricktokeeffe, RequestPolicy version 1.0 lets you create blacklist (deny) rules and also lets you work in a default-allow mode. https://www.requestpolicy.com/1.0.html Hopefully version 1.0 is the solution you're looking for. |
|
+1 for a blacklist like in noscript. also really like the idea of importing the blacklist from noscript #14 |
|
+1 for blacklist. Just let me decide, which domains i don't want to see in the list of blocked destinations. 👍 |
Add a blacklist of request destinations that aren't allowed even if the whitelist policy says they should be. This would apply even when "temporarily allow all requests" is enabled (maybe that would be the default behavior but it could be changed through a config option to not apply in that case).
The blacklist would be able to include IP address ranges and requests to those IP addresses would be blocked even if the host in the requested URI was a domain name rather than an IP address.
The blacklist would definitely be for blacklisting destinations, possibly also for blacklisting origins-to-destinations (though one might argue that if users need to allow destinations from only some origins, they shouldn't whitelist the destination but instead only those origins-to-destinations they intended to allow). What about origins? I seem to really need to stretch to come up with a situation where that would be useful.
The blacklist would probably be accessible by default only from the preferences window but later on there could be an option to add "blacklist this [whatever]" items in the menu.
(Thanks to RSnake for the suggestion of a blacklist.)
The text was updated successfully, but these errors were encountered: