Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#14851 closed defect (fixed)

NoScript update caused permissions pref update

Reported by: mikeperry Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: TorBrowserTeam201502, tbb-pref
Cc: mcs, brade, gk, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If you download Tor Browser 4.0.2 from https://archive.torproject.org/tor-package-archive/torbrowser/4.0.2/, it comes with an old NoScript. If you go into the addons UI and update noscript by itself without updating Tor Browser, NoScript is able to change its defaults. For some reason, it does not do this upon update from 4.0.2 to 4.0.3.

The pref in question that is concerning is noscript.volatilePrivatePermissions. We want this to remain true, but updating noscript caused its new default value to become false.

There are two issues here: First, what is the best way to switch this pref back to true for our users? Can we simply update our extension-overrides.js file for this pref for update?

Second, what caused this discrepancy to happen? How do we prevent it in the future? Now that we have an updater, should we disable updates for NoScript and HTTPS-Everywhere in 4.5?

Child Tickets

Change History (10)

comment:1 Changed 5 years ago by arma

Mike, can you summarize the risk to our users for those who have the box checked now?

comment:2 Changed 5 years ago by gk

Cc: gk added

comment:3 in reply to:  description Changed 5 years ago by gk

Replying to mikeperry:

There are two issues here: First, what is the best way to switch this pref back to true for our users? Can we simply update our extension-overrides.js file for this pref for update?

Yes, it seems to work.

Second, what caused this discrepancy to happen? How do we prevent it in the future? Now that we have an updater, should we disable updates for NoScript and HTTPS-Everywhere in 4.5?

There is no discrepancy. You updated 4.0.2 to a NoScript version > 2.6.9.10 which has the pref in question set to false. 4.0.3 is shipped with NoScript 2.6.9.10 which has it still set to true. If you update the NoScript in 4.0.3 you get the same problem.

I think the only way to reliably prevent that issue generally is indeed to ship NoScript (and HTTPS-E) updates only via our updater. The NoScript release speed makes this probably not feasible for us at the moment but I think we should and could start with HTTPS-E (#10394) and see how it goes just taking important security related updates justifying an out-of-order release. We could start monitoring the NoScript releases with the same criteria in mind to get a handle on how many additional releases we would need to do approximately. I might even volunteer for that task as having these extensions just updating themselves makes me quite nervous.

Last edited 5 years ago by gk (previous) (diff)

comment:4 Changed 5 years ago by boklm

Cc: boklm added

comment:5 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201502R tbb-pref added; TorBrowserTeam201502 removed

comment:6 Changed 5 years ago by mikeperry

arma: The risk from this is leaking to disk the sites you have allowed (hence the tbb-disk-leak tag).

comment:7 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201502 added; TorBrowserTeam201502R removed
Resolution: fixed
Status: newclosed

Ok, I pushed the extension-overrides update for this pref for TBB 4.0 and 4.5.

comment:8 in reply to:  6 Changed 5 years ago by arma

Replying to mikeperry:

arma: The risk from this is leaking to disk the sites you have allowed (hence the tbb-disk-leak tag).

Do they get deleted from disk when the pref changes?

That is, is there some further step we need to take for the users who have already been bitten to help them recover?

comment:9 Changed 5 years ago by mikeperry

Keywords: tbb-disk-leak removed

Actually, after testing, it seems that even with this pref set, allowed sites weren't hitting the disk. This is because we only expose "Temporarily allow all this site" in our NoScript menu, which used the temporary store regardless of this pref value.

So, as a result this was only a disk leak for people who actually altered their NoScript menu to expose menu options that we normally don't (such as "Allow [...]"). Changing NoScript settings like that is unsupported. There are tons of ways to get it to do bad things that way, which I have no interest in trying to clean up after...

comment:10 Changed 5 years ago by mikeperry

Incidentally, we also clear temporary site permissions on New Identity.

Note: See TracTickets for help on using tickets.