InformAction Forums

Hey.

AFAIU, right now when one whitelists a certain domain, then scripts from that are allowed everywhere, i.e. on the sites from the domain itself but also on sites on any other domain which just uses them (e.g. as 3rd party scripts).
Typical examples are all the facebook.net, jquery.com and similar crap, which from a security PoV one may not want to whitelist globally.

The natural way to overcome this, would be to allow whitelist entries be specified for a list of domains only.
e.g. allow facebook.net on facebook.com, facebook.net and perhaps example.org, but nowhere else.

If no such domain(s) are specified for an entry, the current behaviour of allowing it globally should be retained (though the UI should perhaps visualise that somehow, e.g. with an implicitly set "*").
Obviously, such feature should also find it's way into the UI,... i.e. when one clicks at the noscript icon and allows/forbids scripts from a certain domain (and/or its subdomains), it should further allow one to select whether this is done globally or only for the domain (and/or subdomains) of the current site.

Cheers,
Chris.

https://noscript.net/faq#qa8_10
or wait for noscript 3

Keep in mind though that NoScript is a security tool, not a privacy tool; and you're not gaining all that much security-wise from per-site permissions - in security, either you trust a site or you don't, there is no half-trust. That said there are a few sites like Akamai which host many different sites' content under the same 2nd-level domain, that's when per-site permissions would make sense in terms of security.

Well I had read that, but I seems rather cumbersome to be used in practise (especially the need to manually edit the rules instead of doing it easily via the context menu as it works with global whitelisting.

I didn't intend this as a privacy thing... and I don't think you're right in terms trust/half-trust.
First there's the example like akamai, cloudflare, etc. pp. and while you say it's "few" I encounter this more and more (those guys are the biggest CDNs...), many big sites facebook, amazon use scripts from there.
Second, I may trust e.g. jquery.com to mess around with the content I get from example.com,... if jquery.com would get evil or hacked, then maybe anything on example.com (or anything I interact with it) is simply not important enough to me, that I'd really care.... but OTOH, I may no trust it enough to get their scripts run on myonlinebanking.com.


Is there any information on what's planned with respect to that issue for version 3?


Thanks,
Chris.

calestyo wrote:Well I had read that, but I seems rather cumbersome to be used in practise (especially the need to manually edit the rules instead of doing it easily via the context menu as it works with global whitelisting.

Well there is also µMatrix (discussion here)...

calestyo wrote: I don't think you're right in terms trust/half-trust.
First there's the example like akamai, cloudflare, etc. pp. and while you say it's "few" I encounter this more and more (those guys are the biggest CDNs...), many big sites facebook, amazon use scripts from there.

Using scripts from a CDN is very different from putting scripts on the CDN. Most CDNs (such as cloudflare, jquery) serve their own content, so there's only one entity to trust. From a security perspective, if you trust that one entity, you can feel free to Allow the site and that's that.

If a CDN serves other people's content from its own domain (like Akamai and Cloudfront do), then there are two entities to trust: 1) the CDN operator(s) and 2) the content creator(s). This shouldn't be Allowed unless both entities are trusted.
(Fortunately for us NoScript users, usually with Cloudfront each entity has its own subdomain, so just only Allowing the full domain is generally good enough there.)

calestyo wrote:Second, I may trust e.g. jquery.com to mess around with the content I get from example.com,... if jquery.com would get evil or hacked, then maybe anything on example.com (or anything I interact with it) is simply not important enough to me, that I'd really care.... but OTOH, I may no trust it enough to get their scripts run on myonlinebanking.com.

Then in that example you don't really trust jquery.com and Allowing it is a tangible risk to compromise yourself.
Letting a "evil or hacked" site "mess around with the content you get from [a site you're visiting]" is just asking for malware & the like.

For such cases it is best to only grant the site temporary permissions when you need it (if even that) and leave it outright Forbidden the rest of the time. Even better, run the browser in a sandbox and don't visit any sensitive sites in that session, and dump the sandbox on browser quit, then it mostly doesn't matter what happens.

calestyo wrote:Is there any information on what's planned with respect to that issue for version 3?

All I know is that it's planned, sorry. Only Giorgio would know more.

calestyo wrote:Typical examples are all the facebook.net,

... which you should (could?), simply, not use; because why would anybody trust it, btw.

*It's a crazy idea to have your login information /credentials, for Facebook, thrown around the Internet by facebook.net (despite their claims)