InformAction Forums

Posted: **Mon Nov 27, 2017 6:12 pm**

grizzler wrote:Well, it's more like ten steps back for me.

As I wrote in the first posting in this thread: there is nothing for me to set. Every NoScript related window only has some "window furniture" at the top - if any - and no content at all.

I get the impression this has something to do with the number of items in the database. Opening the Options window and scrolling down used to lock Firefox solid here. I never got as far as the debug section. Maybe NoScript is now simply ignoring a database with more than a certain number of items (mine is most likely rather large, as I've been using NoScript for well over a decade).
Could be something else entirely of course. I don't know. All I know is I can't make any changes to anything.

But in the end, you are just being confronted with a specific general problem of "white and or blacklisting" content, which happens from firewalls to virus scanners.
And that is that the longer you make the list to comb through by said application, the more drastically you increase the time to parse said list.

The goal of those applications isn't to specifically index the whole internet into "All the things I do or do not trust".
The goal should always be to fundamentally understand which of those lists is going to be the bigger, and deal with that content as "default" behaviour.
Basically if you have a blacklist from here to Madagascar, you shouldn't be keeping a blacklist specifically to begin with, but have "treat it as blacklist" for everything, and whitelist individuals.
Or the other way around, if you basically don't fret about anything except for something specific threats, you default allow, and have a blacklist.

Because in general (either way around you prefer) you basically force the application to parse a list of things that are already covered by the default behaviour, basically for the sheer heck of it.

The fact that the interface isn't able to handle such a micromanaging is lamentable, but somewhat understandable given the timeframe of release and the general "not best practice" space of triggering the issue to begin with.
It's not really about the time of how long you use it. It is about how long you have used it with a "less than optimal" approach to begin with.
I understand that the reaction to the above is probably "don't tell me how to use it, it was fine until now", but technically it wasn't, it just wasn't noticeable.
It'S one of those things that continuously slows things down until someone goes "this is all shit and slow", or in this case "the new interface doesn't deal with it well/at all".

Posted: **Mon Nov 27, 2017 7:29 pm**

Pansa wrote:
oldetyme1 wrote:Just jumping in to say I'm also seeing odd behavior with the latest.

While it looks like some of the worst things are now fixed (defaults reverting and getting mixed up with custom), other things are still not quite functioning as expected.

Setting anything under custom, or setting temporarily allow in neither temporary, nor remembered in custom tab for a domain.
Temporary doesn't "stick" for me, either upon a reload, or a re-launch. None of the options selected are remembered after reload or re-launch.

Two steps forward, one back, it seems.
https://forums.informaction.com/viewtop ... =7&t=23845

Doesn't seem to change much in my case (green vs. red).
The only thing I see are fewer URLs listed for adjusting, depending on the site.

It bounces back to default, whether refreshed, re-opened, or re-launched.
It can stick to 'custom' when *not* selecting the lock (leaving it green), but it will not keep "temporarily" allow in "bolded" / selected / applied status.
Even tried removing it, starting with a new profile, and then installing add-on. No change.

- Unable to set temporary permissions (remains persistently "allowed")
- Unable to set custom at all after setting to 'red' (http/s) (it defaults to "default" upon refresh)

Posted: **Mon Nov 27, 2017 7:58 pm**

oldetyme1 wrote:...

Just a stupid question:
Why does it say "Firefox/54.0" below your post?

Firefox pre 57 doesn't support 10.1.x as far as I know.

Also the way you use "temporary" is weird to me.

Are you saying that if you create a custom temporary rule, you are wondering that it resets that rule to default after you close FF?
Because that is "intended behavior". That is literally what "temporary" means.
And things that get removed from custom, don't remember what their custom settings were.

You can see that in the debug log. (options, check box next to debug)
If something is trusted or untrusted, it just gets put into the list there, and the settings are ONE section for all of them (plus the section of default settings)
If you create a custom setting, it creates a site specific section with it's own rules below it.
If you remove it from custom, the whole section gets removed, and the settings with it. And that site readded to either list (trusted/untrusted) or also removed (default)

So this covers "temporary rules and closing firefox". As well as general "if you remove it from custom" behaviour.

Now to "reloading":
If you set a rule, and then reload, Noscript matches what it finds against the ruleset, and if it doesn't find a rule sets it to default behaviour.
This is why "red lock" is important sometimes.
If a page only is a HTTP site, and you make a green lock rule (https only), and reload, it looks for a rule for HTTP and doesn't find one, because there isn't one -> default.

It doesn't just show you less, if it shows you less it means that you blocked the script that loaded MORE scripts.

Also while you are in the debug log : check whether the capabilities for "trusted" and "untrusted" as well as "default" actually are what they think they are.

Posted: **Mon Nov 27, 2017 8:31 pm**

Pansa wrote:
oldetyme1 wrote:...
Just a stupid question:
Why does it say "Firefox/54.0" below your post?

Firefox pre 57 doesn't support 10.1.x as far as I know.

Also the way you use "temporary" is weird to me.

Are you saying that if you create a custom temporary rule, you are wondering that it resets that rule to default after you close FF?
Because that is "intended behavior". That is literally what "temporary" means.
And things that get removed from custom, don't remember what their custom settings were.

You can see that in the debug log. (options, check box next to debug)
If something is trusted or untrusted, it just gets put into the list there, and the settings are ONE section for all of them (plus the section of default settings)
If you create a custom setting, it creates a site specific section with it's own rules below it.
If you remove it from custom, the whole section gets removed, and the settings with it. And that site readded to either list (trusted/untrusted) or also removed (default)

So this covers "temporary rules and closing firefox". As well as general "if you remove it from custom" behaviour.

Now to "reloading":
If you set a rule, and then reload, Noscript matches what it finds against the ruleset, and if it doesn't find a rule sets it to default behaviour.
This is why "red lock" is important sometimes.
If a page only is a HTTP site, and you make a green lock rule (https only), and reload, it looks for a rule for HTTP and doesn't find one, because there isn't one -> default.

It doesn't just show you less, if it shows you less it means that you blocked the script that loaded MORE scripts.

Also while you are in the debug log : check whether the capabilities for "trusted" and "untrusted" as well as "default" actually are what they think they are.

Running 52/ESR, mainly, but had 54 still installed / open for some misc tinkering and posted from that earlier.

57 in a couple other places for testing. Not ready to use this version of NoScript "full time" until I see it working "on par" with the old one.
Posting from 57 here, for this post, to show ya

As for temp, it stays custom. I should have clarified.
It stays custom/allowed. Even after a restart, fresh profile, and trying it again to be sure I'm not crazy. The "temporarily allow" does not stay bolded. It just stays allowed under "custom."

For showing less, I suppose that makes sense in the case of blocking, and explains that part of things.
Still quite odd to even have the choice. Have read more about that, and it makes some more sense, but It should default to both, and if the choice is there, that's cool, but it should not need to be forced to be made. It's quite confusing.

Posted: **Mon Nov 27, 2017 8:53 pm**

Pansa wrote:
oldetyme1 wrote:...
Also while you are in the debug log : check whether the capabilities for "trusted" and "untrusted" as well as "default" actually are what they think they are.

After repeated attempts at "temporarily allow" under custom, this is what the debug shows.

Code: Select all

    ],
    "untrusted": [],
    "custom": {
      "https://arstechnica.com": {
        "capabilities": [
          "frame",
          "fetch",
          "other",
          "script"
        ]
      }
    },
    "temp": []
  },
  "enforced": true
}

