1667348 - Blob isolation regresses sandboxed iframe downloads

Status: RESOLVED FIXED

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

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Julien Cristau [:jcristau]]

privacy.partition.bloburl_per_agent_cluster is nightly only.

Comment 3

[Anne (:annevk)]

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?

Comment 4

[Tim Huang[:timhuang]]

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

Comment 5

[:Gijs (out for now; he/him)]

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

Comment 6

[Anne (:annevk)]

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.

Comment 7

[Tim Huang[:timhuang]]

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

Comment 8

[Anne (:annevk)]

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.

Comment 9

[Karl Dubost💡 :karlcow]

Setting to P3 because Bug 1728192 has disabled the feature.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:timhuang, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Comment 11

[Tim Huang[:timhuang]]

We are looking for a new isolation approach for blob URLs.

Comment 12

[Abhishek Madan[:abhishekmadan]]

This issues was caused by the pref : privacy.partition.bloburl_per_agent_cluster. This pref is now disabled by default and current implementation of blob url partitioning using the pref : privacy.partition.bloburl_per_partition_key has been tested and has been shown to not cause breakages with sandbox iframes.

Comment 13

[Tom Ritter [:tjr]]

There is no pref bloburl_per_partition_key.... If we never intend to enable bloburl_per_agent_cluster we should let :gregp know and he'll remove it

Comment 14

[Tim Huang[:timhuang]]

The pref bloburl_per_partition_key will be added in Bug1843152 and Bug 1843155. We will never enable bloburl_per_agent_cluster because of the breakage. Instead, we are looking for enabling bloburl_per_partition_key.

:gregp, ni you for this information.

Comment 15

[Gregory Pappas [:gregp]]

Hi, please file a bug for the pref removal which blocks bug 1773039.

A few questions

• Since this is a security/privacy sensitive pref, do we want to add a migration that moves bloburl_per_agent_cluster users to bloburl_per_partition_key? Or would the # of users be too low to make that worth it?
• Do we want to wait for bug 1843152 to land in Nightly before removing bloburl_per_agent_cluster?

Comment 16

[Tim Huang[:timhuang]]

Hi Gregory,

• We never enabled the pref bloburl_per_agent_cluster even in the Nightly channel. Given this, I would expect that not many users enable this pref. So, I don't think it is worth migrating.
• We won't remove the pref bloburl_per_agent_cluster before landing bug 1843152.