InformAction Forums

Have you got both ...linkedin.com and ...licdn.com set as TRUSTED?

Please check latest development build, thank you!

v 11.4.41rc1
============================================================
x Reduce cosole spam on non-debugging instances
x [nscl] Avoid patched workers breakage if console API is
disabled (thanks ayi for reporting)

Could you please tell us in NORMAL words why the extensions needs access to EVERYTHING we do on a website? NoScript does not "access" ANYTHING you do on a website, but in order to patch the execution environment and prevent the webpage (which most of the time WANTS DESPERATELY to spy on E...

Should be fixed (for real this time ) in latest dev build, thanks:

v 11.4.40rc1
============================================================
x [nscl] Fix patched workers failures caused by Firefox
webRequest filters disconnect() breaking on large files
(thanks barbaz for reporting)

OK, very strange thing I'm observing: if I've got the devtools panel open (ctrl+shift+K) I cannot reproduce, and the local engine works fine. In "normal" windows it gets most of the time stuck at "Loading engine..." on the switch. Puzzling... further investigation needed, but it'...

Fixed in latest rc:

v 11.4.39rc1
============================================================
x [nscl] Correctly propagate extra arguments to shadowed
worker constructors

Investigating, thanks.

Quoting the mandatory permission justification note I provided to the Chrome Store editors on submission: Using the debugger API is the only way to reliably inject scripts into workers, especially service workers, on Chrome: https://github.com/hackademix/nscl/blob/main/service/patchWorkers.js On Fir...

barbaz wrote: ↑Sat Aug 24, 2024 3:36 pm Does the "lazy load" capability apply to the document URL (like "unrestricted CSS" does)?

The former: it's a capability of the document triggering the load.

Could the neutralizing of lazy loading please be made optional? v 11.4.35rc3 ============================================================ x Gracefully handle new capabilities still unknown to the settings host (e.g. Tor/Mullvad browser), if any x Configurable "lazy_load" capability (see h...

fatboy wrote: ↑Tue Aug 20, 2024 8:29 pm > …"if I explicitly navigate to a website, I automatically trust it for this session"
And for all subsequent ones, even if it is not a session restore.

No: not until you actually navigate it back as a top level site.

Temp TRUSTED in classic NS had limited capabilities compared to TRUSTED. What is "Temp" now expressed in if the permission is actually issued forever? That's no "classic" vs "now". This option (which I personally don't like, but was requested by many users) has always ...

"Temp TRUSTED" should be canceled when the browser restarts.Isn't it? It is. If you open NoScript Options>Per Site Permissions at browser start, before you visit any site, you'll see the site(s) which were set to Temp TRUSTED in the previous session are gone away (except for session resto...

Open the "General" tab in the settings — "Temporarily set top-level sites to TRUSTED" is still checked. Umm...that's completely expected behavior. The temporary permission is being re-created the second time you visit example.com, exactly as specified by the setting. Yes it is. ...

If you check the General -> Temporarily set top-level sites to TRUSTED checkbox and restart (or close and start) the browser, then the temporary permissions are not canceled. I cannot reproduce, sorry. Could you provide step-by-step instructions, included how the temporary permissions were added, i...