InformAction Forums

Giorgio Maone wrote:

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.

Either way you decide, maybe have an error condition for adding a rule that No script will not match.

As is, it adds the rule, the rule looks fine, but it is never applied.
If you do allow manual adding these kind of broad rules a warning would probably be appropriate.

The specific case of cloudfront and other such providers is surely more debatable then the other cases described here.
.gov.uk isn't such a "everybody can drop something on there", and the internal corporate domains neither.

With the change of how the presets are configured, and this case..
I see a risk of making security decisions as if the majority of users were completely computer illiterate, but for those NS was always rather too complicated in the first place.
And meanwhile annoy the users who actually want to use it, but run into increasing barriers of getting it done, because of the above.
Making NS both foolproof (pun intended) and actually quick to use for those who know what they want, is going to be quite a challenge.

It's not like NS Classic ever really prevented users from making it entirly pointless by configuring it non nonsensically.
What's the worst that can happen? Scripts running as for every user out there who just uses their browser.

I'll second that: It's extremely important to allow all subdomains. This was available in all previous versions, and became a problem only with Firefox Quantum.

I'd like to continue sending donations to the developer(s), but functionality is critical.

NYCgirl wrote:I'll second that: It's extremely important to allow all subdomains. This was available in all previous versions, and became a problem only with Firefox Quantum.

I'd like to continue sending donations to the developer(s), but functionality is critical.

I don't disagree with him on cloudfront.

I just don't see a non time/work intensive way of making the distinction between cases where the TLD is actually one entity with one trust concern, and one where it is decidedly NOT, as in cloudfronts case.
Trusting cloudfront (as he correctly points out) is an insane security liability.
You are basically acting like cloudfront is one entity to trust, when it is basically just a storage vector for ANYONE, trustworthy or not.

It's like if you installed an appblocker to stop executables, and instead of trusting everything from one company, you want to trust everything that comes in a zip file.
It's halfway to trusting *.com or *.net

The issue here is that cloudfronts mode of operation disallows what is completely common on the web, and that is proper "treeing".
One site you want to trust operates on several 1level down subdomains instead of having that distinction on the second layer (which you should be able to trust.)
It's lazy architecture, because you are not supposed to be security concious as a "customer". Google does a similar thing by not having their captchas at "captcha.google.com" but randomly somewhere as part of www.google.com.

So...
For people who want to trust cloudfront in a very specific context (as you pointed out workflow) I would almost advise having a seperate sandbox configuration without no script that you use to work out of, and exclusively use to access sites you know are trustworthy with what the put on a cloudserver.
Because when people lazily allow it in their regular private time because it is a hassle when Amazon uses more than one cloudfront instance, it boils down to taking NS out in the yard and shooting it.
You can't trust everything that is in the cloud, just to minimize rules :/

Please check latest dev build, thanks.

I have just downloaded v 10.1.6.3rc1. My initial impression after some quick tests is that it is now much better - it seems to be obeying the domain trust rules that I have specified so far. I will continue using v 10.1.6.3rc1. Thank you Giorgio for making the change.

Giorgio Maone wrote: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.

Perhaps allow such risky changes but with a (supressable) warning to help users avoid cut-and-paste mistakes and typos that grant too much trust?

Giorgio Maone wrote:Please check latest dev build, thanks.

Code: Select all

v 10.1.6.3rc1
=============================================================
x Domain matching now works also for manually entered TLDs
  and pseudo-TLDs, such as "gov.us" or "cloudflare.net"

Big improvement, thanks Giorgio! I'm now able to whitelist my entire 2nd-level .test domain as expected. But I still don't get this option in the NoScript popup. The popup only shows the full domain. The 2nd-level domain has to be manually entered in NoScript Options.

barbaz wrote:

Giorgio Maone wrote:Please check latest dev build, thanks.

Code: Select all

v 10.1.6.3rc1
=============================================================
x Domain matching now works also for manually entered TLDs
  and pseudo-TLDs, such as "gov.us" or "cloudflare.net"

Big improvement, thanks Giorgio! I'm now able to whitelist my entire 2nd-level .test domain as expected. But I still don't get this option in the NoScript popup. The popup only shows the full domain. The 2nd-level domain has to be manually entered in NoScript Options.

Giorgio Maone wrote: 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.

Pansa wrote:

Giorgio Maone wrote: 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.

Pansa, I'm afraid you misread my post. I completely agree with Giorgio on that point and I'm not asking for that to change.

What I'm saying is, the following behavior -

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.

... is only fixed for permissions. The popup still doesn't follow this rule.

barbaz wrote:

