Opened 4 months ago

Closed 4 months ago

#34305 closed defect (fixed)

NoScript inconsistent behaviour in Firefox 77 (currently beta)

Reported by: acat Owned by: acat
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: noscript, ff78-esr, TorBrowserTeam202006
Cc: ma1, tbb-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

While working on fixing the testsuite (#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.

Basically, the issue is that with Tor Browser Safer NoScript configuration when visiting a http: page (containing a https: iframe) and then going to the https: version of the same page results in JavaScript being blocked, but it should not be. Manually reloading the https: page results in JavaScript being executed correctly.

After some effort, I managed to reproduce in current Firefox 77 beta directly, more specifically: f2e0df68e569b43ca337535927ed63068ed01c664eea7e397378cae668f63d0a firefox-77.0b9.tar.bz2. Tested with NoScript 11.0.26 and 11.0.25.

Steps to reproduce (in a fresh profile):

  • Install NoScript addon.
  • Go to NoScript options page (either via about:addons or via NoScript toolbar badge).
  • Enable "script" option and "Cascade top document's restrictions to subdocuments" in the General + Default tab.
  • Still in General, go to "UNTRUSTED" and enable "frame".
  • Go to "Per-site permission" tab and add a new rule: "http:" and mark it as "untrusted" (basically, setting non-https pages as untrusted).
  • Result: JavaScript is blocked, but it should not be. When the page is manually reloaded (press F5), the script is executed correctly, and the JavaScriptEnabled text is displayed.

Child Tickets

Change History (13)

comment:1 Changed 4 months ago by acat

Cc: ma1 added
Keywords: TorBrowserTeam201905 added
Status: newneeds_information

I bisected the issue down to https://bugzilla.mozilla.org/show_bug.cgi?id=1462989. Without that change, I cannot reproduce the bug. Of course, the underlying problem might be different, but at least it looks like that change exposed this.

ma1, could you please confirm this is a Firefox issue and not a NoScript one (which by some reason got exposed by https://bugzilla.mozilla.org/show_bug.cgi?id=1462989)? If so, I think we should file a bugzilla ticket for this.

comment:2 Changed 4 months ago by gk

Keywords: TorBrowserTeam202005 added; TorBrowserTeam201905 removed

comment:3 Changed 4 months ago by gk

Keywords: ff78-esr added

comment:4 Changed 4 months ago by acat

Cc: tbb-team added
Owner: changed from tbb-team to acat
Status: needs_informationassigned

comment:5 Changed 4 months ago by acat

Status: assignedneeds_information

comment:6 Changed 4 months ago by ma1

Sorry for the late answer, but I was unable to comment (the textarea was missing).
As correctly guessed by acat, the culprit isan implementation detail of https://bugzilla.mozilla.org/show_bug.cgi?id=1462989 (a webRequest listener can only either delete or merge CSP headers now, not both in the same callback), which combined to the fact CSP headers injected by extensions get cached by the browser and automatically reinserted in cached responses, can cause all sorts of confusions when policies change without cache-purging reloads.
The (quite annoying, but effective) work-around is uniquely "tagging" NoScript's CSP headers, to not interfere with page's own policies or other extensions (something NoScript already did) and registering a second auxiliary listener which just does the cleanup by removing the previously cached CSP headers.

I hope to release a development build containing this work-around later today or tomorrow, and a stable AMO auto-update within this week.

comment:7 Changed 4 months ago by acat

Status: needs_informationnew

Thanks! I think the response was actually pretty fast :)

comment:8 in reply to:  7 Changed 4 months ago by ma1

Replying to acat:

Thanks! I think the response was actually pretty fast :)

Please check https://github.com/hackademix/noscript/releases/tag/11.0.27rc1

Thanks you.

comment:9 Changed 4 months ago by acat

Thanks! It now works with the steps I mentioned, but the issue is still present with privacy.resistFingerprinting = true. More concretely, I can reproduce if I enable that pref and restart the browser, and then continue with the steps from the ticket description.

I think it may be simply because navigator.userAgent is spoofed. Maybe you could use browser.runtime.getBrowserInfo(), which always reports the right version?

comment:10 Changed 4 months ago by acat

In any case, this would not be an issue for Tor Browser ESR78.

comment:11 in reply to:  9 Changed 4 months ago by ma1

Replying to acat:

I think it may be simply because navigator.userAgent is spoofed.

Correct. However what's the point of spoofing in a WebExtension background page? Maybe another blocker for https://bugzilla.mozilla.org/show_bug.cgi?id=1450398 ?

Maybe you could use browser.runtime.getBrowserInfo(), which always reports the right version?

Yes, I had considered this, but I preferred to avoid it in early initialization code because it's an asynchronous API. However I've got hacks in places to make it a lesser issue, so I guess I can live with that. Switching to getBrowserInfo() in rc2.

comment:12 Changed 4 months ago by gk

Keywords: TorBrowserTeam202006 added; TorBrowserTeam202005 removed

Moving tickets to June.

comment:13 Changed 4 months ago by acat

Resolution: fixed
Status: newclosed

Thanks, this is fixed for me with noscript-11.0.27rc4.xpi.

Note: See TracTickets for help on using tickets.