[RESOLVED] NS 10 Weird handling of TLDs & local domains?

Ask for help about NoScript, no registration needed to post
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

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

Post by Pansa »

barbaz wrote:
Do you have an example of a TLD that's A) not in the public suffix list, B) does not fall into any of the above 3 categories, and C) was seen 'in the wild' containing domains that actually pointed somewhere?
You are missing my point.
You want the "default" to be "is in the overlay".
As in "if it isn't on the very limited TLD list, or the community lead (so, not comprehensive) suffix list, it should be considered safe to include in the overlay.

I fundamentally do not think that "the default in case of lack of data is "safe"" is in line with the current changes in terms of securing against accidental misuse in the overlay.
If no script doesn't know what you have there, because it's not on either list, it should relegate you to do it yourself.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Pansa wrote:You want the "default" to be "is in the overlay".
As in "if it isn't on the very limited TLD list, or the community lead (so, not comprehensive) suffix list, it should be considered safe to include in the overlay.
Glad we have no more misunderstanding here.
Pansa wrote:I fundamentally do not think that "the default in case of lack of data is "safe"" is in line with the current changes in terms of securing against accidental misuse in the overlay.
When assessing potential security problems, we need facts, not just fundamental thoughts.

Therefore, I ask you again -

Do you have a concrete example of a TLD that's A) not in the public suffix list, B) does not fall into any of the above 3 categories, and C) was seen 'in the wild' containing domains that actually pointed somewhere?
*Always* check the changelogs BEFORE updating that important software!
-
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

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

Post by Pansa »

barbaz wrote:
Pansa wrote:You want the "default" to be "is in the overlay".
As in "if it isn't on the very limited TLD list, or the community lead (so, not comprehensive) suffix list, it should be considered safe to include in the overlay.
Glad we have no more misunderstanding here.
Pansa wrote:I fundamentally do not think that "the default in case of lack of data is "safe"" is in line with the current changes in terms of securing against accidental misuse in the overlay.
When assessing potential security problems, we need facts, not just fundamental thoughts.
A) We didn't have a misunderstanding to begin with. I just kept rephrasing it until you saw that I do fully understand what you are asking.
B) No, when assessing security problems you have to consider whether what you ask as exception is consistent with the general system of prevention you are dealing with, and whether that exceptions creates holes that are a vector. Not just flick holes you already know are quantifiable problematic.

So no, I do not have to give an example. I don't have to manually search for the most obsurce unconventional toplevel domain and then crossreference that with the user created list.
There is no reasonable assumption that this doesn't exist, because nothing in the system prevents it from existing.
And that is reason enough to treat a "default" as if they do.
I don't think "I haven't seen one yet, so it's ok" is a proper approach to that.

The argument for implementing this 2 level system also is not "here is a cloudfront subdomain with a script no one in their right mind would want to run", it is "it is not one source to trust, it MIGHT contain scripts you don't want to run".
On a similiar note, non conventional TLDs are not a conform set of things, thus the default should not treat them as trustworthy that way.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Pansa wrote:So no, I do not have to give an example.
Pansa, this is not like other forums. Around here, when you are asked to back up what you write, attempting to circumvent the question is not a good idea. ;)

I will assume that you don't have a concrete example.

As an alternative way to back up your assertions, please expand on this...
Pansa wrote:nothing in the system prevents it from existing.
... and describe a real-world situation where it would exist and be problematic for NoScript users in the same way as co.uk or cloudfront.net.
*Always* check the changelogs BEFORE updating that important software!
-
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

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

Post by Pansa »

barbaz wrote: ... and describe a real-world situation where it would exist and be problematic for NoScript users in the same way as co.uk or cloudfront.net.
What prevents "mycloudservice.iamcool" from existing?
Why is the assumption that mozillas public suffix list is comprehensive and up to date warranted?
This isn't esoteric.
Unconventional TLDs are allowed on the internet.
Unconventional TLDs can be used to host whatever service you might host.
Thus the default assumption for unconventional TLDs should not be more lax than for known TLDs and public suffixes.
Pansa, this is not like other forums. Around here, when you are asked to back up what you write, attempting to circumvent the question is not a good idea. ;)
It was not as much a circumvention, as it is clearly pointing out that you demand a different layer of "proof" here, than is warranted both for general security concerns, as well as was used to establish concerns for the cases A) and B) above.
It is questioning the premise the question is based on.

And you keep dodging my question all the same. What is the difference in argument between "we don't know what is hosted on cloudfront, thus we don't want make trusting cloudfront as a whole too easy" and "we don't know what is hosted under unconventional TLDs, thus don't want to make the assumption that NONE of them are cloud services".

Or inversely:
Why is assuming that unkown TLDs don't have cloudservices hosted more prudent than
assuming cloudservices might host unwanted scripts.
Why is "well I can't think of an unkown tld that fits this case" different from "well I don't know a specific cloudflare subdomain that hosts questionable scripts"?

