Whitelist View Enhancement

[treslumen]

Dear developers:

I've been using NoScript for a long time, yet this is my first forum post here, in order to suggest a UI enhancement based on my experience, which I believe would benefit more than just myself:

The Whitelist is central to NoScript, yet its current view is not as useful/flexible as it can be. The following are the suggestions that I come up with:

1. Sort the whitelist by 2nd-level domain name

Since today specifying the 3rd-level subdomain in a whitelisting rule becomes important, esp due to cdn domains like cloudfront.net (it's risky to whitelist the whole cloudfront domain as a specific subdomain can be hosting bad scripts), now several rules with the same 2nd-level domain are scattered around, eg aaaaa.cloudfront.net and zzzzz.cloudfront.net are far apart. With 2nd-level-domain based sorting, all the cloudfront.net sites are placed together. Of course, this could be just an optional sorting/viewing mode, not necessarily the only mode.

2. Site grouping

Personally, due to the importance of NoScript, I think it's worthwhile to maintain the whitelist, to keep it as tight as possible. One UI enhancement I believe is to allow (manual) grouping of related rules, which overrides the default sorting suggested above. For instance, specify a Google group:

Code: Select all

Google
- google.com
- gstatic.com
- googleusercontent.com
- googleapis.com

This is also particularly useful to group corresponding cloudfront domains to a site, for example:

Code: Select all

Dropbox
- dropbox.com
- dt8kf6553cww8.cloudfront.net

3. Annotation / comment

I feel the need to keep a brief note about a whitelisted site that I'm not familiar with (for example, for a specific cloudfront subdomain), and the note can show as a tooltip upon hovering.

4. Statistics

This is also essential for maintenance: log and display basic statistics, mainly "total hits" and "time of last hit", and provide corresponding sorting options, so that, if a site has very few hits, or the last hit dates from 2 years ago, then we can consider removing it in order to keep the whitelist lean.

5. Blacklist

I know that NoScript keeps an implicit blacklist, but I really feel it's important to have an equal UI for blacklist for maintenance purposes, and the same suggestions listed above apply to blacklists, esp annotation and statistics.

Side note: as a primitive thought, I even think it could be considered to put both whitelist and blacklist in one list, but with distinct visual style, eg color-code the blocked domains in red, and that allows site grouping to display both allowed and blocked domains for certain site in one place, for instance,

Disqus
- disqus.com
- referer.disqus.com
- a.disquscdn.com


That's all about the whitelist view enhancement that I can think of, and I hope for a discussion with the developers and everyone who are interested in whitelist/blacklist maintenance in NoScript.

[Thrawn]

1. Sort the whitelist by 2nd-level domain name

Sounds valuable.

2. Site grouping

Could be useful sometimes, but may not work so well when sites like googleapis are used in lots of places...

This is also particularly useful to group corresponding cloudfront domains to a site, for example:

Have you ever investigated RequestPolicy? You may find it valuable.

4. Statistics

This is also essential for maintenance: log and display basic statistics, mainly "total hits" and "time of last hit", and provide corresponding sorting options, so that, if a site has very few hits, or the last hit dates from 2 years ago, then we can consider removing it in order to keep the whitelist lean.

Are there addons that do this kind of thing in general? I'm not sure.

I will point out that this kind of tracking is a potential privacy leak.

That's all about the whitelist view enhancement that I can think of, and I hope for a discussion with the developers and everyone who are interested in whitelist/blacklist maintenance in NoScript.

Actually that's 'developer' (singular). It's all Giorgio. The rest of us just moderate. On the downside, he's always busy; on the plus side, he does really good work.

[treslumen]

Thank you Thrawn for the discussion! Here are my further elaborations regarding the concerns you brought up.

[Site grouping] may not work so well when sites like googleapis are used in lots of places

I meant to put googleapis under the Google group, this is different from the cloudfront case, because googleapis is exclusively hosting Google's own content, but cloudfront can host whatever users put there, not just Amazon's own content. This site grouping that I suggested, at least for now, is manual for maintenance purposes only, namely within the "Whitelist" tab of "Options".

Site grouping for various cloudfront.net subdomains is quite useful, for instance, currently, when you look at entries in the whitelist like ggegdhebh.cloudfront.net, you have no idea which site it belongs to. That's why I suggested two things: annotation/comment on rules, and (manual) site grouping in the "whitelist" tab.

[Statistics] Are there addons that do this kind of thing in general? I'm not sure.
I will point out that this kind of tracking is a potential privacy leak.

This can be completely local, just like the fact that the whitelist / blacklist itself is completely local, instead of being sent to NoScript. There exists addons that disaply this sort of basic "hits" data, like Adblock Plus, which lets you quickly see which rules are in frequent action and which are dormant, as well as since when they became active / dormant. To me, very useful data for rule maintenance. What do you think?


Finally, regarding the developer, is his NSA (NoScript 3.x) only for mobile devices, or it's all-in-one, including desktop UI as well?

[barbaz]

I like your first 3 points. Would make dealing with the whitelist much nicer. +1 to those.

However,

4. Statistics

This is also essential for maintenance: log and display basic statistics, mainly "total hits" and "time of last hit", and provide corresponding sorting options, so that, if a site has very few hits, or the last hit dates from 2 years ago, then we can consider removing it in order to keep the whitelist lean.

If this is going to be included, please make sure it can be completely disabled, the same way you can disable this feature in Adblock Plus (where disable also implies reset).

5. Blacklist

I know that NoScript keeps an implicit blacklist, but I really feel it's important to have an equal UI for blacklist for maintenance purposes, and the same suggestions listed above apply to blacklists, esp annotation and statistics.

Side note: as a primitive thought, I even think it could be considered to put both whitelist and blacklist in one list, but with distinct visual style, eg color-code the blocked domains in red, and that allows site grouping to display both allowed and blocked domains for certain site in one place, for instance,

Disqus
- disqus.com
- referer.disqus.com
- a.disquscdn.com

I'm not entirely sure what you're talking about. There is no "implicit blacklist". There's only the Untrusted list, which the user explicitly sets, and the rest is just default-deny, nothing is stored anywhere.
Assuming you're talking about the Untrusted list, let's not mix it up with the whitelist. That would confuse everyone, especially the colorblind. And for people like me whose Untrusted list doesn't fit on a really large tooltip, it would also make the whitelist GUI basically unusable as such, and we would end up trying to mess with hidden preferences in about:config to edit the whitelist (which is a real PITA but still less bad than working with a combined whitelist/blacklist GUI).

Let's keep Untrusted list GUI in its own panel, maybe under "Advanced" (since most users won't need to manage the Untrusted list that way anyway). This way it can share code with the whitelist panel more easily and could potentially be simpler for Giorgio to maintain, should he decide to implement this.
-----------------
EDIT: Sorry, I was being unclear. By "hidden preferences in about:config" I meant "preferences you CAN'T see in about:config". Which would mean closing browser, manually editing prefs.js or user.js, restarting, hoping it works, if not, repeat...

