1475811 - Entering URLs in address bar violates FPI

Status: NEW

(Core :: DOM: Navigation, enhancement, P5)

Description

[Arthur Edelstein [:arthur]]

In Tor Browser, we observed that first-party isolation was violated by a speculative connect when the user entered a URL or search term in the address bar. The line causing this was here:

https://dxr.mozilla.org/mozilla-esr60/rev/dd52b41d2b775e5c7261ce52795268b7670635fc/toolkit/components/remotebrowserutils/RemoteWebNavigation.js#92

It seems the principal is null, and therefore no firstPartyDomain is assigned. For a visit to a new site, the firstPartyDomain should be assigned to the URL entered by the user. For a search string, the firstPartyDomain should be assigned to the search engine domain.

However, I'm not sure where the patch should go: whether it should be local, or if a principal needs to be generated and passed upstream of this function.

Comment 1

[Gary Chen [:xeonchen]]

IIUC, this issue would be FPI only since dFPI doesn't fill firstPartyDomain field for top-level requests.

Comment 2

[Pier Angelo Vendrame]

Attachment: patch

Hello!
I think this patch could solve the behavior you described in comment 0.
However, I am not sure on how to test it the correct way.
I have written a small hello world webapp to simulate third-party cookies, and with FPI enabled it work as expected.
However, I am not sure on how to catch any problem caused by the speculative connection.
Could you please tell me how you observed the violation in the first place?
We think that Tor Browser is not affected even without your original patch, because speculative connections are blocked when a proxy is used, if we understood correctly.
So, I am testing with Firefox, to try to understand what the wrong behavior would look like.

Thanks!

Comment 3

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:adw, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Drew Willcoxon :adw]

If the speculative connection being reported here is in RemoteWebNavigation, then this is downstream of the address bar. The address bar hands off to openTrustedLinkIn() to load URIs.

So I don't think the Address Bar component is well suited to handle this bug -- I know I'm not, and I don't know the answer to the question in comment 2 about how to test the patch in Firefox. Based on blame around the relevant lines in RemoteWebNavigation, it looks like Core :: DOM: Navigation might be a better component.

Comment 5

[Manuel Bucher [:manuel]]

Not sure if the same thing, but I've seen incorrect partitionKey behavior in predictive connections in Bug 1951466.