New Features Opt In, Perhaps?

[Mad_Man_Moon]

Not sure if this is impertinent ... but would it perhaps be possible for new features to be opt-in?

I'm particularly referring to new capabilities that we can choose for given domains in the setup (especially for the 'custom' key, though) ... because ... as of my most recent update I've just seen stuff enabled on a bunch of sites that I didn't wish for it to be enabled for ... I have no idea what's now gone their way, unfortunately

I'm not complaining, or shouting about it ... just ... perhaps it could be a consideration for the future?

(the most recent addition is web assembly, I think)

[Giorgio Maone]

When new capabilities are added to NoScript, they're never configured allow sites to do more than they can already do, but on the opposite to provide users with the ability to block stuff that was previously not possible to control.

What's the"stuff enabled on a bunch of sites that I didn't wish for it to be enabled for" you've noticed, exactly?

[barbaz]

What's the"stuff enabled on a bunch of sites that I didn't wish for it to be enabled for" you've noticed, exactly?

(the most recent addition is web assembly, I think)

The "wasm" capability should only be enabled in presets or CUSTOMs for which you had "script" enabled. But NOT added where "script" was disabled. This actually *is* the opt-in arrangement, since it keeps your existing permissions to be exactly the same as before the capability was added.

The same should be true for other new capabilities: enabled where your pre-existing permissions would've allowed them before, disabled where your existing permissions did not already allow the thing the new capability controls.

Could you please be more specific about what you saw and how it was different from this?

[Mad_Man_Moon]

Aha, cheers, both.

So web assembly and javascript are the same thing ... good to know!

What's the"stuff enabled on a bunch of sites that I didn't wish for it to be enabled for" you've noticed, exactly?

(the most recent addition is web assembly, I think)

The "wasm" capability should only be enabled in presets or CUSTOMs for which you had "script" enabled. But NOT added where "script" was disabled. This actually *is* the opt-in arrangement, since it keeps your existing permissions to be exactly the same as before the capability was added.

The same should be true for other new capabilities: enabled where your pre-existing permissions would've allowed them before, disabled where your existing permissions did not already allow the thing the new capability controls.

Could you please be more specific about what you saw and how it was different from this?

When new capabilities are added to NoScript, they're never configured allow sites to do more than they can already do, but on the opposite to provide users with the ability to block stuff that was previously not possible to control.

What's the"stuff enabled on a bunch of sites that I didn't wish for it to be enabled for" you've noticed, exactly?

[barbaz]

So web assembly and javascript are the same thing ...

From a NoScript user's point of view, yes and no:
- Yes in that both are active content code that a website can run, and NoScript's security & trust model doesn't particularly depend on what language active content code is written in.
- No in that WebAssembly is binary code (compiled to WebAssembly-specific bytecode, *not* platform-native binary code!) whereas Javascript is interpreted text code.

Also AFAIK the only way for a website to run WebAssembly code is by Javascript code calling to run it. As such, the "wasm" capability is a subset of the "script" capability, it only has meaning when "script" is enabled.

[barbaz]

Just realized the sticky wasn't yet updated with info about "wasm" - have now updated it with my understanding of the "wasm" capability.