Page 2 of 5

Re: NoScript 10.1.5.1 question

Posted: Mon Dec 04, 2017 6:32 pm
by DHO
From my point of view what I want is for the NoScript processing of trust to accurately match the rules that have been specified, for example if I say I trust ...service.gov.uk then this means *.service.gov.uk is trusted (which is NOT how it currently works!).

I can see that there may be some difficulty in NoScript always suggesting appropriate options for Default domains that you can choose to trust if you wish given the variation in domain structures. However providing I can manually input entries in the 'Address of web site' input box I can make my own decisions about at what level in the domain structure I want to specify trust for a specific domain (the level could well vary depending on the specific domain).

I definitely do NOT want NoScript to constrain me to only using it's suggestions on what level in the domain structure I am allowed to specify trust for a specific domain!

Re: NoScript 10.1.5.1 question

Posted: Mon Dec 04, 2017 7:17 pm
by Tomate
DHO wrote:From my point of view what I want is for the NoScript processing of trust to accurately match the rules that have been specified, for example if I say I trust ...service.gov.uk then this means *.service.gov.uk is trusted (which is NOT how it currently works!).
...
However providing I can manually input entries in the 'Address of web site' input box I can make my own decisions about at what level in the domain structure I want to specify trust for a specific domain (the level could well vary depending on the specific domain).
That functionality could be added at some point. But it's really a rare special case.
Although it's probably not so good security wise as it seems there are many websites registered by different people under .gov.uk
https://www.gov.uk/government/publicati ... troduction
barbaz wrote:I confirm this. It not only affects subdomains with "fake" TLDs (such as .corp or .lan), it also affects some real TLDs (like .test).
I would suggest that if the domain contains any dots, and if it doesn't have a known TLD, NoScript should fall back to the "one-dot rule" - whatever comes after the last dot is treated as the TLD.
Sounds good to me.

Re: NoScript 10.1.5.1 question

Posted: Mon Dec 04, 2017 7:22 pm
by Tomate
(and under service.gov.uk)

Re: NoScript 10.1.5.1 question

Posted: Tue Dec 05, 2017 4:43 pm
by Tomatix
https://forums.informaction.com/viewtop ... 066#p93676
zdamien wrote:1) I'm finding many sites not loading, until I individually trust each of the <garbage>.cloud front.net servers that they happen to be depending on. This wasn't an issue before FF 57, and I see no way to trust *.cloud front. net now.
cloudfront.net
cloudcontrolled.com
and many other cloud-something.. .com
..are all listed as "Top-Level"-Domains / Domain-Suffixes

I suppose because here again it makes little sense to trust the cloud providers base domain, if it delivers the web content of many different 3rd party websites around the world.
( https://en.wikipedia.org/wiki/Amazon_Cl ... #Use_cases )

<subdomain-ID>.cloudfront.net
But seems logical that the subdomain-IDs stay the same for a particular website that uses cloud services. So it should be possible to TRUST them permanently for all sub pages of that website.
( https://aws.amazon.com/solutions/case-studies/all/ )

Re: NoScript 10.1.5.1 question

Posted: Wed Dec 06, 2017 8:40 am
by Richard
As I am not a regualr user of this forum: Is this issue taken care of or has this to be taken to the development forum?

Thanks
Richard

Re: NoScript 10.1.5.1 question

Posted: Thu Dec 07, 2017 1:52 am
by barbaz
Richard wrote:As I am not a regualr user of this forum: Is this issue taken care of or has this to be taken to the development forum?

Thanks
Richard
It's fine here, but I think the title needs to be more descriptive. What do you think of: NoScript 10 Weird handling of TLDs & local domains?

Re: NoScript 10.1.5.1 question

Posted: Thu Dec 07, 2017 2:09 am
by Tomatix
barbaz wrote: It's fine here, but I think the title needs to be more descriptive. What do you think of: NoScript 10 Weird handling of TLDs & local domains?
good. (was definitely needed)

Re: NoScript 10.1.5.1 question

Posted: Thu Dec 07, 2017 2:17 am
by barbaz
Tomatix wrote:
barbaz wrote: It's fine here, but I think the title needs to be more descriptive. What do you think of: NoScript 10 Weird handling of TLDs & local domains?
good. (was definitely needed)
Done, thanks for the feedback Image

Re: NoScript 10.1.5.1 question

Posted: Thu Dec 07, 2017 2:27 am
by Tomatix
barbaz wrote:Done, thanks for the feedback Image
You're welcome :)

Re: NoScript 10.1.5.1 question

Posted: Sat Dec 09, 2017 3:33 pm
by Giorgio Maone
barbaz wrote: I would suggest that if the domain contains any dots, and if it doesn't have a known TLD, NoScript should fall back to the "one-dot rule" - whatever comes after the last dot is treated as the TLD.
Agree, it's gonna be in next RC.

Re: NoScript 10.1.5.1 question

Posted: Sun Dec 10, 2017 3:35 pm
by barbaz
Giorgio Maone wrote:
barbaz wrote: I would suggest that if the domain contains any dots, and if it doesn't have a known TLD, NoScript should fall back to the "one-dot rule" - whatever comes after the last dot is treated as the TLD.
Agree, it's gonna be in next RC.
The fix doesn't seem to work for me. Testing NoScript 10.1.5.7 with a .test domain, it still only gives the option to allow the full domain, and trusting the 2nd-level domain still doesn't trust the full domain.

Re: NoScript 10 Weird handling of TLDs & local domains?

Posted: Mon Dec 11, 2017 6:15 pm
by DHO
The recent comment #123 from Giorgio at
https://hackademix.net/2017/12/04/noscr ... utshell-2/
seems to confirm that NoScript 10 is now using the concept of a "public suffix" when processing domains.

However there appear to be some problems with this new implementation approach:

1) The new NoScript 10 domain rules have not been documented and seem confusing - not just to me - see the following:

https://forums.informaction.com/viewtop ... =7&t=24030
https://forums.informaction.com/viewtop ... =7&t=24066
https://forums.informaction.com/viewtop ... =7&t=24125

(even comment #123 above admits it is a bit counter-intuitive)

2) I can look at my NoScript Options and see a list of domains with associated trust rules.
At present NoScript seems to obey some of these trust rules and ignore others.
Looking at the list I can't tell which ones it will obey and which ones it will ignore.

3) The NoScript Options list of domains and associated trust rules can be sourced from or modified by:

