1698863 - Allow extensions to specify request context in the browser.downloads.download API

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Rob Wu [:robwu]]

We have repeatedly seen new (privacy) features being added to Firefox that somehow break extensions that make requests. For the browser.downloads.download API, we have a couple of reports:

• (network) cache partitioning - bug 1689752 / bug 1691907 / bug 1687569
• HTTPS-only mode - bug 1685862
• downloads in container tabs - bug 1669566
• other kinds of isolation, see https://bugzilla.mozilla.org/show_bug.cgi?id=1670278#c2

It is possible to support these by exposing new properties to extensions. However, the disadvantage of that is that extensions need to repeatedly be updated, and if the partitioning logic (e.g. choice of partitionKey) ever changes, then extensions that are trying to mimic the "native" behavior can fail to do so.

So instead of this, I am proposing that we introduce an API to automatically infer the right origin attributes, principals and settings from the frame. I.e. allow extensions to make (download) requests on behalf of a specific frame.

Here is an example of an API design for the above idea. See https://bugzilla.mozilla.org/show_bug.cgi?id=1691907#c14 for more context (also in the surrounding discussion):

browser.downloads.download({
  url: ...,
  requestInitiator: { // <-- new name. Maybe requestContext?
    tabId: ...,
    frameId: ...,
  },
});

There are some caveats in the above API design, but they can be resolved:

• The tabId / frameId (nor most of the inferred request context) cannot be exposed through the download API when the download is queried (e.g. via browser.downloads.search). Extensions cannot read properties off the download item to create an identical download. This can be resolved in the future, e.g. by introducing a new downloadId property (instead of tabId+frameId).
• The frame could have been navigated at the time of the invocation of downloads.download. If this is a concern, we could require extensions to specify the URL and/or origin of the frame's document.
• The downloads.download API supports properties to set part of the context (e.g. incognito). The specified flag may conflict with the origin attributes inferred from the given frame. (this could be resolved, e.g. by rejecting the call).

This bug is a good introduction to explore the necessities to resolve the more general issue of requests "on behalf of frames" at bug 1670278. The API design here should ideally be generally applicable to other methods from that other bug.

Comment 1

[Masatoshi Kimura [:emk]]

How Chrome resolves this issue? They don't add privacy features so frequent?

Comment 2

[Rob Wu [:robwu]]

(In reply to Masatoshi Kimura [:emk] from comment #1)

How Chrome resolves this issue? They don't add privacy features so frequent?

They haven't resolved the issue. https://crbug.com/1169987 ("Issue 1169987: cache partitioning causes web page saving extensions to waste more time and data") is like bug 1687569.

Comment 3

[Rob Wu [:robwu]]

Bug 1919153 tracks the implementation of cookies.getPartitionKey, which would enable extensions to describe the storage partition to use for cookies.

That would not fully solve the issue - to decide which cookies to send, it is also relevant to know whether a request is first-party or third-party (for SameSite cookies). In a different context (tabs.create - https://github.com/w3c/webextensions/issues/663), I sketched an initiator property to enable extensions to specify the initiator URL. This together with a partitionKey property could enable extensions to cover most current cases.