Adding New Version Revokes Temporary Permissions

Bug reports and enhancement requests
User avatar
therube
Ambassador
Posts: 7669
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Adding New Version Revokes Temporary Permissions

Post by therube » Sat Aug 08, 2020 11:43 am

Adding New Version Revokes Temporary Permissions, or something along those lines.
At the least, most (99%, if not 100%) of Temporary Allow's are being reset back to Default.
Is that supposed to happen?
(Probably been that way for at least the last couple rc updates.)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.4

barbaz
Senior Member
Posts: 9666
Joined: Sat Aug 03, 2013 5:45 pm

Re: Adding New Version Revokes Temporary Permissions

Post by barbaz » Sat Aug 08, 2020 4:53 pm

I think NoScript doesn't store temporary permissions anywhere persistent, so it's expected that would be wiped on updates.
*Always* check the changelogs BEFORE updating that important software!
-

User avatar
Giorgio Maone
Site Admin
Posts: 8938
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Adding New Version Revokes Temporary Permissions

Post by Giorgio Maone » Mon Aug 17, 2020 11:04 pm

Temporary permissions are meant not to be persisted in any way on the disk, and therefore they cannot survive browser reloads, including on updates.
Except...:
v 11.0.39rc2
============================================================
x Let temporary permissions survive NoScript updates
(shameless hack)

x Fixed some traps around Messages abstraction
x Ignore search / hash on policy matching of domain-less
URLs (e.g. file:///...)
x Removed useless CSS property
x Updated TLDs
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

barbaz
Senior Member
Posts: 9666
Joined: Sat Aug 03, 2013 5:45 pm

Re: Adding New Version Revokes Temporary Permissions

Post by barbaz » Tue Aug 18, 2020 12:20 am

Giorgio Maone wrote:
Mon Aug 17, 2020 11:04 pm
Temporary permissions are meant not to be persisted in any way on the disk, and therefore they cannot survive browser reloads, including on updates.
Except...:
v 11.0.39rc2
============================================================
x Let temporary permissions survive NoScript updates
(shameless hack)
Could you please make this behavior optional, and delete this new temporary-permanent storage when user disables the option? Not only for the reason you already stated, there's also:

1) Based on recalling past changes to NoScript, it would seem this breaks some Tor browser users' security and privacy model.

2) People like me who typically run browser in a sandbox intentionally minimise persistence of things we don't intend to be somewhat permanent. This persistence is out of line here.

3) This behavior is counter-intuitive, at least to advanced users. We expect temporary stuff like this to get wiped on extension reload/update.

Thanks!

(I'm not sure what the best default of such option would be?)
*Always* check the changelogs BEFORE updating that important software!
-

User avatar
Giorgio Maone
Site Admin
Posts: 8938
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Adding New Version Revokes Temporary Permissions

Post by Giorgio Maone » Tue Aug 18, 2020 7:06 am

barbaz wrote:
Tue Aug 18, 2020 12:20 am
1) Based on recalling past changes to NoScript, it would seem this breaks some Tor browser users' security and privacy model.
I think you'll change your mind If you look at how the hack is implemented:
  • As soon as a NoScript update is ready to be installed (and only in that case), the volatile data is strongly encrypted (extra-paranoid step to avoid leaking / tempering by means of an hypothetical sandbox/SOP bypass) and stored in an ad-hoc temporary about:blank tab and only the encryption key and the tab id are temporarily saved in local storage ("updateInfo" object, it's the only data to hit the disk). To be extra cautious about this (for the Tor-like use cases / policies), if a private window exists the tab is opened there to prevent any (very unlikely) persistence of it through session restore. Then the extension is immediately reloaded and the update applied.
  • A few milliseconds later, as soon as the new version is loaded, it checks for the existence of the "updateInfo" object in local storage, and if it's found (meaning there's some volatile data to be restored) it uses it to find the tab, retrieve the data, decrypt it and restore it, while both destroying the tab and removing the "updateInfo" data from local storage.
barbaz wrote:
Tue Aug 18, 2020 12:20 am
2) People like me who typically run browser in a sandbox intentionally minimise persistence of things we don't intend to be somewhat permanent. This persistence is out of line here.
You're mostly unaffected, i.e. the above happen exclusively in case of an automatic upgrade of the extension, and not in any other case of extension reload.
barbaz wrote:
Tue Aug 18, 2020 12:20 am
3) This behavior is counter-intuitive, at least to advanced users. We expect temporary stuff like this to get wiped on extension reload/update.
I don't believe people "expects" an update. It just happens, and it can be quite disruptive if temporary permissions (e.g. a restrictionless tab) get wiped out in the middle of a financial transaction or a long uncommitted work.
As for the other cases (reinstalling, disabling/enabling, manually reloading) as I said this mechanism just does not apply.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

User avatar
therube
Ambassador
Posts: 7669
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: Adding New Version Revokes Temporary Permissions

