RequestPolicy 1.0.0a7 released

Showing 1-13 of 13 messages
RequestPolicy 1.0.0a7 released Justin Samuel 4/16/12 11:19 AM
RequestPolicy 1.0.0a7 has been released. This includes the following changes:

* Links from view-source pages now work.
* When the menu is opened through the keyboard shortcut, it is placed
better when the Firefox window is not maximized.

Justin

Re: RequestPolicy 1.0.0a7 released aaaa 4/18/12 2:14 PM
Some sort of 'blacklist' functionality would be nice, to hide items that appear often and need blocking. This would in many cases save user the trouble of manually searching through all 10+ analytics/advertising domains. Something like NoScript's Untrusted functionality.
Re: RequestPolicy 1.0.0a7 released Justin Samuel 4/18/12 2:24 PM
It's likely that a future 1.x version grows an "ignored destinations"
feature. Basically, destinations that wouldn't turn the flag icon red
when blocked and maybe would be grouped together in the UI.

For purposes of clarity, this isn't a blacklist in our terminology.
RequestPolicy 1.0 supports blacklists in terms of "block" (deny) rules
that are mostly useful when using the default-allow policy. So,
RequestPolicy 1.0 has both whitelists and blacklists but these aren't
related to ignoring indications of blocked requests.

For reference, the "untrusted"/"ignored" feature is good ol' ticket #1:

https://github.com/RequestPolicy/requestpolicy/issues/1

Justin

> --
> You received this message because you are subscribed to the Google Groups
> "RequestPolicy discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/requestpolicy-discuss/-/FYGpJvZK_qkJ.
> To post to this group, send email to requestpol...@googlegroups.com.
> To unsubscribe from this group, send email to
> requestpolicy-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/requestpolicy-discuss?hl=en.

Re: RequestPolicy 1.0.0a7 released John Perdikis 4/20/12 10:35 AM
Thank you Justin, you're building a great addon here.

Is there any way to allow all requests from a specific webpage (not domain) eg. when I read articles in google reader i have to allow images/videos etc from the originating website.

I suppose we can't allow requests from something like this: "https://www.google.com/reader/*", right?


Re: RequestPolicy 1.0.0a7 released Justin Samuel 4/20/12 11:10 AM
On Fri, Apr 20, 2012 at 10:35 AM, John Perdikis wrote:
> Thank you Justin, you're building a great addon here.

Thanks. Positive feedback is always appreciated.

> Is there any way to allow all requests from a specific webpage (not domain)
> eg. when I read articles in google reader i have to allow images/videos etc
> from the originating website.
>
> I suppose we can't allow requests from something like this:
> "https://www.google.com/reader/*", right?

Having rules be able to include a path element (e.g. path prefix
"/reader/") is a planned feature in 1.x. When creating the new rule
system used in 1.x, I made sure that this could be supported. The big
question at the moment is when I'd have the couple of days I'd need to
implement and test this. Right now a couple of days is hard to find.

In a few weeks I'll have a much better idea of how much time I'll have
for RequestPolicy over the next six months. That's going to be a big
factor in how many features make it into 1.x this year.

Justin

Re: RequestPolicy 1.0.0a7 released Wacław Jacek 4/21/12 3:27 AM
When I click a box next to a preference name, it checks the box, but when I switch to another tab of the preferences page and then back, it's back to default. How can I help find out what causes this?


Take care,
Wacław Jacek
Re: RequestPolicy 1.0.0a7 released 61473 5/17/12 7:51 AM
Thanks for pointing me to this dev build, Justin.
I have a number of ideas, comments and questions that came to mind while using the alpha build yesterday.

  • When opening the Request Policy icon menu from the addons bar in Firefox I saw that it allows you to access many pages in the addon settings tab (Preferences, Manage Policies, Help, About, etc). Each time someone clicks one of these links a new tab will open, showing the desired page. Perhaps make it so that only a single "options" tab can be opened at a time. Make the program check whether a settings tab is already open and change it to reflect the page that the clicked link points to. Also, the icon menu should probably close automatically whenever one of these links is clicked. It currently stays open.
  • When you move your mouse cursor over an item in the icon menu, it gets highlighted. Make the background of these highlighted items a bit darker. I am unsure whether this is addon-related or it's just my system theme, but on my LCD screen on Arch Linux I can barely see the highlight box.
  • Perhaps add a greetings screen that appears the first time firefox is opened after the addon has been installed. Have the users choose whether they want deafult-allow or default-deny policy. Also, have them choose whether or not to use subscriptions. You could add a bunch of other initial settings in here too.
  • The settings UI: I saw this option in the setting "Indicate blocked images" Does this only indicate blocked images or does it apply to other objects as well? Flash, Java, Silverlight, etc? Perhaps consider blocking and adding a placeholder for these objects too? Rename the option to "Indicate blocked objects".
  • The settings UI: In the "Your Policies" tab you could move the "Allow" radiobutton, "Block" radiobutton and "Temporary" checkbox into a single line.
  • The settings UI: Maybe add a new "Enabled" checkbox that toggles all subscriptions on/off at once. Is there a way to view the rules for these subecriptions? Should subscriptions be enabled by default?
  • The ability to block/allow multiple destinations before the page reloads = WIN!!!
  • For deny by default policy: There should be a way to add a default-blocked destination to the blacklist in the icon menu. Currently you have to first allow the destination so that the menu item appears that lets you block it permanently.
  • The current tab in the "Your Policy" page only lists the policies, but won't let you change them. You have to remove an existing one and add a new policy. Users should be able to edit the policies in place.
  • In the icon menu perhaps there should be some way to differ between items blocked/allowed by default and items in the white/blacklist. Perhaps make the permanently blocked/allowed items appear bold.


