Questions about new 'noscript' option

[guest]

Thanks for the new version 11.2.1!

Usually I have scripts disabled on websites which work fine without it. Now I need to enable the new 'noscript' option on some of them to make them work (or set the site to trusted).

What's the use of this? Shouldn't the default preset have this option enabled by default? Why does the trusted preset have this option, too?

[Giorgio Maone]

The "noscript" pseudo-capability should, indeed, be enabled by default in the DEFAULT preset.
In facts, that's the case if you install from scratch, and it was supposed to be the case if you upgraded from any version < 1.2.1rc4.
Unfortunately a little typo bug sneaked in, and the latter does not actually apply.
I'm trying to rush a quick minor update to limit the "damage", thanks.

[Quest]

And what's the purpose of this option?
What differences there are if allowed or not?
And should it be allowed and what if not?

[Giorgio Maone]

And what's the purpose of this option?
What differences there are if allowed or not?

It controls whether the <noscript> element is rendered or not (included emulating meta refreshes inside the element).
It's your choice, depending on the site. It has been requested by users who perceived some fallback content/behavior as an annoyance.
Personally I think it's better for the element to be rendered (NoScript emulates it on purpose, indeed, since CSP script blocking wouldn't render it per-se), and in facts the DEFAULT preset is meant to have it checked (even though, unfortunately, it didn't happen for upgrades from 11.2 because of the aforementioned bug).

It controls whether the <noscript> element is rendered or not (included emulating meta refreshes inside the element).
It's your choice, depending on the site. It has been requested by users who perceived some substitution content/behavior as an annoyance.

And should it be allowed and what if not?

Personally I think it's better to render <noscript> elements because it often contains useful fallbacks. NoScript emulates it on purpose, indeed, since CSP script blocking wouldn't render it per-se.
Because of this, the DEFAULT preset is meant to have it checked (even though, unfortunately, it didn't happen for upgrades from 11.2 because of the aforementioned bug).

[barbaz]

Why does the trusted preset have this option, too?

Sorry if I missed it, but I wonder the same but don't see the answer above? What does "noscript" capability do when enabled for a site that has scripts allowed?

And shouldn't this be enabled by default for Untrusted preset too?

[Giorgio Maone]

Why does the trusted preset have this option, too?

Sorry if I missed it, but I wonder the same but don't see the answer above? What does "noscript" capability do when enabled for a site that has scripts allowed?

It has it to avoid surprise when cascading restrictions.

And shouldn't this be enabled by default for Untrusted preset too?

My reasoning is that if you mark a site as UNTRUSTED you probably don't care (or even want to avoid) possibly annoying and/or tracking replacement content.
It's configurable, anyway.

[barbaz]

Why does the trusted preset have this option, too?

Sorry if I missed it, but I wonder the same but don't see the answer above? What does "noscript" capability do when enabled for a site that has scripts allowed?

It has it to avoid surprise when cascading restrictions.

Thanks. Just to make sure I have it right:

• on actually script-allowed sites, it does nothing;
• when "Cascade top documents restrictions..." is enabled, it controls:
  • whether <noscript> elements are shown in nominally-script-allowed subdocuments of script-blocked pages;
  • whether <noscript> elements are shown in script-blocked subdocuments of script-allowed pages.

Is this correct and complete?

[Giorgio Maone]

What does "noscript" capability do when enabled for a site that has scripts allowed?

It has it to avoid surprise when cascading restrictions.

Thanks. Just to make sure I have it right:

• on actually script-allowed sites, it does nothing;
• when "Cascade top documents restrictions..." is enabled, it controls:
  • whether <noscript> elements are shown in nominally-script-allowed subdocuments of script-blocked pages;
  • whether <noscript> elements are shown in script-blocked subdocuments of script-allowed pages.

Is this correct and complete?

Yes, it is (pending bugs )

[barbaz]

Thanks Giorgio I updated viewtopic.php?p=93552#p93552 with this information.

[noni]

i couldn't understand what's the purpose of this new "noscript" checkbox.

in Default and Untrusted i have nothing checked and i like it that way,i have no issues with it.
and in Trusted everything is checked apart from ping and "noscript".
for my use case;does checking "noscript" decrease the level of security i look for?

or could some one please provide a simpler explanation of this new checkbox?

Thanks.

[barbaz]

i couldn't understand what's the purpose of this new "noscript" checkbox.

in Default and Untrusted i have nothing checked and i like it that way,i have no issues with it.
and in Trusted everything is checked apart from ping and "noscript".
for my use case;does checking "noscript" decrease the level of security i look for?

or could some one please provide a simpler explanation of this new checkbox?

Thanks.

As said above -

It controls whether the <noscript> element is rendered or not (included emulating meta refreshes inside the element).
It's your choice, depending on the site. It has been requested by users who perceived some substitution content/behavior as an annoyance.

A "<noscript> element" contains content that should only be shown when scripts are disabled. For technical reasons, the browser does not show these with NoScript's method of blocking scripts, so NoScript must emulate the correct behavior. When this checkbox is unchecked, NoScript does not emulate the <noscript> element on script-disabled pages, resulting in <noscript> elements not being shown at all.

For security it doesn't matter whether it's checked or not.

[noni]

i think i understand.
I'll keep it unchecked.
Thanks @barbaz