[Ext] RequestPolicy 0.5: control over cross-site requests

[bjm_]

Good day Justin
I waited for FF and now have conflict with my Security app. 0.5.12 does not play well with NIS 10.1 Tool Bar...Tool Bar vanishes.
bjm_

[ad_infinitum]

Hi Justin,

I just registered to the forum, as I really like RequestPolicy, but I got a problem with the latest (I think) update (through Firefox extensions update).
The option for permanently allow requests from a specific site to another specific one is missing - I only get the temporarily one.

I think it's related to the last updated version, given that I got it 2 days ago and noticed this issue just today.

So, is it just me or is this a RequestPolicy issue?
What can be done?

Oh, on the same day, I got an update for NoScript as well - could it be some sort of conflict between them?

Thanks in advance,
ad_infinitum

[Justin Samuel]

Good day Justin
I waited for FF and now have conflict with my Security app. 0.5.12 does not play well with NIS 10.1 Tool Bar...Tool Bar vanishes

Thanks for reporting this, I've opened a ticket for this here:

https://www.requestpolicy.com/dev/ticket/57

[Justin Samuel]

I got a problem with the latest (I think) update (through Firefox extensions update).
The option for permanently allow requests from a specific site to another specific one is missing - I only get the temporarily one.

Hi, this should only happen when you are in Private Browsing Mode. The reason to not store items in the persistent/permanent whitelist when in that mode is that whitelist entries related to sites someone might not want in their history would still be in the whitelist after they leave Private Browsing Mode. So, the approach I took to addressing this was to prevent people from adding to anything but their temporary whitelist while in Private Browsing and then, when one leaves Private Browsing, the temporary whitelist is cleared.

If you're seeing this and you aren't in Private Browsing Mode, then this is probably a bug (hopefully a rare one, otherwise that would be really annoying for a large number of users).

[ad_infinitum]

Hi, this should only happen when you are in Private Browsing Mode. The reason to not store items in the persistent/permanent whitelist when in that mode is that whitelist entries related to sites someone might not want in their history would still be in the whitelist after they leave Private Browsing Mode. So, the approach I took to addressing this was to prevent people from adding to anything but their temporary whitelist while in Private Browsing and then, when one leaves Private Browsing, the temporary whitelist is cleared.

If you're seeing this and you aren't in Private Browsing Mode, then this is probably a bug (hopefully a rare one, otherwise that would be really annoying for a large number of users).

Thanks for the reply Justin,
Yes, I'm in Private Browsing Mode (PBM). Problem is, I'm always in PBM but still have some sites I used to permanently allow specific requests.

Are you saying that the only way to have this option back is to give up PBM? I must confess, I'm a bit disappointed. I think it's unfair to cut it completely off for everybody, because - please, correct me if I understood this the wrong way - one might choose "permanently" instead of "temporarily" while in PBM.
The way the options were presented till now was very clear; loosing the option to permanently allow in PBM has taken away some of its functionality - but maybe, it's just me.

Please, don't get me wrong; I really love RequestPolicy & the power it gives you over your browsing and I do appreciate the effort you put into it, I just don't think that the new direction is for the better.

Anyway, is there any way to overcome this, except giving up PBM? If not, will there be in the future?

Thanks in advance,
ad_infinitum

[Justin Samuel]

Yes, I'm in Private Browsing Mode (PBM). Problem is, I'm always in PBM but still have some sites I used to permanently allow specific requests.

Thanks for confirming that. Unfortunately there's no workaround in 0.5.12 other than using the preferences window to whitelist items. I think your best may be to go back to 0.5.8 (the stable release before the private browsing change) until I can add a preference for this in the next release (0.5.13), which may not be for 2-3 weeks. I do understand how this could be very annoying. The problem was that I just hadn't considered this use case when making the change.

I've opened a ticket for this here:

https://www.requestpolicy.com/dev/ticket/58

[ad_infinitum]

Hi Justin,

Thanks so much for the reply, the ticket and, most of all, the hope you've given me.

So, if I understood this correctly, in the next version, there'll be an option in preferences (under Advanced, maybe) that, if chosen, will make the permanently allow menu active (visible) in PBM? Or sth in the line of this?

Manual whitelisting requests is a bit of work, but I can live with it knowing that solution is on its way. And don't worry about the time-line, 3 weeks go by faster than we think.
Let's say this is going to be your X-mas or New Year's present to users like myself.

Thanks again, and apologies if I was too hard on you,
ad_infinitum

P.S. Does RequestPolicy come with some default permanents whitelisted? When updating versions, do your permanents follow you? Asking, coz I got some I recognize I whitelisted before v.0.5.12, but also some I definetely did not (e.g. there're a lot of entries for ebay, but I don't visit/ use ebay).

[Justin Samuel]

I apologize for taking so long to address these issues, but I now have a beta of 0.5.13 available here:

https://www.requestpolicy.com/releases/ ... 5.13b2.xpi

Version 0.5.13 has the following changes:

• Option in Preferences > Advanced to allow persistent whitelisting while in private browsing mode.
  
• Option in Preferences > Advanced to disable auto-reload of pages.
  
• Individual file:// urls are no longer treated as separate origins/destinations.
  
• The request log has an informational message when it's empty (to decrease user confusion over the empty log).
  
• Internationalized Domain Names (IDNs) are supported.

More details:
https://www.requestpolicy.com/dev/query ... one=0.5.13

Anything not in the list above is not because I don't think it's important, but because I want to get these fixes out before any more time slips away. Especially with the growing list of extension and toolbar conflicts, there's quite a bit of work to be done.