[treslumen]

[Statistics] If this is going to be included, please make sure it can be completely disabled, the same way you can disable this feature in Adblock Plus (where disable also implies reset).

I agree, it must be an option.

[Blacklist] Assuming you're talking about the Untrusted list, let's not mix it up with the whitelist.

Sorry for the confusing wording, I am talking about the Untrusted list. By "implicit" I simply meant that GUI-wise there's no explicit listing in Options like the Whitelist does, and I do feel the need to find an efficient way to maintain the Untrusted list besides editing prefs.js directly. And the "hits" data, IMHO, is very useful in decision making during the process of keeping the list from growing too big (which happens easily).

That "combine both lists" thought was primitive of course (brainstorming...) I'd be totally happy with a separate Untrusted list view. My point was that, my suggestions 1 through 4 also apply to the Untrusted list.

Maybe put both lists as sub-tabs under the main tab "Domain rules" or "Site rules" (which is currently just "Whitelist").

Thank you for your discussion, barbaz.

[Thrawn]

googleapis is exclusively hosting Google's own content

No, it's not. Lots of sites use Google APIs.

[Statistics] Are there addons that do this kind of thing in general? I'm not sure.
I will point out that this kind of tracking is a potential privacy leak.

This can be completely local, just like the fact that the whitelist / blacklist itself is completely local, instead of being sent to NoScript. There exists addons that disaply this sort of basic "hits" data, like Adblock Plus, which lets you quickly see which rules are in frequent action and which are dormant, as well as since when they became active / dormant. To me, very useful data for rule maintenance. What do you think?