There, that's about it. I hope I wasn't being too harsh. ;)

Re: RequestPolicy 1.0.0a7 released Justin Samuel 5/17/12 2:20 PM
On Sat, Apr 21, 2012 at 3:27 AM, Wacław Jacek wrote:
> When I click a box next to a preference name, it checks the box, but when I
> switch to another tab of the preferences page and then back, it's back to
> default. How can I help find out what causes this?

(Sorry for the delayed response. Life is comically busy, as always.)

Is it possible you have scripts disabled in Firefox? The new
preferences pages rely very heavily on JavaScript to populate them as
well as to save changed values.

Justin
Re: RequestPolicy 1.0.0a7 released Justin Samuel 5/17/12 3:09 PM
On Thu, May 17, 2012 at 7:51 AM, 61473 wrote:
> Thanks for pointing me to this dev build, Justin.
> I have a number of ideas, comments and questions that came to mind while
> using the alpha build yesterday.

Thanks for trying it out despite its alpha status.

> When opening the Request Policy icon menu from the addons bar in Firefox I
> saw that it allows you to access many pages in the addon settings tab
> (Preferences, Manage Policies, Help, About, etc). Each time someone clicks
> one of these links a new tab will open, showing the desired page. Perhaps
> make it so that only a single "options" tab can be opened at a time. Make
> the program check whether a settings tab is already open and change it to
> reflect the page that the clicked link points to.

The problem with this is that if a user has unsaved changes on the
currently open preferences tab, they would be lost if a new
preferences page is loaded there. At the moment this wouldn't be too
big of a risk because most preferences are being saved immediately
(that's why there's no save button). I do like the idea and I'll give
this some more thought.

> Also, the icon menu should
> probably close automatically whenever one of these links is clicked. It
> currently stays open.

That's a good idea, thanks.

> When you move your mouse cursor over an item in the icon menu, it gets
> highlighted. Make the background of these highlighted items a bit darker. I
> am unsure whether this is addon-related or it's just my system theme, but on
> my LCD screen on Arch Linux I can barely see the highlight box.

I probably do need to tweak the colors a bit but I also intend them to
be pretty faint. In the coming months I'll try it out on more
monitors.

I think there is also a bug which is causing the grey background to be
either too light or too dark on certain systems. I noticed that once
but haven't have time to look into it yet.

> Perhaps add a greetings screen that appears the first time firefox is opened
> after the addon has been installed. Have the users choose whether they want
> deafult-allow or default-deny policy. Also, have them choose whether or not
> to use subscriptions. You could add a bunch of other initial settings in
> here too.

You're completely right about this. This is one of those things I
meant to have done before I released the first public alpha but I just
didn't want to wait any longer. I'll get to this some time this
summer.

The initial setup window is going to be very simple, though. It
probably won't give options for subscription management. The goal is
to get out of the user's way as quickly as possible. Maybe there will
be a button for "advanced setup" or something in a corner which will
tell the user about subscriptions and such.

> The settings UI: I saw this option in the setting "Indicate blocked images"
> Does this only indicate blocked images or does it apply to other objects as
> well? Flash, Java, Silverlight, etc? Perhaps consider blocking and adding a
> placeholder for these objects too? Rename the option to "Indicate blocked
> objects".

It only applies to images. Placeholders for other blocked objects
could be useful but it's nearly impossible for me to justify spending
time on that. I might be able to revisit this some time after 1.x has
been released to all users, but I'm inclined to think this will only
happen with someone contributing a patch.

> The settings UI: In the "Your Policies" tab you could move the "Allow"
> radiobutton, "Block" radiobutton and "Temporary" checkbox into a single
> line.

What's currently there was just a quick hack and it might change a
lot. But, yeah, it would make sense to put "allow/block" on the same
line. I don't know about "temporary".

