Open Bug 1698863 Opened 3 years ago Updated 2 years ago

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

Categories

(WebExtensions :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: robwu, Unassigned)

References

(Blocks 1 open bug)

Details

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:

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.

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

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

Severity: -- → S3
Priority: -- → P3
Severity: S3 → N/A
See Also: → 1687569
See Also: → 1710251
See Also: → 1705134
You need to log in before you can comment on or make changes to this bug.