Blocking Youtube with DeclarativeWebRequest

[T S]

Is there something like a youtube-specific caveat when it comes to blocking with DeclarativeWebRequest?

If I establish a dynamic ruleset with basic patterns, almost all websites work as expected. However, when it comes to Youtube, (https://www.youtube.com), I haven't ever managed to block it regardless of pattern.  

You'd expect a pattern of *youtube* to be pretty foolproof, but no luck.  I thought it might be related to loading via quic, but other quic sites (cloudflare-quic.com) can be blocked just fine.

If it makes a difference, I'm testing this against a ChromeOS device.

This is definitely part of the functionality I'm hoping to provide, so I'd appreciate it if anyone has any light to shed here.

[Patrick Kettner]

There is nothing youtube specific. Can you share the code you are using?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/70a20f92-25da-4b32-ae61-7618982b047dn%40chromium.org.

[T S]

I looked around for other sites that can't be blocked.  Gmail is blockable with *mail.google*, but chrome.google.com is not blocked by *chrome.google*.  That feels like it would point to a chromeos specific detail.

Including code verbatim is going to be a bit obtuse, but ultimately this is a call like

chrome.declarativeNetRequest.updateDynamicRules({
addRules:[
{
id: someGetNextIdFunction(),
priority:1,
action: { type: "block" },
condition: { resourceTypes: [ "main_frame" ] },
          urlFilter: <pattern>
        }
]
});

(In addition to making sure there are no unwanted rules lying around either)

Maybe there's some interaction with main_frame going on?

[T S]

uh. typo.  urlFilter is part of the condition object as expected.

[wOxxOm]

YouTube is a SPA (single-page application) site, which means the same DOM page is used when the user navigates the site while the URL is faked via history API in JS, i.e. there's no network request for declarativeWebRequest to see. To block such fake navigations you'll have to use a content script and navigate event's interception or patch window.history methods in the MAIN world.

Re "chrome.google.com", the site is redirected to https://www.google.com/chrome/, which is probably why it's not blocked. Anyway, sounds like a bug to me.