Rated 4 out of 5 stars

Me encanta poder bloquear peticiones a ciertas páginas solo en ciertos sitios e incluso temporalmente, a diferencia de Privacy Badger que es permanente en los sitios.

Lamentablemente, a veces falla al bloquear las peticiones, cuando recargo la página sigue la opcion como si no la hubiese desactivado y vuelve a salir el tipico dialogo de bloquear peticion de esta pagina a esta otra, e incluso a veces funciona y se queda el enlace en la lista como si no hubiese hecho nada pero al seleccionarlo está en blanco, sin opciones.

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 1 out of 5 stars

moved to alternative: https://addons.mozilla.org/en-US/firefox/addon/3p-request-blocker/

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 5 out of 5 stars

Amazing extension that replaced the outdated Request Policy. I sincerely hope you update it to be compatible with Firefox v57.

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 5 out of 5 stars

Excellent for keeping you more secure and increasing your privacy plus reducing the amount of adverts/annoyances. It's simple to use and, whilst it does take a little while to 'train' it initially to block or allow sites/domains, it's not difficult & well worth the effort. Sadly it's not yet compatible with FF57 but I can't wait until it is: I've tried the rest & this is, IMHO, the best. Thanks guys!

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 3 out of 5 stars

I was using this addon since RequestPolicy's death. Now Quantum killed this addon.
For other people finding an alternative, I am trying "3P Request Policy" and it's good.

https://addons.mozilla.org/en-US/firefox/addon/3p-request-blocker/

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 1 out of 5 stars

Time to switch to alternatives.
Thanks for all the fish.

Firefox 57 compatible add-ons
https://github.com/nylira/prism-break/issues/1850

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 5 out of 5 stars

Must have.

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 5 out of 5 stars

I'll preface this by saying that PRC will increase the amount of fiddling you have to do in your browser. That said, this is an amazing add-on to expose and block all the 3rd-party components on websites. The upshot is that you can allow the necessary 3rd-party pieces to load, while blocking the ads and tracking (and potential malware) by default. If you are worried about security or privacy, or just don't like ads, this add-on is for you.

This review is for a previous version of the add-on (1.0.beta13.2). 

Rated 5 out of 5 stars

One of the two (aside of NoScript) most useful addon. A must have one.

This review is for a previous version of the add-on (1.0.beta13.0). 

Rated 5 out of 5 stars

As a security conscious hobbyist, I researched how to make FireFox secure. The consensus was: use "RequestPolicyContinued" along with "Noscript." This was repeated everywhere I looked, but my first source was Ghacks.net.

I tried it for a few hours and failed to get it working. Couldn't get my search engine website to open websites without clicking "Allow" for each search result. I followed the developer's instructions for asking questions (create GitHub account, use the "Discussion" page to post questions.)

The developer responded in less than 24 hours with a solution to the problem.

Here was my question and his response. Hopefully that saves someone else some time in the future:

QUESTION:
I created the following rule:
Policy -- Origin----------------------- Destination-- Rule Set
Allow -- https://duckduckgo.com/://: ://:* -- User

ANSWER:
I guess you put https://duckduckgo.com/ in the origin "scheme" field and :// in the destination "scheme" field. Instead, fill in as follows:

origin scheme: https
origin host: duckduckgo.com
destination host: *

This review is for a previous version of the add-on (1.0.beta13.0). 

Rated 5 out of 5 stars

Great add-on! And it has been substantially enhanced over the the original version allowing easier handling of requests through pop-menu (among other things).

This review is for a previous version of the add-on (1.0.beta12.4). 

Rated 5 out of 5 stars

Works as expected

This review is for a previous version of the add-on (1.0.beta12.4). 

Rated 4 out of 5 stars

RequestPolicy Continued will be compatible in the futur with Electrolysis Mozilla Projet ?

This review is for a previous version of the add-on (1.0.beta12.4). 