I never assumed that it would be sending data to noscript.net. What if someone else takes a look at your computer? This would have to integrate with Private Browsing mode, presumably, which would further complicate it.

ABP filters are less of an issue, because they don't tell anyone what sites you've been to; the sites on them are supposed to be third-party advertisers, who could be anywhere and who weren't what you wanted in the first place.

Finally, regarding the developer, is his NSA (NoScript 3.x) only for mobile devices, or it's all-in-one, including desktop UI as well?

They will integrate eventually, I believe, but not yet.

[barbaz]

googleapis is exclusively hosting Google's own content

No, it's not. Lots of sites use Google APIs.

This disagreement is a good example of why grouping whitelist entries would only be useful if it's entirely manual (no automatic grouping). Different users will want to make different groups out of the same sites, and automatic grouping would make that impossible.

Not to say I wouldn't be OK with default groups, so long as they can be changed/ungrouped/deleted...

[treslumen]

googleapis is exclusively hosting Google's own content

No, it's not. Lots of sites use Google APIs.

True, I realize now that Google Storage is on this domain as well (bad design). Originally I was only thinking of Google-hosted JavaScript libraries (the ajax subdomain) and Google Maps API (the maps subdomain), etc.
See GitHub eventually had to move all user content to a new domain github.io.

In addition, it would be great if NoScript can implement simple logic in whitelisting rules like "Allow all googleapis.com subdomains except commondatastorage". It's like inverse selection, assume there will be dozens of googleapis subdomains that are exclusively hosting Google's own content, but only one or two are open to all Google users, so we can't simply Allow the whole 2nd-level domain, but adding rules for each subdomain isn't as neat as using the exception logic.

What if someone else takes a look at your computer? This would have to integrate with Private Browsing mode, presumably, which would further complicate it.
ABP filters are less of an issue, because they don't tell anyone what sites you've been to; the sites on them are supposed to be third-party advertisers, who could be anywhere and who weren't what you wanted in the first place.

Regarding ABP rules, there are quite many first-party rules if you look at ABP's official lists (including domain-specific CSS hiding rules); Then custom filters tend to contain even more first-party, domain specific rules.

If someone else takes a look at your computer?
Case 1: Family members or friends tend to do this...
Then as barbaz said, this can be disabled completely.
Case 2: Bad guys...
Then there's more to worry about...

Of course, it'd be great if this feature conforms to Private Browsing!

----------------
This dilemma is similar to, should I keep a personal diary?
It serves yourself very well for introspection and memory keeping, but it is a also a privacy bomb...

Depending on a specific user's evaluation and choice, he/she can opt in or out correspondingly.

[barbaz]

In addition, it would be great if NoScript can implement simple logic in whitelisting rules like "Allow all googleapis.com subdomains except commondatastorage". It's like inverse selection, assume there will be dozens of googleapis subdomains that are exclusively hosting Google's own content, but only one or two are open to all Google users, so we can't simply Allow the whole 2nd-level domain, but adding rules for each subdomain isn't as neat as using the exception logic.

You can already do this. Mark the specific subdomain(s) as Untrusted, then Allow the 2nd-level domain.

[treslumen]

In addition, it would be great if NoScript can implement simple logic in whitelisting rules like "Allow all googleapis.com subdomains except commondatastorage". It's like inverse selection, assume there will be dozens of googleapis subdomains that are exclusively hosting Google's own content, but only one or two are open to all Google users, so we can't simply Allow the whole 2nd-level domain, but adding rules for each subdomain isn't as neat as using the exception logic.

