Investigate if we can get the hasStoragePermission for the unopened channel in ThirdPartyUtil::AnalyzeChannel()
Categories
(Core :: Privacy: Anti-Tracking, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox77 | --- | fixed |
People
(Reporter: timhuang, Assigned: timhuang)
References
Details
Attachments
(1 file)
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 is in ThirdPartyUtil::AnalyzeChannel().
This bug is for investigating that if we have a way to address this.
|
Assignee | |
Comment 1•5 years ago
|
||
The ThirdPartyUtil::AnalyzeChannel() could be called in both parent and content processes.
There are three places where we call AnalyzeChannel() in the parent process. This first one is CookieServiceParent::TrackCookieLoad(). The TrackCookieLoad() would be called in OnStartRequest(). The channel was opened before we reach OnStartRequest(), so for this case we are good. The second case is nsCookieService::GetCookieStringFromHttp. This would be called when the connection begins, which is supposed to happen after channel opening. For the third case, it's nsCookieService::SetCookieStringFromHttp(). This happens when we get the channel response which is definitely after channel opening. So, we don't need to do anything for the parent.
There are three places for the child process. The first one is CookieServiceChild::TrackCookieLoad(). This would be called during Document::StartDocumentLoad() which happens after channel opening, so we don't need to do anything here. For the second and the third case, CookieServiceChild::GetCookieStringInternal and CookieServiceChild::SetCookieStringInternal, the unopened channel for both function are came from a dummy channel. This dummy channel is created if we don't have a channel in the document and the document use it to check the privacy status in this case. This is the place where we need to find a solution.
|
|
Assignee | |
Comment 2•5 years ago
|
||
The dummy channel is created because we might not have a channel when access cookies in a document. For example, we access cookies for an 'about:blank' page in an iframe. In this case, we would use the URI of the NodePrinicpal() to create a dummy channel and do the privacy status check through this channel. Because the NodePrincpal() was originated from the parent node, so I think we can copy the hasStoragePermission flag from the parent when we create the dummy channel.
The parent is supposed to be in the same process for this case since the real channel is not ready yet. This means the process switch never happens for this document because the switch only happens after the channel was opened. So, the document and its parent should be in the same process either in non-FIssion and Fission mode. So, we can safely get the flag from the parent and use it in the dummy channel.
|
|
Assignee | |
Comment 3•5 years ago
|
||
When we access cookies in a document, we will create a dummy channel for
it if the real channel is not available. For example, accessing cookies
in an 'about:blank' page in an iframe. In this case, we need to set the
hasStoragePermission to this dummy channel since this channel won't be
opened. We will get the flag from the parent document since this channel
is created by the url of the document's NodePrincipal. And it will be
the same as the principal of the parent document since it is an 'about:blank'
page. So, we can use the flag in the parent document directly because
they are supposed to be the same.
|
||
Comment 5•5 years ago
|
||
| bugherder | ||
Description
•