Context of inline image requests in extension page (e.g., a popup)?

Add-ons Development
#1

In one extension (Switch to Previous Active Tab), I’m displaying a popup with site icons for recently accessed tabs (tab.favIconUrl).

I was surprised to see in the Browser Console that requests are being sent to sites for these icons, rather than what I expected, which was that they could be pulled from the cache (considering that they are already displayed on tabs). I noticed that cookies were sent with some of the requests, so it appears that even though this is a privileged page, there is some interaction with stored site data.

Q: What is the context for these requests? Is it distinct from user session data?

I’d like to respect privacy, but it’s also nice to be able to show site icons. As a precaution for the time being, I decided not to show icons for private window tabs because I don’t want to cross over private session hosts and regular session hosts.

However, I subsequently found other tab listing extensions that don’t bother with this distinction (e.g., Fast Tab Switcher and Saka).

Hence my question: are inline image requests from extension pages isolated in a special context separate from regular session data?

1 Like
#2

I’d like to respect privacy

:+1:

Here is what I think how it works, but I am not entirely sure:

Firefox has several “cookie stores”, exposed to WebExtensions e.g. as cookieStoreId on tabs. I think despite the name, the cookie stores also manage all other persistent data like cache, indexDB, localStorage, etc.
There is one default one, one for every contextual identity and a new one every time you open the Private Browsing mode.
When a WebExtension makes requests (and does not have a host permission for the target), these are handled like they were made by a web page. Since WebExtensions have their own origin, all requests will be cross origin. But the default behavior when requesting images (mostly for legacy compatibility reasons) is to include the cookies of the current cookie store anyway.

Now, to know which cookies will be included, you also need to know what your current cookie store is.
In Firefox, the background page uses the “default” cookie store (in Chrome this works slightly different). Panels and sidebars attached to non-private windows also use the default store.
Container tabs (opened by the user or the extension itself) use the specified cookie store.
Tabs in private windows and panels/sidebars attached to them use the current (non-persistent) private mode cookie store.
One way to observe this is that extension.getViews()and .getBackgroundPage() don’t work across views in different cookie stores.

So bottom line: either generally request images without credentials (e.g. <img src="..." crossorigin="anonymous">) or make sure to only load images referenced from the same cookie store.

1 Like
#3

The simple answer is: no.

To avoid the cookies in the request, I recommend looking into https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes - note that the default behavior just changed for that in nightly (to same-origin)

#4

Okay, I see that. If I open the popup in a regular window, only regular window cookies are sent, and if I open the popup in a private window, only private window cookies are sent.

Trying to send no cookies using CORS (crossorigin=“anonymous”) didn’t work. Testing in Nightly, I don’t get the images, and in the Browser Console I get:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://hostname/favicon.ico. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Which I guess prevents sending of cookies, but also prevents display of site icons.

There also is a different problem: the site icons for private tabs, when retrieved in the popup in the regular window, are stored in the regular disk cache. So, if the goal is not to save any data from the private session in the regular site data, I can’t show those icons.

#5

That is odd. As far as I understood the documentation, the absence of a Access-Control-Allow-Origin header should only prevent you from programmatically reading the image data (e.g. canvas taint), not from displaying them.

There also is a different problem: the site icons for private tabs, when retrieved in the popup in the regular window, are stored in the regular disk cache. So, if the goal is not to save any data from the private session in the regular site data, I can’t show those icons.

When you make the request with e.g. a Pragma: no-cache header, Firefox should not cache the result at all. You would need to do the request manually (e.g. fetch) and display it as a blob:-URL. You need the host permission (e.g. <all_urls>) for this.
And it would also fix the problem above.

1 Like
#6

I will keep this in mind for other projects, thanks.

1 Like