You can already do this. Mark the specific subdomain(s) as Untrusted, then Allow the 2nd-level domain.

Yes, that I am aware of, but this is different.

There're three states for a given domain: Allowed, Prompting, and Untrusted.

For example, currently, we can allow googleapis.com, and Untrust commondatastorage.googleapis.com. But this is not ideal, and surely not what I wanted. Here is why:

Say there are two user buckets in Google Storage:
good.commondatastorage.googleapis.com
bad.commondatastorage.googleapis.com

I want NoScript to prompt for my decision so that I can allow good.commondatastorage.googleapis.com but untrust bad.commondatastorage.googleapis.com.

Currently, if I untrust commondatastorage.googleapis.com totally, then there's no way to allow good subdomains.

What is needed is to set the rule to prompt (instead of untrust) commondatastorage.googleapis.com, yet allow all the other googleapis.com subdomains.

------------
EDIT

Mark the specific subdomain(s) as Untrusted, then Allow the 2nd-level domain.

The other problem with this approach is that, after you Allow the 2nd-level domain, it's impossible to protect from NEW bad subdomains in the future...
This is particularly the for those CDN type of domains.

[barbaz]

Oh. That can be achieved with ABE rules. Here's a template using your example:

Code: Select all

Site .good1.commondatastorage.googleapis.com .good2.commondatastorage.googleapis.com
Accept

Site .commondatastorage.googleapis.com
Deny INCLUSION(SCRIPT, OBJ, FONT, XHR)
Sandbox

Of course, googleapis.com would need to be Allowed for this rule to have any practical use. Ideally, these rules should be in their own ruleset. If you already have USER rules, go to about:config, create a string preference named noscript.ABE.rulesets.USER2, give it a value of #, then add this rule to that ruleset in NoScript Options -> Advanced -> ABE (delete the initial # first). You can check the Error Console for messages starting with [ABE] to see if you need to add another .good.commondatastorage.googleapis.com to the first line.

But prompting for this through the NS menu would confuse most users and clutter their menu unnecessarily. My menu is large enough as it is. I don't need or want that feature.

[treslumen]

Never bothered looking into ABE before, now I see, this is essentially a HTTP firewall! And fairly simple as well... It's just not "promoted" sufficiently at the moment, is it? Maybe one day ABP is going to have a GUI...

Question though, are the regular rules (Allow, Untrust) internally sharing the same mechanism as ABP? For instance, is Untrust equivalent to Sandbox ALL?

Thanks barbaz!

-------
EDIT
Of course I meant to say ABE, not ABP, schit!

[barbaz]

Never bothered looking into ABE before, now I see, this is essentially a HTTP firewall! And fairly simple as well... It's just not "promoted" sufficiently at the moment, is it?

You're obviously an advanced user if you say that. Took me a few months to figure it out, and many users can't get their heads around ABE at all.

Maybe one day ABP is going to have a GUI...

If you mean ABE (rather than Adblock Plus), Thrawn is working on it.

Question though, are the regular rules (Allow, Untrust) internally sharing the same mechanism as ABP? For instance, is Untrust equivalent to Sandbox ALL?

I don't think so. ABE is totally separate from NoScript's script blocking. And Sandbox ALL would only affect documents rendered in a Gecko DocShell (i.e. full-page documents and iframes), so no it's not the same. Thus the Deny clause before Sandbox in my example rule.

[Thrawn]

Not much progress on SABER lately, I admit, but I hope to make something worthy of alpha-testing over the Christmas period.

Anyone who wants a link to the work-in-progress version can private message me.

[ReporterX]

The suggestions are really good. I would like them to be implemented too.
Statistics are nice to have. Personally I don't need much. I might turn it off if it eats up the resources.
If I can add comments, the need for 1-2 will somehow reduced since I can tackle them with comments.

Priority:
3 > 5 > 1-2 > 4