Skip to content
This repository was archived by the owner on Oct 24, 2021. It is now read-only.

Allow frames to act as their own origins for applying filter rules #22

Open
rhendric opened this issue Apr 10, 2021 · 0 comments
Open

Comments

@rhendric
Copy link

Is your feature request related to a problem? Please describe.

You're reading a page on someblog.com, which has an iframe referencing youtube.com. The youtube.com page references a bunch of other Google domains. You don't want the Google analytics scripts on someblog.com to load, so you have script requests from someblog.com to Google domains blocked. But watching any YouTube videos is already giving some information to Google, so you let general requests from youtube.com to Google domains through. However, this means that the youtube.com frame on someblog.com doesn't work correctly, because those requests are being checked against the someblog.com rules, even though you'd like to think of them as coming from youtube.com.

Describe the solution you'd like

There should be a way to delegate the authority to make requests from a frame to the origin of the frame. There are a few ways to do this that would make me personally happy, but I already have an approach implemented which doesn't change the semantics of existing rule sets, allows for the impact of the change to be limited in a detailed way, and only involves a modest addition to the UI. This approach is to create a new pseudo-request type called delegate. This type gets a new column in the matrix, and can be controlled by all the usual matrix rules. When, to reuse the example above, youtube.com makes a request to google.com from the iframe, first the matrix is checked if the triple someblog.com youtube.com delegate is allowed. If that triple is blocked, then someblog.com continues to be the effective origin for the request, and someblog.com google.com script is checked as usual. If the delegate triple is allowed, then youtube.com becomes the effective origin for the request, and youtube.com google.com script is checked instead. (This process generalizes for frames-in-frames-in-frames: if page A contains frame B contains frame C, and frame C makes a request, the effective origin starts as the host of A, and then the hosts of B and C are tested in order for delegate on the effective origin, and each replaces the effective origin if they succeed. The final effective origin is used as the origin for C's request.)

Describe alternatives you've considered

Simpler solutions could involve a single setting to enable or disable delegating across all origins, or on a per-origin basis, instead of adding the delegate type to the matrix. (Both of those approaches are of course representable within the matrix approach, with * * delegate allow and someblog.com * delegate allow rules, respectively.)

Additional context

I can't find the issue now, but I believe someone (not me) proposed something like this feature to gorhill many years ago, and gorhill was against it for unclear reasons. So I quietly implemented it for myself, and have been periodically maintaining my private fork. Now that uMatrix is archived, I'm looking for a new base and wondering if you'd be more receptive to upstreaming this feature.

Here are some screenshots:
Matrix for website with YouTube video

In this matrix, we see that the host website has made a frame request to youtube.com, and that frame has had 16 requests delegated to it. Notice that there are no other youtube.com requests in this matrix!

Host selector drop-down

To drill into the delegated requests, the host selector widget now has a drop-down list which shows other hosts that have had requests delegated to them on this page. Selecting youtube.com shows this:

Matrix for youtube.com

Now we can see the 16 requests that were delegated to this host, and we can see that the rules for youtube.com controlled whether they were allowed or blocked.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant