If you think this add-on violates Mozilla's add-on policies or has security or privacy issues, please report these issues to Mozilla using this form.
Please don't use this form to report bugs or request add-on features; this report will be sent to Mozilla and not to the add-on developer.
indispensable - essential
Thanks a lot! This exactly what I want.
The only wish is to support wildcards in domain names.
Great Add-on! It is so much more user friendly than NoScript. It trains you to be aware of what cross site requests are being made from each web site. It is possible to turn off 'Indicate Blocked Images' to make it even less intrusive. Keep up the good work.
Forgive me if this double posts as my connection tonight is really cranky. I put this one in my "Apollo! Pack" collection and after playing with it for a while I consider it a MUST have! The only slight issue I have found is things like this combined with other security add-ons like NoScript Cookie Whitelist, Ghostery... will trip up rookies who are used to surfing in ignorant bliss. Some of them will panic when pages don't load or appear to function fully. I am working on putting up a help page or two to explain just what the heck some of these things are and why a newbie WANTS to be bothered with toggling these things.
I read and agree with the past reviews of this one and I also agree that when you get rid of all the junk scripts, requests, ads... it speeds up pages since they aren't having to connect to and load all the junk! The bottom line is this one is a true 5 star rating!
ANNOYING With the way it Stops ALL Redirects.
Gets 1 bonus star For the Idea.
I really enjoy this app much more so then noscript.
I agree with atomic dryad about allowing cross-site images. Otherwise, it's all good.
And please, don't mention the anal addon called NoScript.
Needs wildcard whitelisting or option to allow images (for gods sake!). Adblock's image blocking is perfect...requestpolicy just makes a pest of itself by nuking all cross-site images in addition to the unwanted cross-site SCRIPTS that it's so well suited to handle.
I would prefer NoScript's way of working, untrusted/blacklisted. When temporarily allowing request from a site would just allow the rest and not the blacklisted/untrusted site[s]. Besides that I really like RequestPolicy. RequestPolicy and NoScript are a must.
Thank You for this add-on.
A very good add-on that puts an end to requests going on behind my back. It needs a certain period tough in which one has to manually add trusted sites to the whitelist when browsing them for the first time. But once this is done, it works smoothly in the background and adds very good extra protection. I recommend this in combination with NoScript, Adblock Plus, BetterPrivacy and CookieSafe.
I also experienced a speed boost in browsing, because unnecessary requests are simply blocked, thus websites are displayed earlier.
It is a very useful addon, however, generates a lot of noise when connected to the web sites when I do a search on google, should have more options for the web forwarding as well as the ability to manually add the domain as reliable as malicious.
Hi, I don't fully understand the feature you're asking for. Please email me or find me on irc so we can discuss it. Thanks!
Please tweak the addon so that the page will only do one reload after all the chosen options are toggled. NoScript pioneered this behaviour, and it's useful for saving bandwidth.
This is definitely a feature that will be added (ticket is here: https://www.requestpolicy.com/dev/ticket/2). There's quite a number of features that need to be added first, but this is a very popular request.
I'd like to be able to approve *.imageshack.us and *.tinypic.com either outright or in association with certains sites or forums. Since imageshack adds new hosts often it's troubling to add each one at a time. There are other sites like this with similar CDN*.somesite.tld that are as irksome to whitelist. ... not merely to load content but 'allow' redirection
despite these this is a truly excellent security extension that falls into "must have" category for EVERY firefox profile.. even those light on extensions
whitelist from *.there.tld
whitelist from cdn*.why.tld
blacklist such that I never am prompted again, nor shown in blocked menu
Very good, but an important thing is missing - wildcard or regexp support, so you can use the full address mode for unfamiliar sites or untrusted subdomains, but don't have to add many permissions for trusted sites and subdomains. Blocking an untrusted subdomain might require a blacklist though.
This add-on has my firefox running 1000X better since I replaced NoScript with Requestpolicy. I even tweeted about it. Keep it light and you've got me as a loyal adopter!
Thanks, I'm glad you like RequestPolicy. I personally suggest using both RequestPolicy and NoScript. See the following for more info on why: http://www.requestpolicy.com/faq#faq-noscript
The extension is great, but as I think there is no opportunity to allow all reqs by default while blocking only unwanted requests? Additional site blacklists could be exchanged and imported from user-community.
Perhaps I am doing it wrong, but trying to allow different blocked reqways to find which one is responsible for missing images(f.e.) is kind of exhausting.
RequestPolicy is still my choice, thanks for the 0.5.13 feature of disabling auto-reload!
I love the concept. Unfortunately, it does not seem to work with StumbleUpon (or StumbleUpon does not work with it) despite stumbleupon.com being whitelisted for both source and destination. Yes, I could turn it off temporarily while "stumbling," but that is when I most desire protection as I never know where the Stumble button will take me. Anyhow, what happens when you press the "Stumble" button is that StumbleUpon picks a topic, displays the topic and "discoverer" of the page in the StumbleUpon bar, but the page itself is never displayed.
This works for me when I whitelist stumbleupon.com as an origin (that is, selecting "allow requests from stumbleupon.com" from the menu). If you're still having problems with this, please let me know.
Excellent add-on, a must have!
Please note that on hiding the status bar the icon on the Navigation toolbar gets disabled (shows nothing, does nothing). Kindly address this issue!
Since the author has corrected the file:// policy in the latest version 0.5.13, I now give back five-star for the hard work and rapid respond by the author of this great addon. Thanks very much, truly!
Please ignore previous comment. It turns out that 3.6 is highly unstable on OpenSolaris at the moment and it's not RequestPolicy's fault.
Thanks for following up to say it doesn't appear to be a RequestPolicy bug. I had noticed your comment and opened a ticket for this, which I have now closed (https://www.requestpolicy.com/dev/ticket/73). You did make me realize that I have never tested on OpenSolaris and should be running a VM for it.
Works very well. Frankly I haven't seen a must-have security extension like this since I installed BetterPrivacy and that was a long time ago.
I would love to give it five-star. HOWEVER, since the last update, RP just block whatever request from a local HTML file, that is, when another extension bring up its local document window, RP blocks it; when I open a ScrapBook item, RP blocks it. It is terribly painful to add each file to the white list -- that's right, you CAN'T even set a path with "file://" to bypass local files, it must be exact file path for each one!
What a damn good idea to put a hand on my "local security"! Thanks a lot but not any more.
I apologize for the very slow response to this bug. In case it helps, installing the older version 0.5.8 would likely make this usable again for you until I can fix this issue. However, no matter how busy life has been, it doesn't excuse not fixing a bug reported months ago. I will fix this bug this coming weekend, period. (The new version might not appear on addons.mozilla.org for a few weeks, though.)
For some reason the 'allow requests from (e.g.) Amazon.com' option has disapeared and I have to click 'temporarily allow requests from....' instead, which is very annoying. I think this happened after an update, it used to be there.
Hi, I'm sorry this change was frustrating. Version 0.5.8 did not treat private browsing mode differently. Since the update to 0.5.12, when the browser is in private browsing mode, the RequestPolicy menu does not give the option of permanent whitelisting. This is a privacy feature, but I didn't realize how many people use private browsing by default and this has hurt usability for these users. I have a ticket open for this issue and it will be addressed in the next release: https://www.requestpolicy.com/dev/ticket/58