Giorgio Maone wrote:Please check latest dev build, thanks.

Code: Select all

v 10.1.6.3rc1
=============================================================
x Domain matching now works also for manually entered TLDs
  and pseudo-TLDs, such as "gov.us" or "cloudflare.net"

Big improvement, thanks Giorgio! I'm now able to whitelist my entire 2nd-level .test domain as expected. But I still don't get this option in the NoScript popup. The popup only shows the full domain. The 2nd-level domain has to be manually entered in NoScript Options.

Which 2nd level domain? neither "gov.u" or "cloudflare.net" are 2nd level domains, they're both TLDs.
Sorry if you already did before, could you (re)give me an example?

I have a local .test domain with subdomains s0.******.test, s1.******.test,...

If I visit the s0 subdomain, the popup shows only s0.******.test. It doesn't show ******.test. But I can manually add ******.test in NoScript Options, and it works.

barbaz wrote:I have a local .test domain with subdomains s0.******.test, s1.******.test,...

If I visit the s0 subdomain, the popup shows only s0.******.test. It doesn't show ******.test. But I can manually add ******.test in NoScript Options, and it works.

So I didn't missread.
That is exactly what he made a point of.
Because if he changed that, we would be back at "cloudfront" being allowable.

How is the case you describe not covered by "I keep the overlay as is, but allow people to murk up their rules in the options"?

Your case isn't covered by the TLD suffix list, and this it isn't available in the overlay :/

Pansa wrote:So I didn't missread.
That is exactly what he made a point of.
Because if he changed that, we would be back at "cloudfront" being allowable.

Let's try again.

The TLD in my case is .test. My domain is ******.test (where ****** is a redacted domain, not a wildcard)

What I am asking is to be able to trust JUST MY DOMAIN when visiting a subdomain. It is no different from asking, 'When visiting forums.informaction.com I should be able to trust informaction.com from the NoScript popup'. Which is already possible.

The fact that my specific TLD isn't listed in the public suffix list should not prevent NoScript from parsing my domain. And as I quoted above, Giorgio agrees with me on this. And we agree on the suggested solution: If a domain contains any dots, AND IF IT DOES NOT HAVE A KNOWN TLD, NoScript should fall back to the "one-dot rule" - whatever comes after the last dot is treated as the TLD.

If you re-read where I quoted Giorgio, that solution is already supposed to be in NoScript. But some testing shows it is not. Therefore, I am reporting a bug. The same bug that folks before me had also reported in this thread.

Now do you understand why I'm not contradicting Giorgio's good decision?

I do understand.

But I fail to understand why doing what you want in the overlay by default in all "unknown" cases isn't exactly that level of security hole that is intended to be avoided in the overlay, but available to configure manually.

We have now obviously entered a paradigm where the overlay is supposed to be reasonably proof for users to not cock things up, and those that have more "refined" wishes to be relegated to the option screen.
Thus I fail to see how in light of changes to the preset settings, and the express argument that "drive by dangerous rules" are definitely going to be avoided in the overlay, defaulting to the right most dot is in line with the expressed security intend here.

Put differently:
If the goal is to prevent users from haphazardly making rules that include a public space, and using the public tld list to make this happen for known open domains under the general TLDs, then logically the consistent behaviour in cases of an unkown tld would be to default to the stringent behaviour, and not the lax one, and pointing users who specifically WANT a potentially lax rule towards the manual input.

Otherwise you make the assumption that obviously in case something doesn't match neither list (FF public suffix list nor the TLD list), it must be safe to allow the root domain and all sub domains. Is that truly the case?

Because if you compare all three distinct cases of complaint in this thread about where rules weren't able to be set (and now are allowed manually):
A) Case where wanted behaviour is suppressed because of TLD list (the *.gov.uk cases )
B) Case where wanted behaviour is suppressed because of public suffix list ( *.cloudfront.net)
C) Not member of either list ( *.yourpage.test)

I don't really see why C is clearly a lesser security risk just by virtue of not being member of those two lists. If anything in terms of what is available on the web by sheer clicking links, C) can be quite a security risks, considering what kind of pages don't use a proper TLD. So I don't think making that exception in the overlay would be consistent.

Pansa wrote:But I fail to understand why doing what you want in the overlay by default in all "unknown" cases isn't exactly that level of security hole that is intended to be avoided in the overlay, but available to configure manually.

Because unknown TLDs are either:

1) known-local domains (e.g. .test), or

2) made-up TLDs for internal networks or similar (e.g. .corp, .internal, .lan), or

3) invalid (e.g. .invalid) and as such NoScript won't encounter them in any real-world situation.

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?