Page 1 of 2

Tree Format Domain Access

Posted: Sun Mar 20, 2016 10:54 am
by treehouse
Possible to have a "Tree Layout" for the sites that are coming from the same domain or related to the same service?

For example: To use Gmail (assuming scripts are forbidden), when a user chooses to "Allow/Temporary Allow" function, the required gstatic domain can be shown in a "Tree" to user, stating that "Gmail is linked to gstatic" and so on. Therefore a user can allow an entire "Tree" of the connected domains resulting in a simpler access in place of choosing to "Allow/Temporary Allow" for each domains and all other NoScript rules can be applied to this "Tree" as usual.

Like this:

User: Allow/Temporary Allow

Gmail
:
:.gstatic (Same rule as set for Gmail)

In case a user does not want to allow an entire "Tree" then that too can be incorporated with NoScript retaining its functionality intact.

Also this kind of layout will make navigation much easier to understand and click on.

Thank you so much for making NoScript!

Re: Tree Format Domain Access

Posted: Sun Mar 20, 2016 11:02 am
by barbaz
Sounds like a corollary of viewtopic.php?f=10&t=18287 (specifically, #2). Also keep in mind that different users will want different trees, so it'd have to be customizable.

Re: Tree Format Domain Access

Posted: Sun Mar 20, 2016 1:28 pm
by treehouse
I really appreciate your input. I checked that link too. Customization and simplicity is the whole idea. I can only hope here.

Thank you.

Re: Tree Format Domain Access

Posted: Sun Mar 20, 2016 5:53 pm
by barbaz
It just occurred to me, the following use case for this RFE. User can set up a "Tree" consisting of a base site and all the scripts they want to have running on that site. Then, when they visit that site and want scripts enabled - they just Temp-Allow the whole tree in one click.

That gives all the simplicity of cascading temporary permissions with none of the dangers - and on a per-site basis at that. 8-)

So, +1 from me.

Re: Tree Format Domain Access

Posted: Sun Mar 20, 2016 7:19 pm
by treehouse
Really loved that. What bothering to me is the the way we have to configure all the subsequent domains while being on the same site. This can greatly reduce that time and helps user to access they want easily.

Perhaps putting a new design element representing that "Tree" will help in the NoScript icon, so one(or as configured by a user) window will popup showing up the entire cascaded domains!

Thank you again for taking this into consideration.

Re: Tree Format Domain Access

Posted: Tue Mar 22, 2016 12:20 am
by Thrawn
barbaz wrote:the simplicity of cascading temporary permissions with none of the dangers
Is this the best way to use temporary permissions, though? My understanding is that they're primarily for when you're not sure which domains you need to make a website work. Temp-allowing each time you go back to a webpage just trains you to whitelist it without thinking.

Re: Tree Format Domain Access

Posted: Tue Mar 22, 2016 12:41 am
by barbaz
That's one purpose of temporary permissions, sure - but not the only one. Temporary permissions are for anytime you don't want some site Allowed unless you explicitly say so. Repeatedly giving a site temporary permissions is basically trusting a site only as far as not to actually compromise your computer or browser in certain hand-picked situations, but no further than that. I only grant temporary permissions for a couple sites I use a lot, for exactly that reason.

Pre-defining trees will significantly mitigate the dangers of getting used to Temp-Allowing a site / whitelisting without thinking. For example, in the case of Unicode-lookalike spoofing & the like, because the lookalike won't be part of the tree, the one click the user is accustomed to won't Temp-Allow the nasty, and the user is still safe.

Feature Request: Create "site-groups" to be enabled/disabled

Posted: Wed Dec 21, 2016 8:04 pm
by Urbin
I've tried searching this subforum but didn't find anything that looked like the same.

I've been using NoScript for a long time and find it incredibly valuable. There is however one thing, that I find a bit tedious and it seems to be spreading wider and wider.

I often come across sites that require "sister-sites" to be enabled to work properly. I'm listing some examples below:

www.linkedin.com also needs
- licdn.com

www.swisscom.ch also needs
- scsstatic.ch
- tiqcdn.ch