I am now working on a WebExtension version, which will be Electrolysis compatible. Subscribe to the issue (https://github.com/RequestPolicyContinued/requestpolicy/issues/704) if you want to be notified about the progress.

Rated 5 out of 5 stars

This is the second add-on i install on every firefox install. The first one is no-script. Required for advance users

This review is for a previous version of the add-on (1.0.beta12.4). 

Rated 4 out of 5 stars

I like this and have been using it for years. I think it as the last safety net for XSS or CSRF.
In many slow sites, I don't allow ad destinations. I never use AdBlock etc because they use blacklist filtering which is not sufficient for rapid-growing security risks.
As a trade-off, it takes effort to use. Online payments usually require several times of allow-then-retry's to successfully complete.

This review is for a previous version of the add-on (1.0.beta12.4). 

Rated 1 out of 5 stars

Like other users, I have seen an allowing of scripts I would have expected to be blocked.

Does anyone associated with RequestPolicy Continued have a relationship with commercial entities that might explain this change or fault in functionality?

I have removed "RequestPolicy Continued" for the time being, but will revise this review once clarified.

This review is for a previous version of the add-on (1.0.beta12.3). 

Be detailed!

«Like other users, ...»
Which other users are you talking about?

«I have seen an allowing of scripts I would have expected to be blocked.»
RequestPolicy is not about blocking scripts—NoScript would be for that—but rather requests.

«Does anyone associated with RequestPolicy Continued have a relationship with commercial entities that might explain this change or fault in functionality?»
Which commercial entities?
Which fault?

Update your comment and I'll take a look at the issue.

Rated 5 out of 5 stars

RequestPolicy Continued: Make temporarily Allowances permanent.
This should be faster, easier to do with 1 Click.

There is only the option
"Stop allowing..."
after you have temporarily allowed scripts for a specific site.
The Option
"Allow requests..." is missing, which makes temp allowances durable.

This would make RPC much more comfortable :)

And perhaps an OK-Button in the right bottom of the option field, to spare mouse movements on reloading pages after changeing requests :)

This review is for a previous version of the add-on (1.0.beta12.3). 

Rated 2 out of 5 stars

Before mozilla switched to requiring addons to be signed, I was using this:

https://www.requestpolicy.com/1.0.html

The 1.0 beta of requestpolicy works perfectly. All the kinds of rules I would normally have to spend time adding are already there, and it very rarely gets in my way.

Contrast this with RequestPolicy Continued. RequestPolicy continued is more intrusive, doing things like not allowing links to take me to another page. I always end up disabling it soon after installing it. It would be nice if RequestPolicy Continued would build on the RequestPolicy 1.0 version, so it could start with a nice, user-friendly version. Maybe someone could make a fork...

This review is for a previous version of the add-on (1.0.beta12.3). 

Is a default policy of “Allow” what you want? Check the settings.

If this is not what you want, or if you think there is a bug, please describe a reproducible scenario. You best communicate via github, but you can also send me an email.

Rated 4 out of 5 stars

Congratulations on building an incredibly handy and mandatory tool for the Firefox community, your efforts are sincerely appreciated.

I just need to highlight one small point of interest which I feel deserves some clarity. It might be a bug or it might just be me misconfiguring something.

(Step-1) I have disabled all Subscription Policies because I would like to create my own on the fly if and when needed which works just fine.

(Step-2) Under Default Policy I have also ONLY selected “Block requests by default” and took the tick mark OUT from the “Allow requests to the same domain” box because I do not want ANY scripts to be allowed initially when I visit any website and therefore have full control over what eventually does get allowed.

When I visit www.github.com for example, the above settings are applied 100% correctly and I have to manually configure github.com to allow loading scripts from its own domain which is exactly what I want.

The problem however is when I visit www.google.com or www.yahoo.com for example. Somehow they are allowed to always load scripts from their own domain although I have explicitly disabled the options to do so.

My understanding is that the default behavior would always be executed in the absence of a policy rule and I have NO policy rules for Yahoo nor Google. So question time. Why is Google and Yahoo downloading scripts from their own domain when default policy clearly dictates otherwise and I have no policies set for them?

I clean installed the latest Firefox 44.0.2 32bit from scratch and installed the latest RequestPolicy Continued as the ONLY extension and still the problem persists. It is therefore not a conflict between extensions.

Once more, sincere gratitude for your efforts on a great security product.

This review is for a previous version of the add-on (1.0.beta11.1). 

Hello Sam, thank you for your report.

It's correct: in your configuration of the default policy, requests from "https://www.google.com/" to "https://consent.google.com/" (different sub-domain) should be _blocked_. However, requests to the same sub-domain (e.g. "https://www.google.com/" to "https://www.google.com/") should be _allowed_. Does this match with the behavior you've observed?

Do you think the spelling "Allow requests to the same domain (www.example.com -> static.example.com)" is misleading? It could emphasize more that requests to the same subdomain are _allowed_.

You can communicate with me on github on a new issue, or via email.

Rated 5 out of 5 stars

The first thing I do on a new Windows PC is install antivirus software. The second thing I do is install firefox. The third....is this extention.

Do not, under any circumstances, use firefox without it. Do not browse the web with a browser that does not implement this functionality. Do not, EVER disable this extention.

The fourth thing....install No Script.

No web site that doesn't work with this extention is worth the risk to your PC or privacy.

This review is for a previous version of the add-on (1.0.beta11.1).