Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When "Block remote fonts" is enabled, JavaScript is executed regardless of the uMatrix settings #502

Closed
7 of 8 tasks
diabonas opened this issue Apr 1, 2019 · 14 comments
Closed
7 of 8 tasks
Labels
external issue involving an external factor Firefox specific to Firefox fixed issue has been addressed

Comments

@diabonas
Copy link

diabonas commented Apr 1, 2019

Prerequisites

  • I verified that this is not a filter issue
  • This is not a support issue or a question
  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue
    • Your issue may already be reported.
  • I tried to reproduce the issue when...
    • uBlock Origin is the only extension → the issue happens in conjunction with uMatrix, which is the only other installed extension
    • uBlock Origin with default lists/settings → except "Block remote fonts", as indicated in the description below
    • using a new, unmodified browser profile
  • I am running the latest version of uBlock Origin
  • I checked the documentation to understand that the issue I report is not a normal behavior

Description

In Firefox, when the uBlock Origin option "Block remote fonts" is enabled, JavaScript is not blocked any more by uMatrix.

A specific URL where the issue occurs

https://javatester.org/javascript.html

Steps to Reproduce

  1. Create a fresh Firefox profile.

  2. Install uBlock Origin and uMatrix from https://addons.mozilla.org.

  3. Remove the default * 1st-party * allow rule from uMatrix so that JavaScript is disabled on all websites by default.

  4. Enable "Block remote fonts" under "Settings/Default behavior" in uBlock Origin.

  5. Restart Firefox (until the restart, everything works as expected).

  6. Open https://javatester.org/javascript.html and observe that JavaScript is executed.

    Note that the site additionally displays the <noscript> tag "JavaScript IS NOT WORKING in your web browser", unless "Spoof tags when 1st-party scripts are blocked" is disabled in uMatrix. However that doesn't mean that JavaScript is not running: the site displays the JavaScript and browser version, which wouldn't work with JavaScript disabled.

  7. For comparison, disable "Block remote fonts" in uBlock Origin and see how the test site renders with JavaScript disabled.

    Note that if you re-enable "Block remote fonts", JavaScript will stay disabled until you restart the browser.

Expected behavior:

JavaScript should not be executed if it is disabled in uMatrix.

Actual behavior:

JavaScript is executed on the test page and other websites if "Block remote fonts" is enabled in uBlock Origin, regardless of the uMatrix settings.

Your environment

  • uBlock Origin version: 1.18.14
  • uMatrix version: 1.3.16
  • Browser Name and version: Firefox 66.0.2
  • Operating System and version: Arch Linux (rolling release), also confirmed on Windows 7 Professional SP1
@gwarser
Copy link

gwarser commented Apr 1, 2019

Finally official issue for this :)

arkenfox/user.js#664

https://bugzilla.mozilla.org/show_bug.cgi?id=1462989

@gwarser gwarser added the Firefox specific to Firefox label Apr 1, 2019
@diabonas
Copy link
Author

diabonas commented Apr 1, 2019

Yikes, that's an ugly situation... Thank you very much for the pointers, I already suspected this might be an upstream issue, but didn't have an idea what to look for.

@gorhill
Copy link
Member

gorhill commented Apr 1, 2019

It can be fixed, but it's not a trivial one. This will require "compiling" the rules which can cause CSP directives injection into a contentScripts.register() -- a non-trivial workaround which would become pointless once the issue is fixed in Firefox. Now that is the "simple" part, even more complicated is enforcing the csp= directives in filter lists -- forget about this part.

It would be much simpler if this was just fixed in Firefox.

@uBlock-user
Copy link
Contributor

I opened that bug almost a year ago on bugzilla, no action has been taken so far, it's been queued into oblivion...

@uBlock-user uBlock-user added the external issue involving an external factor label Apr 1, 2019
@Cerberus-tm
Copy link