For those who have a chance to test 0.5.13b2, please let me know if you find any bugs.

Thanks!

[Justin Samuel]

While version 0.5.13 is waiting approval and hangs out in the AMO sandbox, I've got a beta of version 0.5.14 ready:

https://www.requestpolicy.com/releases/ ... 5.14b2.xpi

This beta attempts to address the issue of unstyled pages sometimes showing briefly before the page's CSS is applied to the page. The changes I've made seem to improve this for me, but others still notice the problem. Feedback is welcome. (e.g. did you notice this before and does this fix it for you? Are you also running NoScript and do you notice different behavior if only running NoScript or only running RequestPolicy?) Feel free to post feedback here or in the ticket:

https://www.requestpolicy.com/dev/ticket/75

This beta also fixes a bug in Refresh header processing that appears to most likely only result in an error in the error console and the correct behavior still happening, as luck would have it.

[Natanael_L]

I want joker signs and cross-site any-destination rules, and top-domain based rules, and negation.
And black lists to make exceptions for subdomains.

Something like this:
site.com <-> http://www.site.com - approved
* -> api.site.com - approved
!*.onion <-> *.onion - banned (non-Tor domains to/from Tor domains)
* <-> http://*.site.com OR !https://* <-> !https://*site.com // - banned (banning non-SSL encrypted cross-site connections)

And site groups:
www.site.com & site.com & img.site.com & js.site.com & cdn.site.com = site.com domains
* -> site.com domains - banned; site.com domains -> * - allowed (outgoing only)

[Privateofcourse]

Thanks for RP, I like the extra security very much. I use it together with NoScript and AdBlockPlus. However, I have had to disable RP for the time being because it has become too impractical to use because of the lack of local file support.

I regularly load local files in my browser. E.g

file:///Y:/Webs/Sites/dev021/filename.html

but I am required to whitelist every single file...which just isn't practical at all. Furthermore, I also use a FF Addon called UnMHT and load the resulting .mht files in Firefox and each of these files also has to be whitelisted individually. E.g.

unmht:///file.5/M:/web archives/filename.mht

This really does need to be a rapid fix for RP for RP to be of any practical use to a lot of people. I am proposing option to:

* allow all local local files (localhost)
* allow all on a range of local IP addresses (e.g 127.0.0.1; 192.168.100.1/253)

Whatever way it is achieved, please could you add local support so that I can reenable RP.

Thankyou very much for your efforts. Much appreciated I would like to add.
Cheers / POC

[Justin Samuel]

@Natanael_L

You're definitely correct, some form of wildcards are needed, as well as a blacklist. Here are the related tickets (probably some dupe-age here).

wildcards:
https://www.requestpolicy.com/dev/ticket/9
https://www.requestpolicy.com/dev/ticket/63
https://www.requestpolicy.com/dev/ticket/8

blacklist:
https://www.requestpolicy.com/dev/ticket/6

In short, I'm quite sure I'll add wildcards in the not-to-distant future (that is, it's the next major feature when time allows features rather than bug fixes). However, the first pass is going to be pretty simple and will avoid regex or anything other than "allow subdomains from this level onward". The major reason for the simplicity is that regex has to be avoided for efficiency reasons in the common case and I need an efficient solution to make available in the menu. Later on I might add regex usage that users can enter through the preferences window.

The *.onion example is interesting because I hadn't thought of a usage scenario at the TLD level. I'll have to keep this in mind in terms of things people might want to whitelist.

@Privateofcourse

I'll need to take a look at UnMHT, but in terms of file://, this is fixed in 0.5.13 which is caught up a bit in AMO editor discussion. If you don't want to wait for AMO approval, you can look find 0.5.13 here:

https://addons.mozilla.org/en-US/firefo ... ion-0.5.13

This is the simple solution of treating file:// as the same origin/destination. Note that Gecko 1.9 (Firefox 3.0+) added restrictions of access between file:// locations, so it isn't completely open season when you run something from file://.

More info: https://developer.mozilla.org/en/Same-o ... le%3a_URIs

[Privateofcourse]

Thankyou very much, Justin. I have installed the update, and yes, nicely fixes the file:// issue.

I'll need to take a look at UnMHT

Excellent! Thankyou again. Look forward to that update.

Without UnMHT support in RP I have to use IE to view the files...and even though mht is of course a Microsoft format I'd much rather stick with Firefox and UnMHT

[ghostintheruins]

Hello,

Not sure if in the previous version this happened but with 0.5.13 after some time all the menu options just disappear if "temporarily allow all request is active", otherwise just the "allow from to" are available. The menu becomes just an empty thin square.

This happen both with the statusbar icon and with the tollbar-icon.

This phenomenon is rather "timed" - if I restart firefox (3.6) all the options are again available or they just "activate" / become available by themselves.

No related error message is given in the console.

It happened again and I could take a screenshot of it:

http://img638.imageshack.us/i/requestpolicymenubug.png/




Cheers

PS
I thought that this was related to certain theme but it did happen to at least 3 installed themes.

[magdev]

Hello,

Your RequestPolicy appears to be a nice add-on that I might want to use. However, contrary to what the GPL license is about (i.e. easy access to source code), there seems to be no way to download the source code.

The XPI release package itself is not open source as it contains some binary (or object) files, such as XPT.

The only way to see the source code is to "browse" it in the Trac system. However, it's practically impossible to download it from there.

Is there a way to download your source code that I missed? If there is not, can you put the source package online?

Thanks,
Paul