RP blocks NoScript resources

[wilkowy]

Request Policy blocks „noscript_0.#####” resources again. This was previously mentioned and fixed here: #788 (comment)

Fx 48.0.2
RP 1.0.beta13.2.1876.r489ddf49pre / default: deny

[myrdd]

@wilkowy how does the URI exactly look like? You get it from the request log.

[wilkowy]

Sorry, I got it wrong, it is not actually blocked. It started to appear in popup again, but in fact it is under „allowed connections” with „?”, not „other”. However in previous versions such entry was hidden from a view (same as „pluginproblem” I noticed as well)

In log it is recorded as resource://noscript_0.7086678826471293/flash16.png The „7086678826471293” part are random digits (they change every fx run). The log does not inform about blocking. So the issue is only partly correct.

[myrdd]

I see. The change has been introduced in commit 4220818#diff-1b7e0f7951478bbe351c234b42abb31bR196. Since then, resource://noscript_*/**/* (and pluginproblem) is allowed "by default":

requestpolicy/src/content/lib/request.js

Lines 222 to 264 in 061b3f9

	Request.prototype.isAllowedByDefault = function() {
	if (
	this.aExtra &&
	this.aExtra instanceof Ci.nsISupportsString &&
	this.aExtra.data === "conPolCheckFromDocShell"
	) return true;
	if (
	this.aRequestPrincipal &&
	Services.scriptSecurityManager.isSystemPrincipal(
	this.aRequestPrincipal)
	) return true;
	let origin = this.originUriObj;
	let dest = this.destUriObj;
	if (
	origin && DEFAULT_ALLOWED_SCHEMES.has(origin.scheme) ||
	DEFAULT_ALLOWED_SCHEMES.has(dest.scheme)
	) return true;
	if (dest.scheme === "chrome") {
	// Necessary for some Add-ons, e.g. "rikaichan" or "Grab and Drag"
	// References:
	// - RP issue #784
	if (dest.path.startsWith("/skin/")) return true;
	// See RP issue #797
	if (dest.spec === "chrome://pluginproblem/content/pluginProblem.xml") {
	return true;
	}
	}
	let destHost = DomainUtil.getHostByUriObj(dest);
	if (
	dest.scheme === "resource" && (
	destHost && destHost.startsWith("noscript_") || // RP issue #788
	DEFAULT_ALLOWED_DESTINATION_RESOURCE_URIS.has(dest.spec)
	)
	) return true;
	return false;
	};

I agree "allowed by default" is not fully correct here. It's "allowed by hardcoded rules".

[myrdd]

The WebExtension version won't have this issue anymore, because chrome and resource uris cannot be blocked by a WE. So this is a (low-prio) XPCOM-only issue.