1626226 - Investigate if we can get the hasStoragePermission for the unopened channel in WorkerLoadInfo::GetPrincipalsAndLoadGroupFromChannel() for workers

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, task, P1)

Description

[Tim Huang[:timhuang] [PTO 10/23 ~ 10/28]]

We will need the hasStoragePermission flag to do ContentBlocking checks for channels in ETP Fission. This flag would first be calculated in the parent process when opening the channel. However, there are cases that we do the check before the channel has been opened.

One case here is when we creating a workerLoadInfo, it will create a channel and get the channel result principals right after this channel is created[1]. At that moment, the channel hasn't been opened yet. So, we wouldn't have a hasStoragePermission set here.

This bug is for investigating that if we have a way to address this.

Comment 1

[Tim Huang[:timhuang] [PTO 10/23 ~ 10/28]]

For dedicated workers and shared workers, we can directly copy the hasStoragePermission from the window who registers the worker because they would only be registered in the same-origin context. So, the hasStoragePermission flag should be consistent between the worker and the window.

For service workers, it's also registered in the same-origin context, so we can use the flag from the window too. But the worker would be initialized before the next loading of the page. In this case, we wouldn't have a window to reference the flag. Baku gave two potential solutions.

• First, we might be able to carry the flag with the service-worker script. So, we would know the flag for the next loading. But, what if the permission has been changed before the loading?
• Second, we can retrieve the flag asynchronously when the script is executed.

Comment 2

[Tim Huang[:timhuang] [PTO 10/23 ~ 10/28]]

Per offline discussion with Baku, we don't need to care about the storage permission for service workers since we do not allow the service worker for third party trackers when the cookieBehavior >= 4. This means we never check storage permission in this case. Thus, the hasStoragePermission flag is irrelevant here.

So, we only need to care about dedicated workers and shared workers. For both cases, we can get the hasStoragePermssion from the document of the window which constructs the workers.

Comment 3

[Tim Huang[:timhuang] [PTO 10/23 ~ 10/28]]

Attachment: Bug 1626226 - Copy the hasStoragePermssion flag from the document for workers when creating under a window for dedicated and shared workers. r?dimi,baku!,asuth!

When creating workers, dedicated workers, shared workers, we will set
the storage prinicpal to the worker load info. During getting the storage
principal, we need to check the storage permission in the content process.
However, we don't have the hasStroagePermission flag which is needed to do
the check since the channel that we use to get the principal is not opened
yet at the moment.

To address this issue, we can copy the hasStoragePermission flag from
the doucment of the window which creates the worker. Because the worker
would be the same-origin as the window. So, the hasStoragePermission
flag is supposed to be the same between the window and the worker.

We don't need to do anything for the service worker since the storage
permission won't be checked due to the service worker is disabled for
third party trackers. And the storage permission is for the third party
trackers. Thus, we can ignore this flag for service workers.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/581d46a5e138
Copy the hasStoragePermssion flag from the document for workers when creating under a window for dedicated and shared workers. r=dimi,baku,asuth

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/581d46a5e138