WebRequest Block APIs not blocking GMAIL when user is LOGGED IN

[Vishal Jaiswal]

Hi Chromium Team,

We are Trellix Endpoint Security, one of our product is Web Control which identifies the malicious sites and custom based block sites through the native messaging host attached to our extension. This extension makes sure that we are blocking the sites listed in block list (a custom list that is present in native messaging host) and showing user a custom block page whenever the extension blocks a site.

With this any site that user or admin wants to block, they can add it in in the config that native messaging host reads and passes block calls to extension.

With the above set up we are able to block any custom based site except mail.google.com which is behaving differently depending upon whether the user is
logged in or logged out.

We have set the mail.google.com in the block list that means whenever user tries to access mail.google.com then it should not open and show a custom block page that we have configured.

But what we are seeing is when the user is logged out then we are able to block mail.google.com but when the user is logged in then it is not getting blocked.

We are using chrome provided APIs to send the block request, and also whatever URL the end user types in browser that also we read though chrome.runtime. APIs.

We need help on why only mail.google.com is behaving differently depending on whether user is logged in or logged out because rest all the sites are working as expected, irrespective of whether the user is logged in or logged out.


Thanks

[Patrick Kettner]

Hi Vishal!

Can you have them check if they have a chrome policy installed?

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/08e328cf-d830-4cc2-81d5-84c30081a141n%40chromium.org.

[Vishal Jaiswal]

Hi Patrick!

Thanks for the quick response.

We have 2 chrome extension policies installed in the environment, one is ExtensionInstallForcelist that we use to force the extension installation, and other is Extension Setting policy where we allow the use of file URL's to load our custom block pages.

Let me know if this helps or you need any other detail.

Thanks and Regards
Vishal

[Vishal Vats]

Using a MutationObserver could solve your issue; you can try that. Because the page URL might be changing very fast before your content script could even load. For not logged-in users, they would visit that static page, and thus the content/bdg script might get the chance to do the processing and block the page. 

By the way, any specific reason that you tagged so many people in this post, apart from just the chrome-extensions group, which is the default one?

[Patrick Kettner]

The actual policy would be useful. You can restrict access to certain APIs and certain domains using it, and the behavior I see when that is done lines up with the information you shared.

--

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 visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/9729999b-70a8-4087-b334-55df7330be8an%40chromium.org.

[Vishal Jaiswal]

Hi Vishal Vats,

I don't think that mutation observer will help here as we are getting the correct navigation event through the chrome extension APIs.

And those APIs are written in background script so it doesn't matter whether content script is loaded till then as we are getting the
appropriate navigation event through background js.

[Vishal Jaiswal]

Hi Patrick,

I'm adding the policy json that I exported from chrome's policy page.
Although I don't see any restriction there on any API or domain but you can have a look for confirmation in case I missed out any.

Let me know if you need any other details for investigation.

Thanks for your active engagement in this issue.

[kg_17]

It could be because of a web service worker.  Search for 'mail.google.com' in the chrome://serviceworker-internals/ page after logging into gmail.  Here's the relevant bug:  https://issues.chromium.org/issues/40747297 (declarativeNetRequest rule not applied to some sites).  This bug also applies to webRequest.onBeforeRequest.

[Vishal Jaiswal]

Hi Kgersen, Good Day!

I have checked the chromium bug that you suggested but this seems to be a different issue and not relevant to what I'm facing.

The above chromium bug talks about the disable of the chrome extension and re-enable is not blocking certain sites, but in my case when logged in to mail then only gmail is not getting blocked otherwise it's working fine and not related to extension being disabled and re-enabled.

Thanks
Vishal 

[kg_17]

I'm pretty sure the problem is the service worker.  Did you test unregistering it?  I can log into a gmail account, unregister the mail.google.com service worker (chrome://serviceworker-internals/), and then successfully block a new tab from loading a gmail account using webRequest.onBeforeRequest (or declarativeNetRequest).  If the service worker is registered though, the gmail account won't get blocked from loading.

It's not just gmail that exhibits this behavior.  For example, load https://developer.chrome.com/ once and a service worker will get registered.  Next, attempt to block a main_frame request to that site it won't be successful.  The page will load.

You can also remove a service worker through the browsingData api:

chrome.browsingData.remove({"origins": ["https://mail.google.com"]}, {"serviceWorkers": true}, () => {});

[Vishal Jaiswal]

Hi Kgersen, Good Day!

I believe whatever you said is correct because I also saw similar behavior. While I did not unregister service worker or deleted data through APIs. But on clearing the browser cache manually I saw that the gmail.com got blocked even in the presence of logged in users, but after sometime, again on reloading the gmail.com it was not getting blocked so I believe the service worker might have re-registered.

Thanks a lot for pointing it out as this definitely sums up the issue and the behavior of chromium towards gmail.com.

Regards
Vishal