> The settings UI: Maybe add a new "Enabled" checkbox that toggles all
> subscriptions on/off at once. Is there a way to view the rules for these
> subecriptions? Should subscriptions be enabled by default?

I doubt I'll add more UI complexity to save having to uncheck those
boxes. If there ends up being dozens of checkboxes, I'd probably add
this.

It's very likely I'll be adding more subscription-related preferences.
For example, users might want subscriptions but not want them
automatically updated. And there may end up being a global
enable/disable for subscriptions (rather than a way to disable each
one).

Subscriptions will definitely be enabled by default, though. One of
the goals of 1.x is to make RequestPolicy as easy to use for the
majority of users (case in point: adding a "default allow" mode).

> The ability to block/allow multiple destinations before the page reloads =
> WIN!!!

Awesome, I'm glad that's working as desired.

> For deny by default policy: There should be a way to add a default-blocked
> destination to the blacklist in the icon menu. Currently you have to first
> allow the destination so that the menu item appears that lets you block it
> permanently.

I doubt I'll add the ability to enter rules manually through the menu.
That seems like too much UI complexity which is only useful to a very
small number of users. I think a better long-term solution will be
user-maintained or community-maintained subscriptions. e.g. you could
maintain your own subscriptions and the first thing you do in a new
firefox profile with RP is add your own subscriptions.

> The current tab in the "Your Policy" page only lists the policies, but won't
> let you change them. You have to remove an existing one and add a new
> policy. Users should be able to edit the policies in place.

Not a bad idea, but the time required to do that and the extra
complexity doesn't seem worth it at the moment. As you've noticed,
right now every possible enhancement runs through the "is this going
to help me get 1.0 launched?" filter. That's part of why the 0.5
branch is getting so little love: the only way I can make any progress
on 1.0 is to ignore everything but major bugs in 0.5. Similarly, the
only way I can make progress on getting 1.0 released is to ignore a
lot of things that would be nice but aren't critical.

> In the icon menu perhaps there should be some way to differ between items
> blocked/allowed by default and items in the white/blacklist. Perhaps make
> the permanently blocked/allowed items appear bold.

It takes a lot of convincing for me to want to add additional visual
hints because these generally don't mean anything to most users. For
example, I've received a few requests over the years for additional
flag icon colors to represent different things. I generally dislike
all of those ideas. I want simpler UIs, not more complicated ones.
However, after 1.0 is launched I do intend to consider various
advanced menu options that are disabled by default. Maybe this can be
one of them.

> There, that's about it. I hope I wasn't being too harsh. ;)

Not too harsh at all. Hopefully my answers aren't, either.

Thanks for taking the time to provide feedback and suggestions.

Justin
Re: RequestPolicy 1.0.0a7 released 61473 5/18/12 2:10 AM
Hey, thanks for the reply.


> For deny by default policy: There should be a way to add a default-blocked
> destination to the blacklist in the icon menu. Currently you have to first
> allow the destination so that the menu item appears that lets you block it
> permanently.

I doubt I'll add the ability to enter rules manually through the menu.
That seems like too much UI complexity which is only useful to a very
small number of users. I think a better long-term solution will be
user-maintained or community-maintained subscriptions. e.g. you could
maintain your own subscriptions and the first thing you do in a new
firefox profile with RP is add your own subscriptions.

Eh, I'm not sure we understood each other here. I'm not asking you to add a textbox, listbox or anything similar (where a user has to manually type in or edit the rules) to the icon menu. If your default policy is block then you will only be able to add items to a whitelist, but not the blacklist (and vice-versa). I'm asking you to add an option to the icon menu that will let users add requests to blacklist and/or whitelist regardless of the current default policy.

Example:
- Set your request policy to deny-by-default.
- Go to http://2020ok.com
- Click the request policy icon to bring up the menu.
- You will notice a number of requests being blocked on the left side of the menu. One of them will be "msn.com".
- Now I would like to add this "msn.com" to my blacklist. So I click it to bring up the submenu on the right part of the popup.
- I only see four items:

Allow requests from *.2020ok.com to *.msn.com
Temporarily allow requests from *.2020ok.com to *.msn.com
Allow requests to *.msn.com
Temporarily allow requests to *.msn.com

But there are no items in here to add these requests to a blocklist. I want the block-equivalents of these items to appear in the same menu. Currently if I want to permanently block the request I have to:

- Click the "Temporarily allow requests from *.2020ok.com to *.msn.com" option
- Click outside the menu to refresh the page
- Bringup the icon menu again. This time ksn.com will appear green. Click it.
- Choose the "Block all requests to *.msn.com" option
- Click outside the menu to refresh the page

I't a bit annoying having to take this detour.
 
> The current tab in the "Your Policy" page only lists the policies, but won't
> let you change them. You have to remove an existing one and add a new
> policy. Users should be able to edit the policies in place.

