declarativeNetRequest |domain| and the extension's own origin

529 views
Skip to first unread message

wOxxOm

unread,
Aug 6, 2019, 8:44:01 AM8/6/19
to Chromium Extensions
Use case: an extension wants to limit a DNR rule to its own tabs/popups that have chrome-extension://id origin.

declarativeNetRequest accepts a list of normal web domains for the originator, but not chrome-extension://id, AFAICT.
webRequest allows to implement that use case either by specifying a tabId filter or by checking the request's initiator inside the listener.

wOxxOm

unread,
Aug 6, 2019, 10:08:34 AM8/6/19
to Chromium Extensions
As to why an extension might want to apply DNR to its own requests. For example, to modify a header like Referer to its own XHR/fetch for a particular site's own API in order to imitate a page request without having to open the corresponding site in a separate tab or hidden iframe inside the extension's popup/tab.

Simeon Vincent

unread,
Aug 9, 2019, 8:37:03 PM8/9/19
to Chromium Extensions
I believe you will be able to accomplish this using the extension's service worker. You can register a fetch listener in your SW to intercept and modify requests sent to your extension. You should also be able to treat the SW as a proxy and make a no-cors request to another domain. Note that when using no-cors requests the response will be opaque to your extension.

Simeon - @dotproto
Extensions Developer Advocate

wOxxOm

unread,
Aug 10, 2019, 12:22:36 AM8/10/19
to Chromium Extensions
Sounds interesting. And plausible. But so far I haven't seen any demo extension on https://cs.chromium.org/ that uses the upcoming extension SW in this fashion. If I overlooked one it'd be nice if someone points to it, otherwise I'm somewhat afraid the SW is only there as an implementation means for the background script, not a full-fledged SW for the extension itself, capable of processing extension's own requests.

wOxxOm

unread,
Aug 10, 2019, 1:51:27 AM8/10/19
to Chromium Extensions
Also, how would this SW intercept its own requests to the outside web made from the background script which is the SW proper? That would require registering a separate SW script for the extension origin, which I'm not sure will be possible in MV3. There's some basic support added in crbug.com/545535 but I also see crrev.com/c/1602440 introduces some kind of limit, not sure if it's applicable here though.

PhistucK

unread,
Aug 10, 2019, 7:56:04 AM8/10/19
to wOxxOm, Chromium Extensions
Using fetch(url, {referrer: "http://foo.baz/bak"}), you can actually directly control the referrer (not possible in XMLHttpRequest, as far as I know).
I am not sure extensions can change the referrer value to whatever they like (other domains), but that could be the missing feature here, rather than intercepting (which would not be possible, like you noted, from a service-worker-background-script, I imagine, if it is the script that initiates the fetch()) just for changing the referrer value.

☆PhistucK


--
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/0f3ee9b8-bc2d-4ec8-9b94-07bb31d90e22%40chromium.org.

wOxxOm

unread,
Aug 10, 2019, 8:34:48 AM8/10/19
to Chromium Extensions, wox...@gmail.com
Sounds like a winner, but according to a quick test I just performed, Chrome extensions don't send the referrer header regardless of referrerPolicy, referrer, mode and other parameters of fetch, and apparently never did as I see the same problem being "solved" by webRequest workaround I've mentioned above. The spec for fetch seems to allow setting an arbitrary referrer URL so I'm not sure why Chrome doesn't do it for extensions (but being aware of all those other stalled bug reports in the extensions API I'm not really surprised).
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

PhistucK

unread,
Aug 10, 2019, 8:49:22 AM8/10/19
to wOxxOm, Chromium Extensions
Maybe file a feature request, then, despite your distrust...

☆PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

--
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/a07a34b2-2a88-460c-a8f3-1b41460d8d82%40chromium.org.

wOxxOm

unread,
Aug 10, 2019, 9:45:31 AM8/10/19
to Chromium Extensions, wox...@gmail.com
I've run a bisect script and found crbug.com/694430 based on discussion in https://github.com/whatwg/fetch/issues/245 which was resolved to silently ignore cross-origin referrers on a fetch request regardless of whether it's performed in an extension or elsewhere. I don't see it being explicitly mentioned in the fetch spec though, but I'm not really proficient at reading them. Anyway, apparently it's intentionally impossible to spoof referrers in fetch() to a cross-origin URL and I don't believe I can convince the Chromium devs to make an exception for extensions so we're back where we've started, I guess.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

PhistucK

unread,
Aug 10, 2019, 11:01:07 AM8/10/19
to wOxxOm, Chromium Extensions
I think it makes total sense to make an exception for extensions, really. If you have those origins in your permissions, there is not reason not to let the extension easily impersonate them.
Just like there is an exception for making CORS-less cross origin requests.

It is your call, but it is better to have the request on file rather than be so pessimistic. Especially now that they are actually working on features and changes, I think it is a good time to raise awareness of things that can help (even more due to functionality loss after the deprecation/removal).

☆PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

--
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.

--
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/3a100edc-112f-4ded-a0b6-ae1e828f1d9d%40chromium.org.

wOxxOm

unread,
Aug 10, 2019, 12:11:50 PM8/10/19
to Chromium Extensions, wox...@gmail.com
Now that there are two of us I'm slightly less pessimistic.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

PhistucK

unread,
Aug 10, 2019, 12:54:40 PM8/10/19
to wOxxOm, Chromium Extensions
One possible problem with this feature is that you may impersonate non-existing domains/sub-domains, or local ones. Not sure if it is a security issue or a feature...

☆PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

--
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.

--
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.

--
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/7edb6bdc-4020-4970-832e-59961270e1f4%40chromium.org.

Simeon Vincent

unread,
Aug 11, 2019, 12:56:17 AM8/11/19
to Chromium Extensions, wox...@gmail.com
But so far I haven't seen any demo extension on https://cs.chromium.org/ that uses the upcoming extension SW in this fashion.

Yeah, I haven't built any demo extensions yet in large part because ATM the only way to get SW access is to run a custom build of Chromium and the fact that I've had my hands full with other stuff. But I do intend to create a demo for this use case.

The description I provided was based on a conversation with the engineer that's been working on the SW implementation. As such, it's currently theoretical, but if it doesn't work I'd consider it a bug. 


Anyway, apparently it's intentionally impossible to spoof referrers in fetch() to a cross-origin URL and I don't believe I can convince the Chromium devs to make an exception for extensions so we're back where we've started, I guess

Worthy of a feature request, IMO. I also starred it :)


Simeon - @dotproto
Extensions Developer Advocate

On Saturday, August 10, 2019 at 9:54:40 AM UTC-7, PhistucK wrote:
One possible problem with this feature is that you may impersonate non-existing domains/sub-domains, or local ones. Not sure if it is a security issue or a feature...

☆PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

Alec Larson

unread,
May 9, 2023, 5:57:37 PM5/9/23
to Chromium Extensions, Simeon Vincent, wox...@gmail.com
Over 3 years later, does anyone know if it's still not possible to specify the extension's own origin as a DNR initiator domain?

Alec Larson

unread,
May 9, 2023, 6:02:47 PM5/9/23
to Chromium Extensions, Alec Larson, Simeon Vincent, wox...@gmail.com
Just tried with `chrome://newtab/` and it works! Sorry for the spam.
Reply all
Reply to author
Forward
0 new messages