Hmm, this looks ugly. I haven't completed the steps in the first post. But I block remote fonts and Javascript by default, using Ublock Origin; even so, the Javascript isn't running for me on that site. So it is as desired and expected in my Firefox. Javascript is allowed for 1st-party in Umatrix. How come I am not affected? Is it because of other Ublock rules I might have?

@gorhill
Copy link
Member

gorhill commented Apr 16, 2019

How come I am not affected?

Because you are blocking inline JavaScript and inline fonts with uBO -- so uBO injects both CSPs, the issue is when two or more extensions try to inject CSPs.

@uBlock-user
Copy link
Contributor

uBlock-user commented Apr 16, 2019

the issue is when two or more extensions try to inject CSPs.

and at the website which itself doesn't insert any CSP headers in response header.

@Cerberus-tm
Copy link

How come I am not affected?

Because you are blocking inline JavaScript and inline fonts with uBO -- so uBO injects both CSPs, the issue is when two or more extensions try to inject CSPs.

And Umatrix + Ublock don't inject each its own CSP?

@gorhill
Copy link
Member

gorhill commented Apr 16, 2019

Umatrix + Ublock don't inject each its own CSP?

You said:

Javascript is allowed for 1st-party in Umatrix

@Cerberus-tm
Copy link

Cerberus-tm commented Apr 19, 2019

Umatrix + Ublock don't inject each its own CSP?

You said:

Javascript is allowed for 1st-party in Umatrix

Sorry, I'm a total layman. I'm afraid I wouldn't know when an extension injects a CSP. So when Javascript is **allowed** for 1st party in Umatrix, Umatrix doesn't inject a CSP on that page?

Is it only when Umatrix would forbid Javascript (following the result of its rules) that it injects a CSP? So if I tell Umatrix to block Javascript for site X, but then tell it to allow Javascript for a subdomain of site X—so that, as a result, Javascript is allowed on the subdomain—, then Umatrix is not injecting a CSP on pages of that subdomain?

And is it that a CSP concerning Javascript can only interfere with another Javascript CSP, not with e.g. an XHR rule, not even on the same subdomain? While inline Javascript and normal Javascript rules can interfere with each other? Hmm but that can't be true, since a rule about fonts does interfere with a rule about Javascript?

Is the best strategy, then, to always allow Javascript in Umatrix, for all domains, and manage all specific Javascript rules in Ublock? And to always allow fonts (I wonder how risky allowing fonts is these days...). At the moment, I block third-party Javascript in both Umatrix and Ublock, but that seems to work fine. Or is that an error?

Or is there another general strategy or work-around to follow?

Sorry about all these questions. One last one: Noscript can still block Javascript on a page even when combined with blocking rules from Umatrix and Ublock (I tested this). I wonder how that works. Presumably it does this through some unusual way that wouldn't work for Ublock/Umatrix?

@Cerberus-tm
Copy link

Cerberus-tm commented Apr 19, 2019

the issue is when two or more extensions try to inject CSPs.

and at the website which itself doesn't insert any CSP headers in response header.

Ah, so there is no problem as long as the website itself doesn't use a Javascript CSP? Or am I mistaken? I've voted for all the Bugzilla issues...

@gwarser
Copy link

gwarser commented Apr 20, 2019

arkenfox/user.js#664

Read more, write less, ask questions on reddit.

Noscript can still block Javascript...

Because NS forces its listener in a loop.

Ah, so there is no problem as long as the website itself doesn't use a Javascript CSP?

ANY CSP.

@uBlockOrigin uBlockOrigin locked and limited conversation to collaborators Apr 20, 2019
@gwarser
Copy link

gwarser commented Apr 15, 2020

@uBlock-user
Copy link
Contributor

@uBlock-user uBlock-user added the fixed issue has been addressed label Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
external issue involving an external factor Firefox specific to Firefox fixed issue has been addressed
Projects
None yet
Development

No branches or pull requests

5 participants