gorhill / httpswitchboard

Point & click to forbid/allow any class of requests made by your browser. Use it to block scripts, iframes, ads, facebook, etc.
GNU General Public License v3.0
1.33k stars 84 forks source link

chromium-behind-the-scene issues #154

Closed requiredregistration closed 10 years ago

requiredregistration commented 10 years ago

after the reload caused by the scope creation, the swf file which is the video player/playback control applet for the flash player is still being blocked even though the youtube.com, ytimg.com, google.com domains and their subdomains have been allowed (the swf file is downloaded from the s.ytimg.com subdomain).

now, by accessing the matrix for behind-the-scene requests and allowing youtube.com, google.com, ytimg.com, and reloading the youtube tab. the swf file will be downloaded, the video file will start being downloaded, and then playback will start.

[reformatted by @gorhill for clarity]

gorhill commented 10 years ago

I try the above steps, and I didn't need to go into the http://chromium-behind-the-scene scope. A recipe for Youtube with which video can play:

https%3A%2F%2Fwww.youtube.com%0A%09white
list%0A%09%09*%20apis.google.com%0A%09%0
9*%20googlevideo.com%0A%09%09*%20ytimg.c
om%0A%09%09*%20youtube.com%0A%09%09image
%20*%0A%09%09stylesheet%20*%0A%09blackli
st%0A%09%09*%20*%0A

now, by accessing the matrix for behind-the-scene requests and allowing youtube.com, google.com, ytimg.com

I can't make sense of this. Are you saying all the requests for the Youtube page ended up being reported in the http://chromium-behind-the-scene matrix? What is your browser? Version? OS?

gorhill commented 10 years ago

Is it possible you have an extension which downloads or otherwise intercepts the Youtube video? Net requests from extensions will be reported in the http://chromium-behind-the-scene scope.

requiredregistration commented 10 years ago

i checked your recipe before i click new issue.

yes, that's what i'm saying. the domains had to be allowed there too.

chromium 34.0.1788.0 (244965) windows xp service pack 3

requiredregistration commented 10 years ago

no, i don't have an extension of that kind.

gorhill commented 10 years ago

You think this could be related: https://code.google.com/p/chromium/issues/detail?id=332481 ?

Excerpt:

Youtube and adblock plus does not work anymore. Just blackscreen and audio

requiredregistration commented 10 years ago

yes. it's your extension, that, or both.

gorhill commented 10 years ago

it's your extension, that, or both.

I see...

Ok so I will flesh out what is going on technically here. If any one else can help investigate, that would be great, because I just can't reproduce what is reported here.

For every call to onBeforeRequest by Chromium engine, the details.tabId value will be set to the tab id from where the request originate. When tab id is -1, this means the request originate from no particular tab. These are identified as Chromium-behind-the-scene requests by HTTPSB.

Requests which originate from tabs should normally never be reported as being out of tab. So far from what I have observed since the beginning of this project is that it may happen exceptionally, but not normally. So that the fact that it happens here seemingly for all requests on the Youtube page is absolutely abnormal, that is, unless something changed in the beta (or is it dev?) version of chromium (v34 as I can see above).

Since for now I will stick to test and debug stable version of chromium, this bug will have to wait for someone to come with some help or constructive information in assisting investigate it.

requiredregistration commented 10 years ago

ok, i did some more testing with the latest stable google chrome 32.0.1700.76.

it is both, your extension and the NPAPI (Netscape Plugin Application Programming Interface) implementation (and/or the flash player plug-in) in chromium and chromium-based web browsers.

gorhill commented 10 years ago

Edit...

ok, i did some more testing with the latest stable google chrome 32.0.1700.76

And? It worked? (at first I read it as "not working either", now unsure re-reading it)

requiredregistration commented 10 years ago

