Open Bug 1667348 Opened 7 months ago Updated 3 months ago

Blob isolation regresses sandboxed iframe downloads

Categories

(Core :: Privacy: Anti-Tracking, defect, P2)

defect

Tracking

()

Webcompat Priority P1
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- disabled
firefox82 --- disabled
firefox83 --- disabled
firefox84 --- disabled
firefox85 --- disabled
firefox86 --- disabled

People

(Reporter: jryans, Unassigned, NeedInfo)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Attached file Reduced Test Case

In Element, we currently use a sandboxed iframe to assist with downloads of encrypted files, which works well in release versions of Firefox and Chrome.

However, the blob isolation work (bug 1658878) in Nightly prevents this from functioning by treating the blob sent to the sandboxed iframe as invalid.

STR:

  1. Open the reduced test case attached to this bug
  2. Click the "Trigger Download" button

ER:

A file should be downloaded with content "Hello". (This does indeed happen in all Chrome channels and Firefox release channel.)

AR:

Nothing is downloaded and no error is logged.

Set release status flags based on info from the regressing bug 1658878

privacy.partition.bloburl_per_agent_cluster is nightly only.

Blocks: 1590107
Severity: -- → S3
Priority: -- → P2
Webcompat Priority: --- → P1

Is this the only blob URL partitioning bug we have left?

I don't really understand why this would fail as the blob URL is created in its own agent cluster that then also navigates to that URL. In principle it ought to be in scope.

If we address this, should we work on shipping blob URL partitioning to release, perhaps after we ship network state partitioning?

Flags: needinfo?(tihuang)

(In reply to Anne (:annevk) from comment #3)
Sorry for the late response, it took me some time to understand the problem here.

Is this the only blob URL partitioning bug we have left?

Yes, I think this is the only bug for blob URL partitioning.

I don't really understand why this would fail as the blob URL is created in its own agent cluster that then also navigates to that URL. In principle it ought to be in scope.

It turns out the agent cluster ids are different between the page and the sandboxed iframe. So, the blob URL cannot be retrieved.

If we address this, should we work on shipping blob URL partitioning to release, perhaps after we ship network state partitioning?

It looks reasonable to me that shipping this to release once we got this fixed. But I would like to see Arthur's opinion here.

Flags: needinfo?(tihuang) → needinfo?(arthur)

Verification/testing of bug 1684183 ran into this issue as well. It's confusing also because there is no error message or anything else (even in the browser console).

Blocks: 1686111

Tim, when you say that the agent cluster IDs are different between the page and the sandboxed iframe, what page do you mean? The page that embeds the iframe? But it's the iframe that is being navigated (resulting in a download), right?

I do think we might need wider lookup of blob URLs for the purposes of top-level navigation. E.g., if a document generates a blob URL and the user navigates to that in a new tab.

(In reply to Anne (:annevk) from comment #6)

Tim, when you say that the agent cluster IDs are different between the page and the sandboxed iframe, what page do you mean? The page that embeds the iframe? But it's the iframe that is being navigated (resulting in a download), right?

Actually, I am not entirely sure if it is the page that embeds the iframe given that I am not familiar with how downloading works. And I've got your point that the download could happen in a new tab after clicking a blob URL in iframes. So, It could be the case that the agent cluster ID of the downloading tab is different from the page which embeds the sandboxed iframe.

I do think we might need wider lookup of blob URLs for the purposes of top-level navigation. E.g., if a document generates a blob URL and the user navigates to that in a new tab.

IIUC, The agent cluster should be the same if the newly opened tab has an opener relationship with the window that generates a blob URL. So, the blob URL should be able to be resolved in this case. But. It doesn't apply here for a downloading tab because it has a different agent cluster ID. So, Does it suppose to be a different agent cluster ID or not?

Something as simple as target=_blank without rel=opener would result in a new tab that does not share an agent cluster with the tab containing that link. This is also what would happen if the user copy-and-pasted the URL and navigated to it in a new tab, download or not. I think to support those cases we would still need an effectively global registry of blob URLs, but only top-level navigations should be able to look at the global registry unscoped. Everything else should have its lookup scoped by the agent cluster, if that makes sense.

See Also: → 1692016
You need to log in before you can comment on or make changes to this bug.