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

[Justin Samuel]

My question is whether it is possible to provide a "default allow" mode, i.e. all requests would be allowed by default and only those added as denied would be blocked. I find it very time-consuming to add allowed requests for each and every site. I would prefer simply marking several known sites as blocked and allowing others to be passed by.

I don't rule out making something like this available someday, and I'm sure there are others interested in it, but I'd probably just make it a separate extension. And, the honest truth is that I don't think I'll get "done" enough with RequestPolicy to work on that. However, I'll happily advise anyone interested in forking RequestPolicy (though, they might want to wait a while longer until it's a bit more feature-complete and has had more people using it to find bugs, etc.).

[Nivekian]

Apparently it stops stumbleupon from working also.

[Justin Samuel]

Apparently it stops stumbleupon from working also.

Hi, sorry you thought RequestPolicy broke stumbleupon.com. I'm not a stumbleupon user, but I tried it and it looks like it's working exactly how it's intended to. When I first arrived at stumbleupon.com, I had to whitelist requests from stumbleupon.com to stumble-upon.com (with a hyphen) to see thumbnails on the home page. Then, when I click on one of the items on the page to see it, it appears that stumbleupon provides a framed view of the page. This frame requires a cross-site request from stumbleupon.com to whatever the url of the frame is (that is, the url of the content you are trying to view through stumbleupon).

In this case, to use a site like stumbleupon's "WebToolbar", as they call it, which is based around cross-site framed content, you may just want to allow all requests originating from stumbleupon.com (which is the option at the bottom of the menu).

The same kind of thing happened when digg started using their diggbar (same exact idea as stumbleupon's WebToolbar, it looks like) as it worked the same way: kept you at the digg site but gave you a frame to the other content. Happily for RequestPolicy, many Digg users found it horrible and Digg does not have that as a default anymore. I don't know enough about stumbleupon to know if what you're seeing is new behavior or if stumbleupon has always worked this way.

Thanks for using RequestPolicy. I hope this hasn't discouraged you! I think it's much better to have a small number of sites like stumbleupon where you allow allow requests from that origin domain if the alternative is to choose not to use RequestPolicy at all because of needing to allow a specific origin-to-destination for every item you try to view at a site like stumbleupon.

[SeaLion]

Justin, first congrats on the addon. I like it very much, make that clear. Now for some constructive criticism
These are things that you're probably planning, but i just want to lay them down here to be sure. These are usability issues.

I was just reading this blog post,
http://broadcast.oreilly.com/2009/07/is ... o-kil.html ,
and allowing it was a pain. 3 things would help, all should be added imho:
1- like NS, an option (on by default) to not refresh immediately after i allow something. Only after i click outside the menu.
2- wildcards, wishlisted no doubt. *oreilly.com to *oreilly.com
3- not so sure of the exact and proper way for this one note. Or even if i'd still want it after discussion. Allow requests from/to the same domain by default. This raises problems, since it's not always as simple as oreilly. But to start, that option not enabled by default perhaps makes sense?

A 4th not related, the blacklist, wishlisted no doubt. It allows us to deny what we already know we don't want, and suppress it from the menu.

Thank you for RP, and good luck with RP's development!

[SeaLion]

Damn i feel dumb. I just found your Feature Requests page..

[Justin Samuel]

SeaLion, don't feel dumb, it just turns out that you have a good and quick eye for necessary features. :)

I've been a bit slow in getting to adding these features because it's been an extremely busy summer for me. However, in a couple of weeks I should be starting a fresh round of feature work.

And to help people find it, here's a list of all open bug reports and feature requests: https://www.requestpolicy.com/dev/report/1

[Aus]

Hi, new user of RequestPolicy here and it's great. I do have one problem, however. I noticed from your 'conflicts with other extensions' link that there are problems with sage-too and newsfox, I'm afraid there are similar issues with brief, another RSS reader. Basically, with RP enabled all images in the feeds are blocked, with it disabled images are available.

I know there's a suggestion to white list sites but when I tried that, I couldn't get it to work. Plus with a large number of feeds it's just nor practicable. I really hope this is something that can be looked at in the near future.

I would have posted this on Trac but when I tried to register I get:

The password file could not be updated. Trac requires read and write access to both the password file and its parent directory.

Thanks

[guanxi]

In the preferences, what does "Strictness" mean? I can think of a couple possible interpretations. Sorry if you already answered this question; I looked at requestpolicy.com and in this thread, but didn't see it addressed.

I just installed it. It looks like a great idea.

Thanks.

[Justin Samuel]

Hi, new user of RequestPolicy here and it's great. I do have one problem, however. I noticed from your 'conflicts with other extensions' link that there are problems with sage-too and newsfox, I'm afraid there are similar issues with brief, another RSS reader. Basically, with RP enabled all images in the feeds are blocked, with it disabled images are available.

I've created a ticket for this here:

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

I'm just coming down off of a very busy few months, so I plan to address these extension conflicts soon (within a few weeks, that is).

I would have posted this on Trac but when I tried to register I get:

The password file could not be updated. Trac requires read and write access to both the password file and its parent directory.

Ah, thanks, I didn't realize it needed write permission to that file's parent directory. It should work now in case you want to subscribe to that ticket or create tickets about other bugs/conflicts/enhancements.

Thanks for the conflict report and letting me know about this Trac configuration problem.

[Justin Samuel]

In the preferences, what does "Strictness" mean? I can think of a couple possible interpretations. Sorry if you already answered this question; I looked at requestpolicy.com and in this thread, but didn't see it addressed.

I just installed it. It looks like a great idea.

Thanks.

Thanks, I'm glad you like it. I think it's quite good currently but that RequestPolicy will become great in the next six months or so.

"Strictness" refers to how RequestPolicy determines whether a host where content is requested from is a different site than the current one (that is, it would be a cross-site request) or whether it is for content from the same site as the current site. For example, with the default strictness of "registered domain", these are considered the same site by RequestPolicy:

http://example.com:8080
http://www.example.com
https://www.example.com

This is because they all have the same registered domain name, example.com.

You can instead change it so it considers those different sites and so requires that they be whitelisted because of different hosts in the url (example.com vs. http://www.example.com) or even because of differences in protocols/ports, as well.

Let me know if that isn't clear. I need to actually create a wiki page to describe this better. I'm in a hurry at the moment, so I've created a ticket for this (https://www.requestpolicy.com/dev/ticket/30) so that I don't forget.

[guanxi]

That makes sense to me. You might be able to save documentation by writing the dialog a little differently. For example, it could say:

If you tell RequestPolicy to allow connections for a webpage (e.g., "http://www.example.com/index.htm"), RequestPoilcy will also also allow connections to,
(*) Anything in the same domain (e.g. also allow images.example.com, example.com:8080, https://example.com)
( ) Anything with the same hostname (e.g., allow http://www.example.com, but not images.example.com)
( ) Nothing else. RequestPolicy will only allow connections for the exact same address (i.e. allow http://www.example.com/index.htm, but not http://www.example.com/about.htm or anything else on the website)

My wording might not be quite right, and probably could be improved, but that's the rough idea.

[guanxi]

RequestPolicy is working well for me, thank you again. I thought you might be interested in a minor bug I encountered: I visited politicsdaily.com. After enabling requests to domains one at a time (I wish I knew which ones, to make the problem easier to reproduce; they were mostly domains ending in *cdn.com), I ended up in a situation where aol.com was listed in three places:
- Blocked destinations
- Allowed destinations
- Other origins within this page (where politicsdaily.com was both blocked and allowed there)

I tried allowing aol.com repeatedly, and under Other Origins I tried allowing poilticsdaily.com. but the state above would not change. I finally selected "Temporarily allow all requests", which worked. Now, after unchecking 'allow all' and returning to politicsdaily.com, the problem is gone.

The workaround was obvious and easy, but I thought you might be interested in knowing about the problem. Thanks again.

guanxi

[Tobu]

Like guanxi, I have some domains appear both whitelisted and forbidden, and can't change them. This is with 0.5.8.

[A`ja]

FYI: 0.5.8 breaks opening of new tabs (via context menu, or otherwise) with latest trunk nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090915 Minefield/3.7a1pre ID:20090915053258

I get the following in Console2:
Error: '[JavaScript Error: "uri is null" {file: "file:///C:/Documents%20and%20Settings/Aja/Application%20Data/Mozilla/Firefox/Profiles/y5aydfee.central/extensions/requestpolicy@requestpolicy.com/modules/DomainUtil.jsm" line: 186}]' when calling method: [nsIRequestPolicy::registerLinkClicked] = NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS
Source file: chrome://requestpolicy/content/overlay.js
Line: 844

which refers to this line:
this._rpService.registerLinkClicked(referrerUri.spec, tabUri);

This was reported in firefox builds forum here:
viewtopic.php?p=7522705#p7522705

Edit: filed as https://www.requestpolicy.com/dev/ticket/38

[Justin Samuel]

RequestPolicy is working well for me, thank you again. I thought you might be interested in a minor bug I encountered: I visited politicsdaily.com. After enabling requests to domains one at a time (I wish I knew which ones, to make the problem easier to reproduce; they were mostly domains ending in *cdn.com), I ended up in a situation where aol.com was listed in three places:
- Blocked destinations
- Allowed destinations
- Other origins within this page (where politicsdaily.com was both blocked and allowed there)

Thanks for reporting this. I've created a ticket for it here: https://www.requestpolicy.com/dev/ticket/37

(And sorry for the slow reply.)