Post by therube » Tue Aug 18, 2020 9:56 am

1. can't comment, don't know tor
2. hardly see where that applies, nothing changing only an extension got updated somewhere along your workflow
3. agree fully

That said, didn't work (on my end).
Specifically (Temporarily) Allowed yahoo.com & informaction.com.
Downloaded .39rc2 - locally (in case that matters).
Dragged .39rc2 into nightly (in case that matters, 20200817093723).
Permissions reset.

(Oh, FF had downloaded a pending [.mar] updated, which I had not yet effected [aka, restarted the browser], in case that matters.
Don't see why it would as it affects instalDir, not ones Profile, plus I hadn't restarted, which is when NoScript TA's would reset.)

(Let me update... drag .39rc1 in [downdate ;-)] & try again...)


Before I do that...

Actually, Per Site Permissions does not show yahoo.com or informaction.com - at all, not there - even though the pages are most certainly, open.


So... (does it ever end)...

Dragged .39rc1 into NoScript Settings window (figuring I'd watch as permissions reset)
Probably shouldn't have done that ? as "nothing happened"
Dragged .39rc1 into Yahoo windows (figuring, can't hurt)
"Nothing happened"
Refreshed NoScript Settings window
Dragged .39rc1 into Yahoo windows (figuring, can't hurt)
"Nothing happened"
Checked Profile & .39rc1 is there, /staged/ (so I guess I'll restart...)

No dice.

Gone from /staged/, but .39rc2 has persisted (so says manifest.json)

Try again...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.5

User avatar
Giorgio Maone
Site Admin
Posts: 8938
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Adding New Version Revokes Temporary Permissions

Post by Giorgio Maone » Tue Aug 18, 2020 10:16 am

therube wrote:
Tue Aug 18, 2020 9:56 am
That said, didn't work (on my end).
Specifically (Temporarily) Allowed yahoo.com & informaction.com.
Downloaded .39rc2 - locally (in case that matters).
Dragged .39rc2 into nightly (in case that matters, 20200817093723).
Permissions reset.
Entirely expected. As explained in my post above, the entire mechanism is triggered exclusively by the availability of an automatic update, i.e. the browser detecting and downloading a new NoScript version either from AMO's stable channel or from software.informaction.com for those who are in the beta one has a new version.

Disabling/enabling, manually installing, restarting the browser and such won't do it, by design.
You must wait for 11.0.39rc3 (or 11.0.40rc1, if that is skipped, or 11.040 if you're on the stable channel) to see it in action, unless you're willing to use about:debugging, inspect NoScript's background script and run this test code in the console:

Code: Select all

await include("/bg/LifeCycle.js"); await LifeCycle.onUpdateAvailable({version: browser.runtime.getManifest().version})
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

User avatar
therube
Ambassador
Posts: 7669
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: Adding New Version Revokes Temporary Permissions

Post by therube » Tue Aug 18, 2020 10:21 am

Oh, in that case, that behavior is wrong (IMHO).
Why should it matter if the update is "automatic" from AMO/information or if it is manually effected from a locally installed copy of the .xpi (unless you hack is specifically dealing with only "automatic")?


(I almost always download directly, once, & install locally - all extensions [often into multiple Profiles].)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.5

User avatar
therube
Ambassador
Posts: 7669
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: Adding New Version Revokes Temporary Permissions

Post by therube » Tue Aug 18, 2020 10:27 am

Separately...

Downgrades .39rc2 to .39rc1 aren't working?
.39rc1 does get into /staged/ - where it persists, instead of installing
after a browser restart
/staged/ is empty (expected, actually expected that /staged/ would not exist)
yet .39rc2 persists.


(Again, all done locally.)


Manually remove... Restart...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.5

User avatar
Giorgio Maone
Site Admin
Posts: 8938
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Adding New Version Revokes Temporary Permissions

Post by Giorgio Maone » Tue Aug 18, 2020 10:28 am

therube wrote:
Tue Aug 18, 2020 10:21 am
Why should it matter if the update is "automatic" from AMO/information or if it is manually effected from a locally installed copy of the .xpi (unless you hack is specifically dealing with only "automatic")?
It matters because automatic restartless updates are IMHO the only case justifying such a measure, in order to minimize the disruption caused by a sudden, stealthy and unintended change in the permissions out of user's control (again, see my last point above).

If you only perform manually updates you know exactly what you're doing, and you're very unlikely to be doing it while in the middle of a financial transaction or of a long multi-page wizard / form.

On the other hand, after some more testing, it seems that unfortunately the WebExtensions API does not dicriminate a "drag & drop" update from an automatic one.
Therefore temporary permissions should survive that (but not disabling/enabling nor uninstalling/reinstalling).

And that's also the reason of the "no downgrades" bug you're seeing (the downgrade will happen only if you manually restart either the browser or the extension) which I'm fixing in RC3, thanks for spotting it ;)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

User avatar
therube
Ambassador
Posts: 7669
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: Adding New Version Revokes Temporary Permissions

Post by therube » Tue Aug 18, 2020 10:34 am

Well of course I know what I'm doing, & am specifically doing it, but I fail to see how that matters.
I'm in a long browsing session, been everywhere, doing everything, have all kinds of Temporary Allows set.

I visit a forum, say information.com, & see that there is a new .rc & I say, hey, hotkeys now work, Ctrl+Shift+\ :-) :-) :-) - just what I wanted! So I download (locally) .39rc2+, drag it in, & wham bam thank you ma'am, all my TA's have been reset? (Not expected behavior.)


(Now, prior to restartless, you knew you had to restart, you knew if you did, your TA's would be reset. That is understandable.)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.5

User avatar
Giorgio Maone
Site Admin
Posts: 8938
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Adding New Version Revokes Temporary Permissions

Post by Giorgio Maone » Tue Aug 18, 2020 10:40 am

therube wrote:
Tue Aug 18, 2020 10:34 am
I visit a forum, say information.com, & see that there is a new .rc & I say, hey, hotkeys now work, Ctrl+Shift+\ :-) :-) :-) - just what I wanted! So I download (locally) .39rc2+, drag it in, & wham bam thank you ma'am, all my TA's have been reset? (Not expected behavior.)
(Now, prior to restartless, you knew you had to restart, you knew if you did, your TA's would be reset. That is understandable.)
As stated in my last post, I've just realized your use case has been (unintendedly) covered as well, while introducing a small "delayed downgraded" regression, which I'm fixing in RC3.
Try to install RC2 over RC2, and your temp permissions should survive.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

User avatar
therube
Ambassador
Posts: 7669
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: Adding New Version Revokes Temporary Permissions

Post by therube » Tue Aug 18, 2020 10:40 am

Where was I... Manually remove...

Install .39rc1 (fresh), that worked
Install .38rc2 (overtop), that worked
Install .39rc2 (overtop), that worked
Install .38rc2 (overtop), fails

Seems you can't downgrade from .39rc2 - without actually Removing .39rc2. first.


(All I can do for now. Gotta run...)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.5

barbaz
Senior Member
Posts: 9666
Joined: Sat Aug 03, 2013 5:45 pm

Re: Adding New Version Revokes Temporary Permissions

Post by barbaz » Tue Aug 18, 2020 12:43 pm

Giorgio Maone wrote:
Tue Aug 18, 2020 7:06 am
I think you'll change your mind If you look at how the hack is implemented:
  • As soon as a NoScript update is ready to be installed (and only in that case), the volatile data is strongly encrypted (extra-paranoid step to avoid leaking / tempering by means of an hypothetical sandbox/SOP bypass) and stored in an ad-hoc temporary about:blank tab and only the encryption key and the tab id are temporarily saved in local storage
Sorry, I misunderstood that code :oops: I thought the temporary permissions themselves were stored encrypted. Yes I agree that one is not a concern.
Giorgio Maone wrote:
Tue Aug 18, 2020 7:06 am
barbaz wrote:
Tue Aug 18, 2020 12:20 am
3) This behavior is counter-intuitive, at least to advanced users. We expect temporary stuff like this to get wiped on extension reload/update.
I don't believe people "expects" an update. It just happens, and it can be quite disruptive if temporary permissions (e.g. a restrictionless tab) get wiped out in the middle of a financial transaction or a long uncommitted work.
As for the other cases (reinstalling, disabling/enabling, manually reloading) as I said this mechanism just does not apply.
Thanks, that makes clear that if this behavior is optional, it should be default-enabled. But unfortunately it doesn't address the reasons to make this behavior optional. As you found out -
Giorgio Maone wrote:
Tue Aug 18, 2020 10:28 am
it seems that unfortunately the WebExtensions API does not dicriminate a "drag & drop" update from an automatic one.
That's the root of my concerns (2) and (3). I do see how this feature would be important in case of automatic update happening during someone's browsing. But I update extensions manually, I only receive updates when I actively decide to. This changes expectations.

So I still request: Could you please make this behavior optional, default enabled, and delete this new temporary-permanent storage when user disables the option? Thanks.
*Always* check the changelogs BEFORE updating that important software!
-

User avatar
Giorgio Maone
Site Admin
Posts: 8938
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Adding New Version Revokes Temporary Permissions

Post by Giorgio Maone » Tue Aug 18, 2020 3:53 pm

barbaz wrote:
Tue Aug 18, 2020 12:43 pm
So I still request: Could you please make this behavior optional, default enabled, and delete this new temporary-permanent storage when user disables the option? Thanks.
Please check latest development build:
v 11.0.39rc4
============================================================
x Added option to forget temporary settings immediately
whenever NoScript gets updated

x Fixed regression: file:/// URLs reloaded whenever NoScript
gets reinstalled / enabled / reloaded
x More resilient and easy to debug survival data retrieving
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Post Reply