Per-Domain Whitelists

Bug reports and enhancement requests
Post Reply
d3fault
Posts: 6
Joined: Tue Jun 05, 2012 5:26 am

Per-Domain Whitelists

Post by d3fault »

Thank you for NoScript, I've been using it for many years now and love it.

I'd like to suggest a feature I thought up during my time using NoScript: basically, as the subject says, per-domain whitelists. If I browse to facebook.com on one tab, for example, I want my 'facebook.com' whitelist to allow facebook.com and fbcdn.net ...... but I do not want to allow other domains/tabs(unless they are also facebook.com) to load javascript from either of those domains.

Another Example:
There are a lot of cases where I have to grant google.com javascript access in order to make captchas work (there is javascript-less mode, but that's besides the point), but that doesn't mean I want to let every domain 'report in' to google, ya know? Even temporarily allowing access to google reloads every tab/domain with a reference to google.com.

Same with google-analytics... which I really only ever enable when viewing AdSense Administration (i think they fixed that dependency though. It was certainly there in the past).

Does this make sense? Has such a feature ever been requested before? Are there drawbacks that I'm not seeing?

I wonder if frames complicate things at all.... but I'd say just deny access for frames (or, I mean, use the global whitelist as usual)... and only allow 'per-domain whitelists' for the domain specifically in the URL bar.


It definitely adds more clutter to the already pretty full NoScript context menu, but eh nothing that can't be fixed by putting new/existing menu items in sub-menus etc.


Thanks for reading this and keep up the excellent work on NoScript,
d3fault
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Per-Domain Whitelists

Post by Giorgio Maone »

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
d3fault
Posts: 6
Joined: Tue Jun 05, 2012 5:26 am

Re: Per-Domain Whitelists

Post by d3fault »

Haha I suck. I've read about ABE before but never used it, thanks.

I guess the only request left that still remains is better UI integration. I'd prefer to see the ABE lists be the core functionality of NoScript (and also processed before a global whitelist), with adding domains [temporarily or not] to global whitelists tucked in some sub-menu.
^^I even remember reading about someone else requesting this functionality (although at the time... 5 minutes ago... I didn't know what ABE even did lol). So basically just +1 that guy's idea.

Even the middle mouse clicking on the noscript toolbar button (love this feature) to temporarily enable all could still do just that -- but only for the current domain.

Either way, the fact that the functionality already exists means you've done enough, so thank you very much Giorgio Maone for your continued efforts :-D

d3fault
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Per-Domain Whitelists

Post by Thrawn »

d3fault wrote:I guess the only request left that still remains is better UI integration
I'd like a visual interface too...want to help?
I'd prefer to see the ABE lists be the core functionality of NoScript (and also processed before a global whitelist), with adding domains [temporarily or not] to global whitelists tucked in some sub-menu.
^^I even remember reading about someone else requesting this functionality (although at the time... 5 minutes ago... I didn't know what ABE even did lol). So basically just +1 that guy's idea.

Even the middle mouse clicking on the noscript toolbar button (love this feature) to temporarily enable all could still do just that -- but only for the current domain.
It's true that ABE rules are very flexible, capable of mimicking most of NoScript's features, but are not usable enough to replace those features. They work fine for ABE's originally-intended purpose, though: protecting selected valuable sites against cross-site request forgery. You might want RequestPolicy?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
d3fault
Posts: 6
Joined: Tue Jun 05, 2012 5:26 am

Re: Per-Domain Whitelists

Post by d3fault »

Thrawn wrote:I'd like a visual interface too...want to help?
Would that be an additional add-on to install? Adding the RequestPolicy-like interface to the already existing NoScript extension sounds like a better plan... but it's nice to see some work being done in this area either way.
Thrawn wrote:It's true that ABE rules are very flexible, capable of mimicking most of NoScript's features, but are not usable enough to replace those features.
Not usable enough... yet.
Is there any reason NoScript couldn't phase out old-style whitelists in the future and replace them with ABE's more advanced rules? Wouldn't doing so make ABE not have to have it's own separate rules? I realize ABE rules brings new features to the table, but I don't think that would be a blocker for merging the two.

An import utility for NoScript that is shown during the transition to the newer rules method could inform user of new functionality of the changing of simple whitelists to the newer more powerful rules file (it should still be manually editable -- esp for those additonal ABE features), and then ask them to choose one of the following:
a) import their old whitelist (and set up the upgraded/merged rules for each whitelist item to re-add them globally (so the functionality does not change))
b) import their old whitelist in a manner that sets up the Rules to only allow domains to include from themselves (and perhaps sub-domains. this could be yet another option (d) too). adding in all the cross-domain inclusions would have to be done manually again (weird scenario, because you'll now have those previously-globally-whitelisted domains in your rules twice: once allowing inclusion from itself (auto-generated by (b), but serves no use as, for example, nobody ever directly browses to fbcdn.net)... and once more when you manually add inclusion to it for the domain that you originally globally-whitelisted it for)
c) start over from scratch <- doubt anyone would use it, but just in case

(b) is the option I would choose, but (a) is what someone who wants their functionality to remain unchanged could use ("Don't know what to click? Choose 'A' for the same functionality as you've always had"). This is stretching it a bit, but maybe even an options menu checkmark/boolean for 'add to rules as global by default'. Having it checked means NoScript functions how it does today (with per-domain adding tucked in sub-menu)... unchecked (new default?) means they add to Rules using a per-domain filter (global whitelist access in sub-menu, just the opposite).
^^ok now I'm really stretching it: choosing (a) enables the checkmark/boolean, (b) disables it. New installs default to disabled (this could lead to confusion, however... where a previously upgraded user that chose (a) would expect a new install of NoScript to use the global whitelist rules adding mode by default. It would need to be mentioned/clear in the context menu how you are adding the domain: "Global" vs. "Per-Domain", depending on the state of that checkmark/boolean in options).

I'd also think a mode 'allow domains to access/execute resources from themselves globally (dangerous)' would be pretty handy and save a lot of time when browsing.

d3fault
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Per-Domain Whitelists

Post by Thrawn »

d3fault wrote:
Thrawn wrote:I'd like a visual interface too...want to help?
Would that be an additional add-on to install? Adding the RequestPolicy-like interface to the already existing NoScript extension sounds like a better plan... but it's nice to see some work being done in this area either way.
Yes, it would be an additional addon, unless Giorgio decided to integrate it (he owns the code).
Thrawn wrote:It's true that ABE rules are very flexible, capable of mimicking most of NoScript's features, but are not usable enough to replace those features.
Not usable enough... yet.
Is there any reason NoScript couldn't phase out old-style whitelists in the future and replace them with ABE's more advanced rules? Wouldn't doing so make ABE not have to have it's own separate rules? I realize ABE rules brings new features to the table, but I don't think that would be a blocker for merging the two.
Hmm...theoretically it's possible, but I don't see the benefits as compared to what you can already do with ABE. If you want site-specific permissions, you can have them. Since Giorgio designed ABE primarily for CSRF protection, I doubt he'd go that route.

But have you read about NoScript 3.x for the desktop?

If you want control of cross-site requests, then I'd again suggest looking at RequestPolicy. A graphical front-end for ABE would basically be a better (more flexible and powerful) version of RequestPolicy.
I'd also think a mode 'allow domains to access/execute resources from themselves globally (dangerous)' would be pretty handy and save a lot of time when browsing.
Again, RequestPolicy does this. But if you want to do it with NoScript and ABE, then try Options-'Temporarily allow top-level sites by default' and:

Code: Select all

Site *
Accept from SELF++
Sandbox GET
Deny
so that links still work, but without risk of XSS. You could also add a similar SYSTEM rule, but using Anon instead of Sandbox, so that CSRF is blocked too.

And get ready to add lots of exceptions...
NB Don't just add sites to the Accept lines in the above rules, unless you trust those sites to send any request. You'd do better to craft individual rules to make sites work in a protected fashion, and place them higher in the rule set, so that they run first. There are some examples in another thread.

Intimidated yet? This is why I want RequestPolicy's interface.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Post Reply