1298856 - Soft block RequestPolicy when a WebExtension is installed

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect, P1)

Description

[Rob Wu [:robwu]]

RequestPolicy [1] is a popular security addon that blocks cross-domain requests by default .With default settings background pages do not load, without any obvious signs why (i.e. no specific console errors or anything).

In Firefox 48.0, the following error appears in the console:

[Exception... "Component returned failure code: 0x805e0006 [nsIWebNavigation.loadURI]"  nsresult: "0x805e0006 (<unknown>)"  location: "JS frame :: chrome://extensions/content/ext-backgroundPage.js :: build :: line 64"  data: no]: build@chrome://extensions/content/ext-backgroundPage.js:64:5
@chrome://extensions/content/ext-backgroundPage.js:120:3
EventEmitter_emit@resource://devtools/shared/event-emitter.js:163:11
emit@resource://gre/modules/Extension.jsm:229:29
runManifest@resource://gre/modules/Extension.jsm:1352:9
startup/<@resource://gre/modules/Extension.jsm:1424:14

This request is blocked because of a cross-origin a request from about:blank to a moz-extension://[uuid].
In Nightly the origin is no longer about:blank, but the request is still blocked because the origin is data:application/vnd.mozilla.xul+xml;charset=utf-8,%3C?xml%20version=%221.0%22?%3E%0A%20%20%3Cwindow%20id=%22documentElement%22/%3E

Is it feasible to initialize the origin to be the same as moz-extension://[uuid] to make sure that the presence of RequestPolicy does not block WebExtensions?

To work around the block for now, one has to add the [uuid] to the whitelist of RequestPolicy.

[1] https://addons.mozilla.org/en-US/firefox/addon/requestpolicy/

Comment 1

[:shell escalante]

needs engagement with author in bugzilla chat for input/potentially fixing in add-on

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

Justin, can you look into this?

Comment 3

[Rob Wu [:robwu]]

This issue also happens with its fork, RequestPolicy Continued - https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/

Comment 4

[Kris Maglione [:kmag]]

This is going to require some special code, but we should be able to do it easily enough, and get it uplifted. It might warrant a hotfix for release, too.

I'll see if I can get some metrics data on how many WebExtensions are currently installed alongside RequestPolicy, but I suspect that the numbers are pretty low, given that they won't actually work.

Jorge, any thoughts on this?

Comment 5

[Kris Maglione [:kmag]]

It turns out it's actually not currently possible to get this information from telemetry without correlating it with data from AMO.

Comment 6

[The 8472]

Note that RP has a preference "Allow requests that are needed for other extensions to work properly" that also lets the user block browser-internals. Maybe moz-extension:// has not been added to that whitelist yet.

Comment 7

[Kris Maglione [:kmag]]

Regardless of why it's happening, the author hasn't been responsive, and this is causing major problems, so we need to do something about it.

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

I contacted the RequestPolicy Continued dev just now, and the add-on is still active, so hopefully there will be a quick fix for that. The original RequestPolicy hasn't been updated since 2013, so I don't expect anything to happen on that front. If adding moz-extension to the extension's whitelist is possible, it sounds like the cleanest solution. If it comes down to blocking it, I'm open to that approach, but I hope the fork can fix this before so we can offer it as a viable alternative.

Comment 9

[Martin Kimmerle]

I've updated "RequestPolicy v0.5 Legacy" [1] to version 0.5.31 [2]. RP Legacy is the same as "RequestPolicy" [3], but with some bug fixes.

The change made in 0.5.31 is just one line [4]. It should be absolutely no problem to apply the patch to "RequestPolicy" as well. BTW shouldn't there be a way to inform the users of a non-maintained add-on about a maintained fork, like in this case? Or do you have some other solution?

I will update "RequestPolicy Continued" (currently 1.0.beta12.3) in the next few days as well.

[1] https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-legacy/
[2] https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-legacy/versions/0.5.31
[3] https://addons.mozilla.org/en-US/firefox/addon/requestpolicy/
[4] https://github.com/RequestPolicyContinued/requestpolicy/commit/4d46d25c7851e8881c831934e292ccfa93ba3ce0

(In reply to The 8472 from comment #6)
> Note that RP has a preference "Allow requests that are needed for other
> extensions to work properly" that also lets the user block
> browser-internals.

It's correct, this setting exists, but that ruleset is empty. The real whitelist has no user preference; it's always enabled, and hard-coded. There are issues on github about that.

Comment 10

[Martin Kimmerle]

RPC is now updated as well.
https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/1.0.beta12.4

Comment 11

[Andy McKay]

RPC has been updated as per comment 10. We are a couple of months away from Firefox 57 when this add-on will need to be updated to a WebExtension and (if read this correctly) the functionality mentioned in this add-on won't be able to run anyway. I suggest at this point we won't fix.