RequestPolicy discussion thread

Discussion in 'privacy technology' started by MrBrian, Dec 10, 2014.

  1. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  2. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  3. 142395

    142395 Guest

    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.
     
  4. krustytheclown2

    krustytheclown2 Registered Member

    Joined:
    Nov 18, 2014
    Posts:
    210
    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
     
  5. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  6. Compu KTed

    Compu KTed Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    1,411
    So what is the difference between RP 0.5.22 and 0.5.28?
     
  7. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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?
     
  8. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  9. Compu KTed

    Compu KTed Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    1,411
  10. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    You're welcome :).
     
  11. 142395

    142395 Guest

    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).
     
  12. Techwiz

    Techwiz Registered Member

    Joined:
    Jan 5, 2012
    Posts:
    541
    Location:
    United States
    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.
     
  13. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  14. Compu KTed

    Compu KTed Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    1,411
    When using RP 0.5 version I checked the Request Log. Nothing is being logged.

    RP Developer:
     
  15. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  16. Compu KTed

    Compu KTed Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    1,411
    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.
     
  17. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    426
    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.
     
  18. guest

    guest Guest

    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.
     
  19. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  20. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    426
    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.
     
  21. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  22. Compu KTed

    Compu KTed Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    1,411
    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.
     
    Last edited: Jan 18, 2015
  23. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  24. Compu KTed

    Compu KTed Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    1,411
    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.
     
    Last edited: Jan 18, 2015
  25. 142395

    142395 Guest

    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
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.