TF1.fr

[smed79]

Hi,

Versions

uBlock Origin 1.12.5.17 / Chromium 58.0.3029.110 (64-bit) uBlock Origin 1.12.5rc1 / Firefox 53.0.3 (64 bits)

Settings

Default settings + Liste FR

URL(s) where the issue occurs

https://www.tf1.fr/tf1/the-voice/videos/audrey-plus-belle-aller-danser-sylvie-vartan-direct-saison-6.html

Describe the issue

Video ads or anti adblock.

Screenshots

http://i.imgur.com/TygrTGs.png http://i.imgur.com/rXoV7yk.png

Suggested filters

||foilpolyth.com^$xmlhttprequest,important,redirect=nooptext,domain=tf1.fr
||louccrossc.com^$xmlhttprequest,important,redirect=nooptext,domain=tf1.fr

Screenshots

http://i.imgur.com/1VMCrj9.png http://i.imgur.com/GEo2BSq.png

Filters for AdBlock / Adblock Plus

• https://forums.lanik.us/viewtopic.php?p=119149#p119149

Source

https://github.com/jspenguin2017/uBlockProtector/issues/187

@SohKa @maxxyme @jspenguin2017 Fyi...

[okiehsch]

This will prevent video playback , if I use Firefox. I can watch the video with default settings. If I add Liste FR, I get the anti adblock message. xmlhttprequest-redirects do not work with Firefox on my end, therefore I can now no longer watch videos on tf1.fr with default settings, unless I override this fix. Other example of xmlhttprequest-redirects not working with Firefox: https://forums.lanik.us/viewtopic.php?f=62&t=37009 Tested with Firefox 53.0.3 and uBO 1.12.4/1.12.5rc1.

[jspenguin2017]

@okiehsch It is either a bug in FireFox or uBO, the redirect didn't work out and ends up being blocked instead. It looks like it tripped on the Content Security Policy.

Don't get me wrong, I'm not defending SMed79, I know he has a reputation of committing untested code, but in this case it really looks like his rule isn't the problem.

[okiehsch]

I'm not defending him, I know he has a reputation of committing untested code

I was not accusing anybody of committing untested code, @SMed79 proposed a fix, he did nothing "wrong" as far as I am concerned. I actually made the same "mistake" with xmlhttprequest-redirects once https://github.com/uBlockOrigin/uAssets/issues/242#issuecomment-269247585

[jspenguin2017]

@okiehsch OK, I see what's going on, uBlock Origin listens requests that are going out, and tells the browser to redirect to a data: scheme. Chrome will happily accept that, but FireFox does not. I didn't look deeper into the WebExtension API, I assume it's an issue with FireFox.

[jspenguin2017]

@okiehsch OK, now I (think I) fully understand the root cause: FireFox complains that: CORS header ‘Access-Control-Allow-Origin’ does not match ‘(null)’ Strictly speaking, that is the "correct" behavior and it's Chrome that is not following the standard:

two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port.

data: scheme and http(s): are obviously different. In the data: scheme standard, it says:

Interpretation of the data within a "data" URL has the same security considerations as any implementation of the given media type.

Which means a XHR of data: scheme should be treated as a http(s): XHR, which in turn means the Access-Control-Allow-Origin header must be set. Later in the first standard document, it says:

NOTE: A URI is not necessarily same-origin with itself. For example, a data URI [RFC2397] is not same-origin with itself because data URIs do not use a server-based naming authority and therefore have globally unique identifiers as origins.

Which reinforce that data: shall be treated as a different origin. The problem is that setting header for data: scheme is kind of hard.

It looks like FireFox is strictly following the standard and Chrome is a bit more sloppy with data: scheme. I didn't read over the full standard document, but this can be a tricky problem to solve unless I missed something...

[gorhill]

I'm pretty sure Chromium used to suffer the same issue, now fixed -- redirect to data: URI by an extension should not be blocked, an extension act on behalf of the user who installed it.

[jspenguin2017]

@gorhill So eh... Open an issue in Bugzilla? I did a quick search and no one seems to have open an issue about it yet...

[gorhill]

Guess I am wrong that Chromium used to suffer the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=527326.

But I really do think that extensions should be treated differently, they are extensions to a user agent, and hence act on behalf of the user.

[jspenguin2017]

@gorhill Chrome explicitly says redirecting to data: is allowed:

Redirections to non-HTTP schemes such as data: are allowed. [...] Redirects from URLs with ws:// and wss:// schemes are ignored.

But Mozilla didn't say anything about data: scheme.

to redirect the request, include a property redirectUrl with the value set to the URL to which you want to redirect.

[jspenguin2017]

@gorhill Do you think onHeadersReceived event would help resolving the problem? https://gitlab.com/xuhaiyang1234/AAK-Cont/issues/38#note_31780973

[gorhill]

Not something I would do, I don't want to relax existing CSP or in the same vein a header like Access-Control-Allow-Origin.

[jspenguin2017]

@gorhill Yea... true... What about patching XMLHttpRequest property? It's probably doable, but could be a bit complex and slow...

[Giwayume]

@gorhill You don't need to do it everywhere, only when you're injecting a data url. In which case CSP doesn't apply anyways.