I still like those sites to be disabled by default but use them relatively often. So whenever I want to use those sites, it means not just one click to temporarily allow the main site but a second and third click to allow the required sub-sites for the main site to work. I have not found a way to do this with a single steps and this is where my idea comes from.

Would it be possible to create "groups of sites" that I could then enable/disable together? This would let me group "linkedin.com and licdn.com" and I could then just enable them both as a group and when I'm done I could disable them again as a group.

Thanks for considering this feature request (or if this is already possible I'd appreciate a quick pointer to documentation describing how I would need to do this).

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 12:18 am
by barbaz
Threads merged.

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 1:51 am
by Thrawn
I don't disagree with your desire to keep sites like tiqcdn blocked, but consider: Why do you want it?

If you don't like tracking etc, then you really should get a full privacy/adblocking extension, which NoScript is not. Personally, I like full control, so I opt for extensions like RequestPolicy (previously) or uMatrix (more recently). I can whitelist tiqcdn in NoScript, but only allow (in uMatrix) selected sites to use it. It's possible to achieve something similar in eg Adblock Plus, although it requires you to write a rule instead of just clicking on cells. uBlock Origin can, as well, but I'm not familiar with it.

If you really don't want a second extension, then you can achieve this in ABE, but since you said you "often" encounter this problem, a dedicated extension will be easier to use.

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 2:35 am
by barbaz
@Thrawn: Urbin is not asking for per-site permissions. They're asking for a one-click method to Temp-Allow (or Forbid) a pre-defined group of sites.

I still say +1 to this RFE. I would use it myself. It's much "cleaner" than my current method.
Thrawn wrote:I don't disagree with your desire to keep sites like tiqcdn blocked, but consider: Why do you want it?
They used the word "needs" for a reason. :)

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 5:44 am
by therube
I'm not quite following?
Anyhow, wouldn't ABE be viable for this?

And what's wrong with Temp Allow (& don't whitelist at all)?
That's all I ever use.

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 4:12 pm
by barbaz
therube wrote:wouldn't ABE be viable for this?
No. ABE is totally independent of script blocking. It doesn't save on clicks.
therube wrote:And what's wrong with Temp Allow (& don't whitelist at all)?
Nothing. Actually, this RFE will make that even easier.

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 10:51 pm
by Thrawn
barbaz wrote:@Thrawn: Urbin is not asking for per-site permissions. They're asking for a one-click method to Temp-Allow (or Forbid) a pre-defined group of sites.
...It's much "cleaner" than my current method.
I know, but I'm saying, temporarily allowing a group, whether all at once or individually, is not really a good way to operate NoScript, and it suggests that what you really want is something outside the scope of security.
Thrawn wrote:They used the word "needs" for a reason. :)
Oh, I didn't mean "why do you want tiqcdn?", I meant "why do you want tiqcdn blocked?"
My point being, you probably want to block it for privacy reasons. So you ideally should get an extension designed to do that very thing.

Re: Tree Format Domain Access

Posted: Thu Dec 22, 2016 11:43 pm
by barbaz
Thrawn wrote:I know, but I'm saying, temporarily allowing a group, whether all at once or individually, is not really a good way to operate NoScript, and it suggests that what you really want is something outside the scope of security.
... or that you really want a "middle ground" type way to handle something like this - viewtopic.php?f=19&t=13576

... or that you run your browser both sandboxed and not sandboxed, off the same profile, and what you really want is less restrictive permissions inside the sandbox vs outside it.

I could go on, but you get the idea. Security-wise, permament permissions can be just as good in a lot of cases, but "Temporarily allow" ain't no one-trick pony.
Thrawn wrote:Oh, I didn't mean "why do you want tiqcdn?", I meant "why do you want tiqcdn blocked?"
My point being, you probably want to block it for privacy reasons. So you ideally should get an extension designed to do that very thing.
Ah. Blocking tiqcdn outright has been known to be problematic and some false positives. Thus, if it is about privacy, I suggest Allowing tiqcdn and using uBlock Origin to block the tracking stuff.