Page 10 of 12
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 4:55 pm
by al_9x
Giorgio Maone wrote:Still I can't understand how ABE doesn't suffice for a power user with this kind of needs.
Please name a policy which cannot currently be expressed by ABE grammar, in one or more chained rules.
I think I already explained it, but will try again. As sites/apps grow more complex (composed), they tend to require various cross site utility iframes and plugins for normal operation. So whereas you want maximum embedding blocking in general, for specific, trusted, frequently accessed sites, you need to loosen permissions for specific (types and locations) embeddings to avoid constant fiddling with temp permissions upon every visit.
ABE is not capable of loosening embedding permission, only tightening. If the default is to block everything even on trusted, which is what it should be, no abe rule can currently, AFAICT, express an exception to it. I am all for doing it in ABE, but to do it at all and in a reasonably friendly manner, you would need something like this:
Code: Select all
Origin site1
Accept embedding(IFRAME, FLASH) to site2
Alternatives to "origin":
From site1
On site1
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 5:12 pm
by Giorgio Maone
For doing it the ABE way, uncheck
NoScript Options|Embeddings|Apply these restrictions to trusted sites as well, and put the following at the bottom of your USER ABE ruleset:
Then you can insert your fine-grained exceptions
before the deny rule:
Code: Select all
Site trusted-widgets.com
Accept from *
Site .youtube.com
Accept from .youtube.com .ytimg.com
Site .google.com
Accept from .google.com
and so on.
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 5:25 pm
by al_9x
This "solution" is extremely unfriendly, it kills placeholders, the blocked objects menu, the embeddings icon feedback, requires fiddling with rules for every unblocking. This solution is more painful than the problem, no one is going to do this.
On the other hand this:
Code: Select all
On site1
Accept embedding(IFRAME, FLASH) to site2
is very intuitive and completely non-disruptive.
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 5:32 pm
by Giorgio Maone
Placeholders and one-click permissions don't belong in ABE.
I believe your user-friendly use case would be better served by giving persistence to the current embedding allowance options (e.g.
Allow shockwave-flash@widgets.com from site.com), which is coming as a side benefit of the E10s/Mobile porting project.
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 6:13 pm
by al_9x
Giorgio Maone wrote:I believe your user-friendly use case would be better served by giving persistence to the current embedding allowance options (e.g.
Allow shockwave-flash@widgets.com from site.com), which is coming as a side benefit of the E10s/Mobile porting project.
How do you plan to express the rules and persist them? It would be nice if they could be viewable and editable, and have some flexibility, which is why I suggested ABE-like syntax, which I thought would be more useful than a long space delimited string of rigid rules:
Code: Select all
noscript.persisted_embeddings_permissions="iframe@www.site1.invalid,www.site2.invalid application/x-shockwave-flash@www.site1.invalid,www.site2.invalid"
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 6:34 pm
by al_9x
Giorgio Maone wrote:Placeholders and one-click permissions don't belong in ABE.
True, ABE was intended for network request blocking, but is there any reason why it shouldn't be extended to also control other aspects of NS behavior? In fact, doesn't it do so already? The Sandbox action doesn't modify the request but instructs NS about the permissions of the retrieved page. Is that so different than rules for embedding permissions?
Re: Discussion: Site Specific Permissions Policy
Posted: Mon Feb 07, 2011 6:47 pm
by dhouwn
al_9x wrote:but is there any reason why it shouldn't be extended to also control other aspects of NS behavior?
Maybe because the plan on making ABE into a separate extension (and preferably a slim one I would guess) still stands?
Giorgio, can you please confirm whether that's true?
Re: Discussion: Site Specific Permissions Policy
Posted: Tue Mar 01, 2011 2:00 pm
by tlu
Giorgio Maone wrote:Placeholders and one-click permissions don't belong in ABE.
And they don't need to, IMHO. For example, in the "Embeddings" tab I've checked "Apply these restrictions to whitelisted sites too" in order to mitigate java/flash related risks. This means, of course, that, e.g, java is blocked on whitelisted sites, and in the Noscript menu there is an entry "temporarily allow java-vm@..." under "Blocked objects" . Wouldn't it be a good idea to add an entry "always allow ..." for objects? I understand that this would result in several whitelists, but I think this would be an excellent improvement for advanced users who want to use this feature.
I believe your user-friendly use case would be better served by giving persistence to the current embedding allowance options (e.g.
Allow shockwave-flash@widgets.com from site.com), which is coming as a side benefit of the E10s/Mobile porting project.
I'm sorry, but what is the E10/Mobile porting project?
Re: Discussion: Site Specific Permissions Policy
Posted: Tue Mar 01, 2011 2:05 pm
by Giorgio Maone
tlu wrote:I'm sorry, but what is the E10/Mobile porting project?
http://noscript.net/nsa/
Re: Discussion: Site Specific Permissions Policy
Posted: Tue Mar 01, 2011 2:33 pm
by tlu
Ah, thanks - very interesting!
Re: Discussion: Site Specific Permissions Policy
Posted: Sun Mar 06, 2011 12:52 pm
by F-3000
I must say that I hunger for option to "allow some site on some domain only (untrust elsewhere)". For example, I would like to have it so that facebook.com is allowed at that site, yet denied everywhere else. Two reasons: I don't trust them, and I don't like the FB "like this" crap. I wouldn't want to be backstabbed by something by permanently allowing it, only to find out later that it screwed me as 3rd party stuff.
If that feature appears quickly, I definitely would make a donation.
Re: Discussion: Site Specific Permissions Policy
Posted: Sun Mar 06, 2011 1:22 pm
by Giorgio Maone
F-3000 wrote:I must say that I hunger for option to "allow some site on some domain only (untrust elsewhere)". For example, I would like to have it so that facebook.com is allowed at that site, yet denied everywhere else. Two reasons: I don't trust them, and I don't like the FB "like this" crap.
Did you actually check
this FAQ first?
Re: Discussion: Site Specific Permissions Policy
Posted: Sun Mar 06, 2011 1:32 pm
by F-3000
Giorgio Maone wrote:Did you actually check
this FAQ first?
I didn't, thank you for pointing that out. Yet, I dearly hope that's not the final solution, because if it is, I invite YOU to teach my girlfriend how to use it.
[EDIT]
Plus, it is very clumsy, and you keep getting those "Request {...} filtered by ABE <...> Deny" (raw translation) notifictations that appear every single time you browse on a site that triggers it.
I don't want to sound rude, I'm just pointing this out.
I would be very happy and utterly satisfied, if the "ABE"-way would be like: You could add permanent allow on specific site with a click or two as it is with current main-way of allow/deny, and it wouldn't produce those notifications - or at least you could control (like time limiting) them as you can do with the ordinary info-strip.
Then, I would use it as my main way of allowing/denying sites' javascript.
This question is a bit OOT, but I'm eager to have an answer to this: Is it better to have NoScript with "allow js to all" than no NoScript at all?
tool-tip showing needed permission?
Posted: Mon Jun 06, 2011 7:36 pm
by dushanm
I'm using NoScript with Firefox under Mac OS X.6.5.
One thing I've found frustrating is not knowing which of possibly many blocked sites needs (or need) to be unblocked to access a particular link. Clicking on the NoScript Options button of the browser brings up a list of blocked sites for the page being viewed (and more frustratingly this is often a multi-nested list) but generally I have no clue which of these should be Allowed to let me get to the desired link.
If there's an NS Preferences option to reveal this information, I've not recognized it. Does such an option exist? If not, is it feasible to incorporate it into NoScript?
- Dushan
Re: Discussion: Site Specific Permissions Policy
Posted: Sat Jun 11, 2011 4:24 pm
by tlu
al_9x wrote:This "solution" is extremely unfriendly, it kills placeholders, the blocked objects menu, the embeddings icon feedback, requires fiddling with rules for every unblocking. This solution is more painful than the problem, no one is going to do this.
On the other hand this:
Code: Select all
On site1
Accept embedding(IFRAME, FLASH) to site2
is very intuitive and completely non-disruptive.
As long as Noscript 3 isn't available yet, there is a workaround using AdblockPlus. If you want to block flash by default just add this custom filter:
swf|
In order to create a whitelist you just have to right-click the ABP symbol, chose the list of blockable items, select the rule that blocked flash on the respective site and create an exception rule. This is relatively easily done for the trusted sites which you visit regularly, like youtube. For any other sites where you would want to see flash videos, you could temporarily disable ABP by middle-clicking its symbol. If you replace above rule with
$object
any content handled by plugins is blocked, including java. However, ABP shows a snail for this rule indicating that it's slow/inefficient.
Again, this is only a temporary workaround which is probably a bit easier for many users than specific ABE rules.