a) Existing entries that were carried over from the previous NoScript settings that the user may have built up over the years.
b) Any entries that have subsequently been manually entered in the 'Address of web site' input box.
c) Imported settings (since 10.1.5.7).
d) Options that can be based of NoScript's idea of domain structures.

If NoScript 10 is going down the road of enforcing at what level in the hierarchy a given domain can be trusted
(which I don't want it to) then surely it should validate trust rules when they are created or modified by methods (a)
to (d) and explicitly reject any that it deems to be unacceptable so that the user is aware that they have been
rejected and you don't end up with problem 2 above?

4) The user has no control over the contents of the "public suffix" file. Some of the contents of this file seem rather
arbitrary judging from some of the examples quoted earlier in this thead (e.g. vic.gov.au versus nsw.gov.au).

5) What happens when the contents of the "public suffix" file change? Are all of the trust rules configured in my NoScript Options going to
be revalidated? Will some trust rules that were previously obeyed now be quietly ignored?

6) There seem to be issues with internal corporate domains and others such as .test.

Please could we just have a much simpler approach where:
- The user is trusted to make sensible decisions about assigning trust to domains.
- NoScript obeys all of the trust rules that the user has defined.

Re: NoScript 10 Weird handling of TLDs & local domains?

Posted: Tue Dec 12, 2017 1:18 am
by Guest
This was not an issue before the WE debacle. When I allow googleapis.com, I want >ALL< of googleapis.com to be allowed, not some unintuitively limited subset of it, this regardless of the number of dots in that name. This becomes excruciating with something like fastly.net.

Re: NoScript 10 Weird handling of TLDs & local domains?

Posted: Mon Jan 01, 2018 11:04 pm
by DHO
Several weeks have now passed. There have been some more threads about wanting to trust *.cloudfront.net:

https://forums.informaction.com/viewtop ... =7&t=24229
https://forums.informaction.com/viewtop ... =7&t=24307

I am still struggling to see how having NoScript 10 quietly ignore some user-specified trust rules is a good thing.

I would be even more concerned if I was blacklisting some domains as Untrusted because the consequences of ignoring a user-specified trust rule could potentially be greater. Also if a user wanted to blacklist at a high level in the domain hierarchy (e.g. a country, the government of a country, a state) how could this be done in NoScript 10?

Please could Giorgio explain exactly how domains are supposed to work in NoScript 10 and why the various concerns raised in my previous post in this thread are not problems.

Re: NoScript 10 Weird handling of TLDs & local domains?

Posted: Mon Jan 01, 2018 11:16 pm
by Giorgio Maone
DHO wrote:Several weeks have now passed. There have been some more threads about wanting to trust *.cloudfront.net
I wonder how blanket trusting all the subdomains of cloudfront.net might be a good idea, since anybody can store any kind of code there and each subdomain can be operated by a different entity (so, who are "trusting" you exactly?).
Using the public TLD suffix list to build the list of operable items in the popup will be kept as it is because it's the only thing which makes sense security-wise.
However, I'm considering to let users shoot themselves in their foot if they wish so by making manually entered sites (in the Options tab) validated in a more and lenient way.