Loading entities from NoScript .dtd files is blocked

added component::applications/tor browser noscript owner::tbb-team priority::high resolution::fixed severity::major status::closed type::defect labels

comment:19:ticket:23718 seems to indicate that our defense against fingerprinting users by probing for re/- and chrome://-URIs might be the culprit: a workaround would be to set extensions.torbutton.resource_and_chrome_uri_fingerprinting to true.

So, it still seems to me that this issue alone is not breaking NoScript funtionality. Or am I missing something?

Something with whitelist, but could be unrelated. As our #8725 (moved) is more restrictive than Mozilla's implementation (landed on FF57), what is the right direction to go: enforce & upstream (and fix NoScript) or relax & backport?

Replying to gk:

: a workaround would be to set extensions.torbutton.resource_and_chrome_uri_fingerprinting to true.

I'm implementing this in next dev build, out in minutes, and it apparently works, with exposure minimized to the quasy-synchronous (local filesystem) load/parsing.

You can preview it by running this code in a browser-scoped Scratchpad window with any NoScript 5.1.x installed:

{
  let xhr = new XMLHttpRequest();
  xhr.open("GET", "chrome://noscript/content/noscriptOverlayFx57.xul");
  try {
    // work around to resolve overlay's XML entities despite the Tor Browser
    
    let TOR_PREF = "extensions.torbutton.resource_and_chrome_uri_fingerprinting";
    let torPrefValue = Services.prefs.getBoolPref(TOR_PREF);
    let restorePref = () => Services.prefs.setBoolPref(TOR_PREF, torPrefValue);
    for (let e of ["progress", "loadend"]) { // restore as early as possible (almost sync)
      xhr.addEventListener(e, restorePref);
    }
    xhr.addEventListener("loadstart", () => {
      Services.prefs.setBoolPref(TOR_PREF, true);
    });
    
  } catch (e) {
    // no pref value, it doesn't seem to be a Tor Browser :)
  }
  xhr.addEventListener("load", () => {
    alert(xhr.responseXML.getElementById("noscript-tbb"));
  });
 xhr.send()
}

Notice that 5.1.2rc1 with the work-around mentioned above is now out on AMO (Beta channel) and https://noscript.net/getit#devel

Please let me know if it needs to go in the release channel or a different approach is preferred, thanks.

Replying to ma1:

Notice that 5.1.2rc1 with the work-around mentioned above is now out on AMO (Beta channel) and https://noscript.net/getit#devel

Please let me know if it needs to go in the release channel or a different approach is preferred, thanks.

Thanks. I think we should wait a bit until it hits your release channel until we figured out what is causing #23724 (moved). Could you have a look at that one, too? It seems to me there are things broken in vanilla Firefox 52 ESR as well when the update happens. I am not sure yet whether it is a bad as in Tor Browser but there are similar error messages like

CustomizableUI:Widget 'noscript-tbb' not found, unable to move  CustomizableUI.jsm:1149
can't access dead object  WebExt.js:17
	tell chrome://noscript/content/WebExt.js:17:7
	saveData chrome://noscript/content/WebExt.js:7:5
	ns.savePrefs chrome://noscript/content/Main.js:1279:9
	ns.dispose chrome://noscript/content/Main.js:891:7
	ns.shutdown chrome://noscript/content/Main.js:216:5
	autoSync/obj[method] chrome://noscript/content/e10sIPC.js:45:16
	shutdown chrome://noscript/content/Restartless.jsm:58:3
	shutdown jar:file:///home/thomas/.mozilla/firefox/bm8w2fpw.noscript1/extensions/%7B73a6fe31-595d-460b-a920-fcc0f8843232%7D.xpi!/bootstrap.js:30:5
	this.XPIProvider.callBootstrapMethod re[/gre/modules/addons/XPIProvider.jsm:4968:9](/gre/modules/addons/XPIProvider.jsm:4968:9)
	startInstall/< re[/gre/modules/addons/XPIProvider.jsm:5859:15](/gre/modules/addons/XPIProvider.jsm:5859:15)
	InterpretGeneratorResume self-hosted:1213:8
	next self-hosted:1120:9
	TaskImpl_run re[/gre/modules/Task.jsm:319:42](/gre/modules/Task.jsm:319:42)
	bound TaskImpl_run self-hosted:957:17
	Handler.prototype.process re[/gre/modules/Promise-backend.js:932:23](/gre/modules/Promise-backend.js:932:23)
	this.PromiseWalker.walkerLoop re[/gre/modules/Promise-backend.js:813:7](/gre/modules/Promise-backend.js:813:7)
	bound  self-hosted:913:17
	bound bound  self-hosted:913:17
	this.PromiseWalker.scheduleWalkerLoop/< re[/gre/modules/Promise-backend.js:747:11](/gre/modules/Promise-backend.js:747:11)
No chrome package registered for chrome://noscript/locale/about.properties

that make me nervous. For instance one visible thing is that the NoScript icon gets suddenly moved to the right side of the toolbar, a thing we can observe in Tor Browser as well.

??? How did you test that? For correct testing it's necessary to do a restartless update of the 5.1.2rc1 (with workaround) to something newer. Update: Oh, wait. You're testing another bug...

Trac:
Status: new to needs_information

Replying to cypherpunks:

??? How did you test that? For correct testing it's necessary to do a restartless update of the 5.1.2rc1 (with workaround) to something newer. Update: Oh, wait. You're testing another bug...

Trying to figure out whether entities in .dtd files get properly resolved does not necessarily need to get tested via an update I think. I guess you mean #23724 (moved).

Trac:
Status: needs_information to assigned

Trac:
Cc: ma1 to ma1, arthuredelstein

Thanks for fixing, Giorgio.

Trac:
Resolution: N/A to fixed
Status: assigned to closed

closed

mentioned in issue #23724 (moved)

moved to tpo/applications/tor-browser#23723 (closed)

Loading entities from NoScript .dtd files is blocked

Child items ...

Activity