I've stayed with version 0.5.22 with no predefined whitelist, primarily because the features added to 1.0 are not useful to me. IMO, a default-permit option defeats the purpose of the add-on. I'm a bit at a loss as to what's being changed here and how those changes will benefit (or hurt) the user. Unless there's some form of cross site request that RP isn't controlling, I don't see any reason to change it.
One reason I prefer RP over Policeman is RP has redirect blocking (1st party). Some malicious site uses multiple random redirect for obfuscation so I think it's useful. It doesn't cover so-called meta redirect, but Fx have built in redirect warning which covers meta-redirect so I also enabled that.
In my experience RP breaks more sites than even NoScript, total headache to use, and I think it's of less practical use in preventing exploits than NS. If I'm visiting anything risky where something like RP would normally be prudent, I'd rather just use a live system within a VM and any exploit dies with the session, more secure and all sites work fine
I don't see RP as a tool for preventing exploits, save for requests to malicious adservers. IMO, it's more valuable for getting rid of undesired content such as 3rd party trackers, ads, and the connections to Google and Facebook that infest the majority of web pages. I don't mind having to load a page a 2nd time in order to limit the content to only that which I want to see. IMO, RP is an excellent complement to NoScript or in my case, Proxomitron. The 2 serve different albeit somewhat overlapping purposes. RP allows you to whitelist connections. NS and Proxomitron allow you to whitelist content. Between the 2, they cover just about all of the ways that malicious content can be delivered to a browser.
I don't know what's been changed between the different versions of RP. 0.5.22 has worked very well for me so I've never updated. If there's a changelog on their site, I've missed it. Could someone link to it if one exists?
Seems everyone has his own reason! In my case, CSRF protection comes first. There're not many option to prevent CSRF on client side. I use CSFire too as a 2nd layer, but it silently causes more problem than RP unless you make much of rules so can't recommend to others. NoScript's ABE is another altrenative but this is hardest way and not practical. As to exploit, there's exploit which NS can't block but RP can, vice versa. But again, for me NS is more for XSS protection. Also I second noone_particular, it's very good to block tracking and ads, excellent complement to NS, though I finally dropped Proxomitron (but I keep my customized Proxomitron in USB for possible future use).
I can understand the developer wishing to consolidate development down to a single add-on, but this pandering to whiny users that can't be bothered is seriously disappointing. It's like caving in to children when they refuse to eat their vegetables. I'm fine with compromising, so long as users realize they have give to get. So if you don't like long/complicated passwords and want a four digit pin. You have to accept that the developer thinks it would be more convenient to store user information in plain text. Likewise, if you don't like configuring RP, the developer has the right to remove all configuration options for allowing/blocking after implementing a default permit option. I think users would come around pretty quickly when they realize they can't have everything they want. Might seem extreme, but my tolerance to pandering to stupid is running thin.
I completely agree. A default-permit option basically allows the browser to do what it would normally do, fetch and connect to everything that's requested. In that mode, the extension does nothing. If a user wants that, disable it. The other option, importing black/whitelists is little more than delegating your privacy/security to 3rd parties. If that's the route the developer wants to take, there's little we can do about it. That said, I'd hope that they'd keep the original default-deny version available for those of us who want a version that works as it was intended. This is another reason that I don't allow auto-updating, especially for browsers and extensions. The results of some of their improvements and features border on malicious changes that I want nothing to do with.
The request log works similar to Proxomitrons log window. It's more of a real time display than a written log. Open it, then load a page. You'll see what's blocked and allowed in real time. There is a context menu for items displayed in the log window.
Didn't know you had to load a page to see logs entered. I now see allowed/blocked entries and the context menu. Thanks for info.
RP v0.5.28 display the log info, per tab, to a pane in the current window. In later versions, is the log info is displayed in a detachable window? FWIW, I use a separate extension, in tandem with RP, called "HTTP Request Logger" https://addons.mozilla.org/en-US/firefox/addon/http-request-logger which writes a global log of all ff requests to an external file (and I keep a shortcut to that logfile on my desktop). Output format is like this: Code: (noreferrer) GET https://addons.mozilla.org/ (noreferrer) GET https://addons.mozilla.org/en-US/firefox/ https://addons.mozilla.org/en-US/firefox/ GET https://mozorg.cdn.mozilla.net/media/css/tabzilla-min.css https://addons.mozilla.org/en-US/firefox/ GET https://addons.cdn.mozilla.net/static/css/zamboni/impala-min.css?build=a6a288e I have websockets disabled. I don't know whether the extension would log websocket traffic (I doubt it). In the first line, above, I had typed addons.mozilla.org into addressbar, so "no referrer" is accurate. Line2 apparently resulted from a (302?) redirect, and the extension isn't clever enough to capture/report that detail. (It can't. I would need to be rewritten.) Lines3 and 4, leftmost url is referrer and right is the request method+ requested uri It does log each ajax request, and I see GET, POST, and DELETE requests in today's log (some requests to indiegogo.com are DELETE cookie requests. hmm that's interesting) ...but I can't recall testing whether the extension logs ftp PUT and other request methods. The logfile gets HUGE quite quickly. I try to keep it under 2Mb, but I can't recall a performance hit from larger filesize. At one point I considered attempting to hack the extension so that it buffers it output and writes to disk less often (as is, it apparently keeps the logfile open/locked, and writes at least once per pageload) but having the logfile open in a textPad window provides an immediate cue when monitoring unexpected/unwanted activity.
I tried RequestPolicy Continued. Subjectively speaking, I really don't like the new UI. And when I opened the settings I saw a "chrome" line in the address bar which gave me a WTH moment. Really didn't like it so I'm back to version 0.5.28.
I haven't looked at RP Continued. I'm very satisfied with RP the way it is and consider it a finished product that needs no changes.
noone, which version of RP are you using? As a heavy user, I can't agree that it is a "finished product". v1.0b+ is buggy, and RP 0.5.28 begs several fixes (at least 8-10 of 'em, see the github issues list and the patches / pull requests by Jordan Milne) github.com/JordanMilne/requestpolicy/commit/a7684192079d7306b95ba9de9e49694c119828c4 and Jordan's explanation: http://blog.saynotolinux.com/blog/2...stpolicys-whitelist-using-the-jar-uri-scheme/ Problem (IMO) with RPcontinued https://github.com/RequestPolicyContinued/requestpolicy is that it (its functionality) foregoes a hardcore "default deny" approach, the devs are hellbent on appealing to a wider audience and are embracing a default allow "subscription blocklists" approach ~~ which seems dumb (er, nonsensical) until/unless RPc accommodates PATH-based rules. Compared to RPc, the nascent policeman extension https://github.com/futpib/policeman offers much more granular control & provides a great GUI for applying temp or perm rules on-the-fly.
I'm using 0.5.22. Compatibility issues prevent me from using a newer version. Thanks for that issue list. Regarding the example in the link, I'm not sure how big of a problem that is. An attacker would have to target RP specifically, then use it to do what? I'm pretty sure that I can mitigate that problem with a Proxomitron filter that removes requests for .jar files. Regarding request policy continued, this appears to be an attempt to monetize it. For users who want to pay or rely on others to build their blocklists, maybe it's an option. IMO, they're ruining a good extension and I'll have nothing to do with it. Regarding Policeman, unless I missed it, this is only for FireFox and possibly variants of it. I didn't see a SeaMonkey version.
RequestPolicy 1.0 A "default allow" mode instead of just a "default deny" mode Personally I prefer a "default deny mode" and whitelist on web site basis. Haven't permanently updated to newer version, but recall testing 1.0 a while back & decided to go back to the 0.5 version. If one filters the requests from jar URI's for example through a proxy filter then wouldn't this solve the RP whitelist bypass? Policeman also is not compatible with Pale Moon.
I don't see the point to a default-allow mode. There's nothing gained by blocking something after you've already allowed it. If a user wants default-allow, why install the extension? The browser already is default-allow. It should. It should be possible to filter out all requests to any .jar file.
Only tried RP 1.0 in testing and yes default-allow mode doesn't make sense to me. Default-deny is what I want. Not exactly sure how best to filter this. Without the patch RequestPolicy does show both green and blue squares. I could use Sandboxie to filter .jar files or run a proxy filter that handles regular expressions that filters URL's. If I do that I end up blocking for example http://saynotolinux.com/tests/requestpolicy_jar.html completely.
I've been testing 1.x with default deny mode, so far there's no serious issue. But do someone know how to whitelist image and CSS by default in 1.x? So far I can't find where I should modify in requestpolicyService.js