We will add the isolation test for the isolate favicon requests by first party. https://torpat.ch/13670

Please note we now test favicon cache and network isolation by first-party in the following Tor Browser patch: https://torpat.ch/13749 See "Regression tests for first-party isolation of cache"

Is this a testing bug or implementation bug?

Dave says that favicons are not isolated by usercontext id. Kamil, can you check this out?

Because the favicon cache will be tested in the Bug 1264577, I proposed that we should check whether cookies of favicon requests is leaking across different first party domains here. Arthur, how do you think?

(In reply to Tim Huang[:timhuang] from comment #5) > Because the favicon cache will be tested in the Bug 1264577, I proposed that > we should check whether cookies of favicon requests is leaking across > different first party domains here. > > Arthur, how do you think? Maybe open a new ticket for clarity? I think it is unclear whether this was intended as an implementation or testing bug. I think we may be able to mark this bug as a duplicate of bug 1277803 if the latter is a complete implementation of first-party isolation for favicons.

I am going to add a test for favicon in terms of the first party isolation in the Bug 1277803, so this bug will be marked as a duplicate of Bug 1277803. In the comment 6, I proposed that we should test cookies for favicon across different first party domains. However, after contemplated the behavior of favicon loading, testing cookies seems not a good idea. Instead, I think we should test that whether the favicon loading is using correct 'mFirstPartyDomain'. But it's hard to fit in the test framework for such tests, so I will write a test without using the test framework. What do you think about this, Arthur?

(In reply to Tim Huang[:timhuang] from comment #7) > I am going to add a test for favicon in terms of the first party isolation > in the Bug 1277803, so this bug will be marked as a duplicate of Bug > 1277803. In the comment 6, I proposed that we should test cookies for > favicon across different first party domains. However, after contemplated > the behavior of favicon loading, testing cookies seems not a good idea. Can you mention the reason you came to this conclusion? I'm not familiar with the behavior of cookies delivered via favicons, but they do sound like a potential tracking vector. > Instead, I think we should test that whether the favicon loading is using > correct 'mFirstPartyDomain'. I agree that testing favicon loading (origin-attribute-isolated caching and confirming that the channel has the correct origin attributes) directly is important. > But it's hard to fit in the test framework for > such tests, so I will write a test without using the test framework. What do > you think about this, Arthur? That sounds OK to me! Whatever you think will work best.

(In reply to Arthur Edelstein [:arthuredelstein] from comment #8) > (In reply to Tim Huang[:timhuang] from comment #7) > > I am going to add a test for favicon in terms of the first party isolation > > in the Bug 1277803, so this bug will be marked as a duplicate of Bug > > 1277803. In the comment 6, I proposed that we should test cookies for > > favicon across different first party domains. However, after contemplated > > the behavior of favicon loading, testing cookies seems not a good idea. > > Can you mention the reason you came to this conclusion? I'm not familiar > with the behavior of cookies delivered via favicons, but they do sound like > a potential tracking vector. First, the favicon loading is triggered by the top-level page, so it just like another loading from the top-level page, but the different part is that it been loaded by the chrome side. Hence, for two top-level pages with different top-level domains, the cookies should be separated naturally even if the first party isolation is turned off. But we still have to make sure that the favicon loading is double keying correctly when first party isolation is turned on. Second, IIUC, the frames or iframes cannot change the favicon. So the favicon will not leak across iframes/frames with different first party domains.

(In reply to Tim Huang[:timhuang] from comment #9) > (In reply to Arthur Edelstein [:arthuredelstein] from comment #8) > > (In reply to Tim Huang[:timhuang] from comment #7) > > > I am going to add a test for favicon in terms of the first party isolation > > > in the Bug 1277803, so this bug will be marked as a duplicate of Bug > > > 1277803. In the comment 6, I proposed that we should test cookies for > > > favicon across different first party domains. However, after contemplated > > > the behavior of favicon loading, testing cookies seems not a good idea. > > > > Can you mention the reason you came to this conclusion? I'm not familiar > > with the behavior of cookies delivered via favicons, but they do sound like > > a potential tracking vector. > > First, the favicon loading is triggered by the top-level page, so it just > like another loading from the top-level page, but the different part is that > it been loaded by the chrome side. Hence, for two top-level pages with > different top-level domains, the cookies should be separated naturally even > if the first party isolation is turned off. But if the favicon comes from a third-party domain, is it not possible that it can load a third-party cookie (assuming third-party cookies are enabled), such that a user could be tracked across domains via the same third-party favicon host? While I understand cookies will be in general keyed by origin attribute, perhaps a test would still be useful to confirm that the favicon's origin attributes (containing the top-level page's domain as firstparty) are correctly propagated to the cookie and we have isolation as expected.

Yes, you are right, I have missed this part of the third-party domain for favicon loading. In this case, the favicon itself is like an iframe/frame, and we have to test the isolation for such favicon loading. Then I will find a way to test this behavior. Thanks, Arthur.