first of all, make sure that the flash player for PPAPI (Pepper Plugin API) is disabled (it is the flash player plug-in bundled with chrome), and enable the one for NPAPI. if you see only the PPAPI one, you have to download the flash player for NPAPI from adobe's website. my guess is that you have it already.

to disable the PPAPI one and to enable the NPAPI one, go to chrome://plugins/, click details, disable the flash player for PPAPI and enable the one for NPAPI.

test with this, http://www.dailymotion.com/video/x17xiu6_how-to-be-quiet-around-a-bison_animals

go to the behind-the-scene matrix and you'll see.

ps: a lot of papi :P

edit: the flash player plug-in for PPAPI is not bundled with chromium. chromium uses the NPAPI one if it is found installed.

my-password-is-password commented 10 years ago

httpsb

Clean install of Chromium Version 34.0.1789.0 with only HTTPSB installed. I didn't have to go to http://chromium-behind-the-scene to allow anything for the video to start playing for me.

gorhill commented 10 years ago

Ok, I could reproduce it using the above steps by @requiredregistration.

So essentially a change in the browser is breaking extensions which rely on the fact that plug-ins net traffic was reported as web page net traffic, while now it is reported as behind-the-scene net traffic in newer iterations of chromium (as per http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html).

This breaks Adblock Plus (https://code.google.com/p/chromium/issues/detail?id=332481), which ignores (unlike HTTPSB) behind-the-scene requests. But this also breaks HTTPSB because it makes no sense for a user to have to create rules in the behind-the-scene scope in order for a web page to work properly.

Now I will investigate if and how this could be worked around. If ever there is no workaround, users will have to use rules in the behind-the-scene scope as a workaround, which sucks really.

gorhill commented 10 years ago

I didn't have to go to http://chromium-behind-the-scene to allow anything for the video to start playing for me.

@my-password-is-password: Is it possible this was HTML5 video? The problem reported here wouldn't affect HTML5 video/audio (my understanding).

From the GIF you posted, I infer this was the video your were playing: http://www.youtube.com/watch?v=Klk40_AwvPA? If so, this one is HTML5 (you can quickly confirm with right-click on the video).

my-password-is-password commented 10 years ago

The youtube video I watch was HTML5. My bad.

gorhill commented 10 years ago

@my-password-is-password : Just curious, how did you make the animated GIF? I am trying to find tricks for creating that kind of animation as easy and fast as possible. The video of HTTPSB I created was really tedious to create.

my-password-is-password commented 10 years ago

Its called GifCam. Its free and you can download at http://blog.bahraniapps.com/?page_id=21

The download link , http://www.bahraniapps.com/apps/gifcam/gifcam.php, is below Version 3.1 which is the latest.

gorhill commented 10 years ago

Well I looked at the net traffic to see if a workaround is possible, and I fear it is not. Details of a typical request linked to the plugin object when onBeforeRequest is called:

details: Object
    frameId: -1
    method: "GET"
    parentFrameId: -1
    requestId: "2521"
    tabId: -1
    timeStamp: 1389893540579.161
    type: "object"
    url: "http://static1.dmcdn.net/flash/dmplayerv4/dmplayer-prod-compressed.swf.v958ed97f10a4ef759"

I had hoped to investigate the use of parentFrameId to infer the tab from which the request originate, but this one field is also neutered. This essentially means a workaround is becoming more difficult, if possible at all.

The only thing left which might be usable is the URL of the request -- the "path" part: if this can be matched to the DOM in one of the tab, then there might be a way to guess the tab from which the request originates.

Looking up something in the DOM of all opened web pages is not something which can be done when onBeforeRequest is called. There would need a prebuild map of plugin-related URLs to tab ids, which can be quickly looked-up at onBeforeRequest time. Hackugly..

gorhill commented 10 years ago

The issue has been marked "fixed" by Chromium people: https://code.google.com/p/chromium/issues/detail?id=332481. I will close this bug anyway, as it is a confirmed Chromium issue, not an issue with this extension.