It is the exact same level of "preventative security concern in face of unkown content". And that is what defaults need to consider (and in both cases currently do)
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Pansa wrote:What prevents "mycloudservice.iamcool" from existing?
Why is the assumption that mozillas public suffix list is comprehensive and up to date warranted?
This isn't esoteric.
Unconventional TLDs are allowed on the internet.
Unconventional TLDs can be used to host whatever service you might host.
By this logic, it's not safe to have *any* 2nd-level domains in the popup. After all, the public suffix list might have missed a cloudfront.net type domain on an existing TLD.
Pansa wrote:What is the difference in argument between "we don't know what is hosted on cloudfront, thus we don't want make trusting cloudfront as a whole too easy" and "we don't know what is hosted under unconventional TLDs, thus don't want to make the assumption that NONE of them are cloud services".
The concrete cases we have for unlisted TLDs (https://forums.informaction.com/viewtop ... 097#p95097) won't contain cloudfront.net type domains.

You are saying that if the public suffix list has missed something, a cloudfront.net type domain could spring up on an unlisted TLD, and thus it's not safe to heuristically determine the 2nd-level domain. But again, the concern there applies to known TLDs just as much, doesn't it?
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

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

Post by Giorgio Maone »

Please check latest development build:
v 10.1.6.3rc2
=============================================================
x Moved preset customization into its own (more discoverable)
global Options section, rather than embedded in assignment
x Domain matching now threats unknown no-dot domains (not in
the public suffixes list) as TLDs everywhere

x Improved validation of manual entries
x Needed capabilities highlighted also on short-hand domain
matched entries inside the CUSTOM preset
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Giorgio Maone wrote:x Domain matching now threats unknown no-dot domains (not in
the public suffixes list) as TLDs everywhere
I'm confused. Was there supposed to be a change in behavior? 10.1.6.3rc2 behaves same as 10.1.6.3rc1 for me, i.e. popup shows full domain s0.******.test but can manually allow the 2nd-level domain ******.test in NoScript Options.
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

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

Post by Giorgio Maone »

barbaz wrote:
Giorgio Maone wrote:x Domain matching now threats unknown no-dot domains (not in
the public suffixes list) as TLDs everywhere
I'm confused. Was there supposed to be a change in behavior? 10.1.6.3rc2 behaves same as 10.1.6.3rc1 for me, i.e. popup shows full domain s0.******.test but can manually allow the 2nd-level domain ******.test in NoScript Options.
You're right, the patch didn't get applied and deployed, ops.
Will go in next dev build, sorry.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Giorgio Maone wrote:You're right, the patch didn't get applied and deployed, ops.
Will go in next dev build, sorry.
Still seeing the same behavior in 10.1.6.3rc4 Image
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

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

Post by Giorgio Maone »

barbaz wrote:
Giorgio Maone wrote:You're right, the patch didn't get applied and deployed, ops.
Will go in next dev build, sorry.
Still seeing the same behavior in 10.1.6.3rc4 Image
Please check latest development build, thanks.
v 10.1.6.3rc5
=============================================================
x Domain matching now treats unknown no-dot domains (not in
the public suffixes list) as TLDs everywhere (fix finally
not overwritten by auto-generated tld.js)

x Fixed rc4 regression causing synchronized changes not to be
persisted
x Smarter XSS popup behavior when reporting concurrent events
from/to the same origins
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Now it gives me the option to allow "test". Too permissive :|
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

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

Post by Giorgio Maone »

barbaz wrote:Now it gives me the option to allow "test". Too permissive :|
OK, clearly I did not fully understood the RFE: "test" is not a public suffix, I believed you wanted to be able to allow it too as a whole.
Instead what you're asking for is:
  1. From the Options Panel: being able to add anything, even TLDs such as "com"
  2. Form the popup: being able to add 2nd level domains, treating unknown one word (no dot) domains not in the public suffix list as TLDs
Is this correct?
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post by barbaz »

Giorgio Maone wrote:what you're asking for is:
  1. From the Options Panel: being able to add anything, even TLDs such as "com"
  2. Form the popup: being able to add 2nd level domains, treating unknown one word (no dot) domains not in the public suffix list as TLDs
Is this correct?
Not quite -
  1. From the Options Panel: being able to add anything, even TLDs such as "com"
  2. From the popup: being able to add 2nd level domains:
    • determine 2nd level domain using the public suffix TLD list where possible,
    • for domains that do contain any dots but TLD not in the public suffix list, fall back to the "one-dot rule" for determining 2nd-level domain
      (for example s0.******.test -> .test not in public suffix list -> by one-dot rule, 2nd-level domain is ******.test -> popup shows ******.test).
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

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

Post by Giorgio Maone »

Please check latest development build:
v 10.1.6.3rc6
=============================================================
x More restrictive domain matching in the main UI for "fake"
TLDs, showing pseudo 2nd level domains containing one dot
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Post Reply