I believe that the issue can be resolved by adding to this line here: https://github.com/chromium/chromium/blob/d30286c2a870ae693860e3258ce50dd9ac93c03c/extensions/browser/api/web_request/web_request_api.cc#L780

By changing:
URLPattern pattern(URLPattern::SCHEME_HTTP | URLPattern::SCHEME_HTTPS |
                           URLPattern::SCHEME_FTP | URLPattern::SCHEME_FILE |
                           URLPattern::SCHEME_EXTENSION |
                           URLPattern::SCHEME_WS | URLPattern::SCHEME_WSS);

to:
URLPattern pattern(URLPattern::SCHEME_HTTP | URLPattern::SCHEME_HTTPS |
                           URLPattern::SCHEME_FTP | URLPattern::SCHEME_FILE |
                           URLPattern::SCHEME_EXTENSION |
                           URLPattern::SCHEME_WS | URLPattern::SCHEME_WSS | 
                           URLPattern::SCHEME_BLOB);

It has been a week. What's going on?

Thanks for filing the issue...

@Reporter : It would be really helpful if a sample URL/Extension is provided, so that we can investigate the issue further.

Thanks.!

This is my extension:
https://chrome.google.com/webstore/detail/coin-hive-blocker/ccagdbjcbhmcdcbbknfebhhdbolnfimo

In the test case I have summed up what the extension does (it blocks cryptoJackers with the webrequest API): 

Chrome extension webrequest blocks called by blobs cannot be intercepted,
because chrome extensions does not have the permission to do so.

For example in the https://openloadmovie.org/movies/cars-3-2017/
when trying to intercept blob-requests that initiate WebAssembly workers
that function as CryptoJackers (https://www.investopedia.com/terms/c/cryptojacking.asp).

chrome.webRequest.onBeforeRequest.addListener(
    callback, { 
     urls : [*://openloadmovie.org/********-****-****-****-************] 
 	}, 
     ["blocking"]);


To be even more concise:
If a webpage gets a file dynamically, like this: 

Const myworker = new Worker('https://example.com/myworker.js')

The request for myworker.js is not intercepted in the webRequest API, this is because workers are loaded as blobs. The webRequest API does not intercepted blobs. I hoped that maybe this would be possible in the future.

Best regards
Andreas

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi, just a friendly reminder to take a look at my issue :)

Thanks for the report!

One of the difficulties here is that we need to be able to track the "real" origin (that is, the origin that created it) of the blob - otherwise, accessing blob:* might leak data from sensitive sites.  I don't know if we currently have this information in the browser process - creis@, do you know?

Also +meacer@ and karandeepb@ for their thoughts - any opinions on this from a security and API perspective?  (If we can figure out proper permissioning, I'm supportive)

From what I understood reading about blob urls, they are just a reference to some byte stream and don't lead to an actual network request (Like data urls). So I am not sure how they fit into the web request api.

Regarding c#5,
From what I saw, doing something like
Const myworker = new Worker('https://example.com/myworker.js')
does lead to an actual network request which the extension can intercept. 

However something like 
worker = new Worker(blobUrl)
won't lead to an actual network request and hence won't be intercepted. 

Can you give some more details? I wasn't able to replicate any blob url requests at https://openloadmovie.org/movies/cars-3-2017/.

Comment 8: Blob URLs have origins in them, right?  That would get lost if the page created a data URL which creates a blob URL, though, so it might not be sufficient for tracking.  Maybe Nick's precursor origin work in issue 810563 would help?

 karandeepb@chromium.org , I tried looking into openloadmovie and it looks like they removed their miners. However, I found a new example. If you go to this link: https://hdfull.tv/pelicula/family-is-family and open the first option. If you look into the sources of the page you will see several new threads start running. if you open one of the threads click on (no domain) you will see from what blob link the wasm worker is loaded from. My problem, as stated before is that webRequest does not look into blobs. I am sorry for replying so late, school just started. Btw, I cant open the issue that creis suggested. But I am very open for suggestions on how to do a workaround. Thank you so much for your help :)

Any news?

I don't think we should be exposing blob urls since they don't actually cause network requests (Similarly for data urls). Think this should be closed. Will mark it as available for now, in case some one thinks there is utility in doing this and wants to take it.