Compatibility with uMatrix

[nihil-admirari]

Hi.

I'm switching from Invidition, which is no longer maintained. Its README says that extensions using WebRequest API (such as uMatrix) need configuration since they tend to block requests before Invidition has a chance to redirect them. Invidition does provide a ruleset for uMatrix.

Does Privacy Redirect require any uMatrix rules for proper functioning?

[SimonBrazell]

Hi @nihil-admirari I don't use uMatrix myself, I find it makes browsing more of a chore, but that's just me, so I'm not sure about this one, have you tried the ruleset listed for Invidition with Privacy Redirect?

[nihil-admirari]

Well, I replaced Invidition with Privacy Redirect and tested. Looks like Invidition's uMatrix rules are really necessary. Unfortunately, I encountered two problems.

First, Privacy Redirect does not intercept calls to iframe_api and www-widgetapi.js, which Invidition did:

youtube.com and s.ytimg.com scripts are mandatory because of the YouTube iFrame API. ... So, the browser needs first to load a script called iframe_api on youtube.com and then load a script called www-widgetapi.js on s.ytimg.com. To bypass this need, those two files have been integrated in the extension, so you never have to call youtube to generate the iFrame.

Can you please add local copies of these two files into Privacy Redirect to make sure that no requests ever reach YouTube?

Second problem is that video embedding does not seem to work at all. When I visit e.g. https://course.fast.ai/videos/?lesson=1 with Privacy Redirect, I get

The loading of “https://invidious.snopyta.org/embed/_QUEXsHfsA0?autoplay=0&mute=0&controls=1&origin=https%3A%2F%2Fcourse.fast.ai&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&local=true&player_style=youtube&autoplay=0” in a frame is denied by “X-Frame-Options“ directive set to “DENY“.

When I visit the same page with Invidition, there is still x-frame-options: DENY is response headers, but it looks like Invidition ignores it.

[SimonBrazell]

First, Privacy Redirect does not intercept calls to iframe_api and www-widgetapi.js, which Invidition did

I did have this implemented in the past in exactly the same way but Mozilla pulled my build from the store saying I can't submit builds with compiled code, I'll find a reference for you, on the mobile atm. So I removed this feature from the build rather than maintain two versions of the extension. I suspect Invidition will run into the same issue eventually if they continue submitting new builds to AMO, or maybe I was just unlucky?

[SimonBrazell]

58

[SimonBrazell]

Not sure about the second problem, haven't encountered this myself, have you tried a different instance?

[nihil-admirari]

I did have this implemented in the past in exactly the same way but Mozilla pulled my build from the store

Ok, I see. I maybe asking too much, but could you try to repackage these files with minor modifications? Mozilla reviewer was dissatisfied with the code written by Google engineers:

var a = document.createElement('script');
a.src = 'https://s.ytimg.com/yts/jsbin/www-widgetapi-vflYl14TA/www-widgetapi.js';
var b = document.getElementsByTagName('script')[0];
b.parentNode.insertBefore(a, b);

What if instead of providing a verbatim copy of https://youtube.com/iframe_api, addon asset had a slightly patched one:

a.src = browser.runtime.getURL('/assets/www-widgetapi.js');

Not sure about the second problem, haven't encountered this myself, have you tried a different instance?

I had success with https://invidious.fdn.fr. https://invidious.ggc-project.de displayed an error: “The media could not be loaded, either because the server or network failed or because the format is not supported.” https://yewtu.be returns x-frame-options: sameorigin. Other instances look completely dysfunctional; that's why I always use https://invidious.snopyta.org.

Invidition did handle x-frame-headers, see injectCSP. Can you please add that feature as well?

[seniorm0ment]

I haven't had any issues personally using uMatrix, as long as you don't block the domain.

For example if you set uMatrix to block Twitter domains, it won't redirect to Nitter because it didn't reach Twitter to actually send the redirect.

I assume this is what OP is suggesting, and it would be nice if a way could be had that made it so that domain didn't have to be whitelisted to redirect. However I don't really see it being a big deal, you can just whitelist the domain but not allow anything like JS, XHR, Other, Media, CSS, Cookies, etc. By default for that domain group.

[nihil-admirari]

Suggestion to rewrite Google's script was left unanswered. x-frame-headers handling got its own issue: https://github.com/SimonBrazell/privacy-redirect/issues/235.