So, temporary "custom" doesn't seem to work, but temporary "trusted" does.
Perhaps that's intended, and perhaps I'm "doing it wrong." ...

The whole red/green bit still confuses me somewhat. I can go unlocked/red on one of the domains, but fewer scripts try to load. If I go back to green/https, boatloads again. Seems ...backwards... from the expectation, if I understand that correctly.
On that, I really don't understand the option to even have that there. It should match across both by default - http* - for example. Granted, I don't understand the complexities involved with even getting it this far (working on 57...), so, maybe there's a good reason for whatever it's doing.

I am, however, VERY grateful that the "defaults" on each category are built-in, and that going between each "tab" doesn't affect the "default" as it had before.

Still think it'd be beneficial to have a global "reset" button for those permissions, in the settings (not main GUI).
On new profile, for example, I noticed that "other" and "Frame" were allowed under custom, where I'd previously not seen that (must've unchecked them).

Code: Select all

    ],
    "untrusted": [
      "§:arstechnica.net",
      "§:arstechnica.com",
      "https://arstechnica.com"
    ],
    "custom": {},
    "temp": [
      "§:arstechnica.net",
      "§:arstechnica.com",
      "https://arstechnica.com"
    ]
  },
  "enforced": true
}

Posted: **Mon Nov 27, 2017 8:59 pm**