Not a bad idea, but the time required to do that and the extra
complexity doesn't seem worth it at the moment. As you've noticed,
right now every possible enhancement runs through the "is this going
to help me get 1.0 launched?" filter. That's part of why the 0.5
branch is getting so little love: the only way I can make any progress
on 1.0 is to ignore everything but major bugs in 0.5. Similarly, the
only way I can make progress on getting 1.0 released is to ignore a
lot of things that would be nice but aren't critical.


It's no problem, I merely wanted to share a few ideas for features that might appear in the future.

 
> In the icon menu perhaps there should be some way to differ between items
> blocked/allowed by default and items in the white/blacklist. Perhaps make
> the permanently blocked/allowed items appear bold.

It takes a lot of convincing for me to want to add additional visual
hints because these generally don't mean anything to most users. For
example, I've received a few requests over the years for additional
flag icon colors to represent different things. I generally dislike
all of those ideas. I want simpler UIs, not more complicated ones.
However, after 1.0 is launched I do intend to consider various
advanced menu options that are disabled by default. Maybe this can be
one of them.


Well I am an advanced user, so that might explain it. I do prefer to manage my own policies over subscriptions, so sometimes the menu gets clogged up with many blocked and many allower requests. I have to click on each one of them to find out whether there is a permanent rule already in place. I thought a way to distinguish between temporary and permanent rules in the left frame of the icon menu would be nice.

 
> There, that's about it. I hope I wasn't being too harsh. ;)

Not too harsh at all. Hopefully my answers aren't, either.

Thanks for taking the time to provide feedback and suggestions.

Justin


I came up with a bunch more suggestions yesterday while playing with the request log.

  • The request log should have an option to enable/disable it while the frame is open. Currently it gets automatically enabled when opened. but you can't disable it to review the requests. Some websites continuously poll the servers and requests keep flowing.
  • Firefox per-tab request logs?
  • Request log sorting doesn't seem to work yet.
  • Maybe add some options to the right-click menu so that it lets you (temporary) allow/block the currently selected tiem in the request log.
 That's about it. I'll post some more comments/ideas, if I think of any.


Re: RequestPolicy 1.0.0a7 released 61473 5/18/12 3:03 PM
I think I found a bug. Sometimes the blocked images are replaced by a placeholder despite that the destination where the images are located is allowed. I'm using the deny-by-default policy and subscriptions under the "Usability" group are disabled. The "Browser" group is fully enabled. Requests to the same domain are allowed.

I noticed this happening multiple times on various websites, but the most recent one was http://www.trillian.im. When I restart firefox, the bug is gone and I am unable to reproduce it. Here's what happened: I was browsing a lot of websited and ended up on the trillian website. Having the deny-by-default policy, I noticed that almost all images are blocked (saw placeholders). So I clicked the icon menu and tried to allow the cachefly.net domain where the images are located. Upon opening the icon menu, I noticed that the cachefly.net domain was listed under the "Mixed destinations" group and its color was orange. I have no idea how it managed to get there, but clicking on it opened all possible menu items. If I recall correctly there were 8 total... (Temporary) Allow requests from trillian to cachefly, (Temporary) Allow requests to cachefly, and the 4 block equivalents. Clicking on either had no effect. Despite having fully allowed the domain, it still appeared orange under mixed destinations, and the images didn't load even after multiple page reloads.

After restarting FF the cachefly.net domain now appears red under blocked destinations. When I allow requests to cachefly, the images load properly.


Re: RequestPolicy 1.0.0a7 released Wacław Jacek 5/19/12 5:06 AM
Justin Samuel wrote:
> On Sat, Apr 21, 2012 at 3:27 AM, Wacław Jacek wrote:
>> When I click a box next to a preference name, it checks the box, but when I
>> switch to another tab of the preferences page and then back, it's back to
>> default. How can I help find out what causes this?
>
> Is it possible you have scripts disabled in Firefox? The new
> preferences pages rely very heavily on JavaScript to populate them as
> well as to save changed values.
>

I can hardly tell at this point. I have started using vanilla Firefox (I
was using GNU IceCat earlier) and I think it's working now.


Take care,
WJ
Re: RequestPolicy 1.0.0a7 released 61473 5/23/12 8:16 AM
Buuuuump!

Another bug. Magnet links do not work properly (Firefox 12.0, Arch linux, requestpolicy 1.0.0a7, block by default policy). Go to website like http://thepiratebay.se/torrent/7218806/Ubuntu-12.04-desktop-i386.iso and click on the magnet link (GET THIS TORRENT). The link does not get passed to the appropriate download application. I found out that you can still pass on the link by triple-clicking it quickly.

With requestpolicy addon disabled, magnet links work properly.