oldetyme1 wrote: temporary "custom" doesn't seem to work, but temporary "trusted" does.

I confirm this behavior. Looks like a bug. Thanks for the report

EDIT Someone started a thread about it - https://forums.informaction.com/viewtop ... 10&t=23869
Please continue discussion of this specific bug there.

Posted: **Mon Nov 27, 2017 10:49 pm**

Ok, one bug confirmed, temp custom not supported right now.
And after further testing I have to throw away half of what I wrote and start again... Ok, here we go.

oldetyme1 wrote: The whole red/green bit still confuses me somewhat. I can go unlocked/red on one of the domains, but fewer scripts try to load. If I go back to green/https, boatloads again. Seems ...backwards... from the expectation

It doesn't as easily work that way.
as we can show by the code you posted.

"untrusted": [
"§:arstechnica.net",
"§:arstechnica.com",
"https://arstechnica.com"
],
"custom": {},
"temp": [
"§:arstechnica.net",
"§:arstechnica.com",
"https://arstechnica.com"
]
},
"enforced": true
}

So
1. There are two different "systems" competing right now, with quite different behaviours. But they overlap, which is confusing.
- The system where everything starts with ...
Like "...arstechnica.com"
- The system where there is a whole URI
like "https://arstechnica.com"

A)group one look like this in your log "§:arstechnica." means "all of the site https site including subdomains". "https://art.arstechnica.net" counts.
the one with the full path on the other hand means "just exactly this one". It is still basically redundant. the one with the exact path is included in the one with §.
On the first visit it basically shows you everything twice or even several times. Once you can say "the whole page", which is the one with the ..., and above that are the "this specific URL" ones.
If for instance you made only the "https://arstechnica.com" rule, and not the §:arstechnica.com rule, it would further ask you about https://art.arstechnica.com.

B) these rules are HTTPS rules (green lock). and thus are written black in the UI. Which means if the website you visited was actually "http://arstechnica.com" it would still show being set to "default" and blocked.
Not because the temp rule didn't work or was removed, not because it is in untrusted.
But because you made a rule about HTTPS, but wouldn't be ON an HTTPS site.
In the log § also means HTTPS only.
For normal users (since the settings for untrusted and default are identical) specifically untrusting these is redundant. You basically would just leave them in "default" and then temp allow them.

C)Untrusted and the §. :
You never want that. It means "Please block the HTTPS part, but ask me again about HTTP. It only blocks HTTPS. Why would you ever want that? (this is a bug, because you can't choose "both" on untrusted. (no locks to click), you have to click trusted or custom, flip the lock to red and THEN push untrusted.
Important : This only counts for the ones in group1 above (...arstechnica)

D). Again the same logic for https and both Http/https.
If you trust ...arstechnica.com with the redlock rules including HTTP are red. meaning ...artstechnica.com reflects the red lock
It means "everything that ends with arstechnica.com, regardless of https or http. So it doesn't ask you about any of the others anymore. Because it already has a rule for all of those, and therefore knows what to do.

In the log it would be seen as just "arstechnica.com" without the §: in front.

E) And now for total confusion:
Things in Group 2 (at the start).
Those are SPECIFIC Urls.
Just go to imdb to see how that plays out in it's whole glory
There are a lot of urls of the group 2, but just a few of the [...] type.
The type 2 rules outright say if they are HTTP or HTTPS
Red lock and greenlock have no meaning here, there is no "http AND https" here
If you trust or untrust them, they will ONLY directly apply to that exact address.
They will show up as exact addresses in the log, too

I understand that this seems a bit convoluted. I basically made a flawed assumption about group2, and then had to rearrange everything to try to have SOME narrative structure.
But I hope it helps you avoid both making double rules (like you did above) and avoid the "resets to default" problem.
And don't concern yourself too much by the NUMBER of entries.
The rules you create often "remove" the lines that they automatically include, allowed or untrusted.
But when you allow something, the script sources that get loaded BY the scripts you just allowed add to the number again.

InformAction Forums

10.1.3c1 no better

Re: 10.1.3c1 no better

Re: 10.1.3c1 no better

Re: 10.1.3c1 no better

Re: 10.1.3c1 no better

Re: 10.1.3c1 no better

Re: 10.1.3c1 no better

Re: 10.1.3c1 no better