Sec-Fetch-Site for navigations from outside the browser

[dveditz]

If an external app opens a URL in the browser should the value of Sec-Fetch-Site: be cross-site or none? We're having this argument in Firefox bug 1722044 because our current behavior sends cross-site and someone complained that it differed from Chrome which sends none. Is Chrome intentionally sending none (the user definitely chose this specific URL to load) or is that an accidental byproduct of being loaded from browser parent code without a webby history attached?

§ 4.3 says

The goal is to distinguish between "webby" navigations that are controlled by a given (potentially malicious!) website (e.g. links, the window.location setter, form submissions, etc.), and those that are not (e.g. user interaction with a user agent’s address bar, bookmarks, etc).

The browser has no way of knowing what the user was doing to trigger the external load, but in my own use the links I end up opening are usually someone else's content. This is especially true on mobile where there's no real difference between the same link opened from the Facebook app vs opened from a Facebook tab, or the Element app vs a link in https://chat.mozilla.org or some other Matrix instance. Or links in a PDF or Word document you downloaded from somewhere and then opened in their local executables, vs the same links in a PDF tab or an online Office365 word document.

Follow-up issue: we equally can't be 100% sure the user initiated the navigation in the 3rd party app, but most apps play nice so it seems totally reasonable to set Sec-Fetch-User: ?1 for these. Apps that open random unintended URLs on their own are despised and quickly uninstalled.

[annevk]

The way I see it this mainly relates to Referer and perhaps as to whether your browsing context is fresh or not. In any event I don't see how you can meaningfully distinguish between the user copying and pasting an outside-the-browser-link into the address bar and clicking on it.

[arturjanc]

tl;dr I'm fairly sure Chrome's behavior is intentional in this case.

The idea behind the none value is to apply to navigations which aren't spoofable by websites (at least without convincing the user to help the attacker). This allows developers to permit navigations from more trusted non-web-controlled surfaces while disallowing navigations initiated by -- less trusted -- web content. The examples in https://www.w3.org/TR/fetch-metadata/#directly-user-initiated and discussions in #71 and #47 go into a little bit of detail about the edge cases. The case of external apps described by @dveditz seems similar to the ones where we settled on none; the prerequisites for an attack (navigating to the attacker's page in a separate app, downloading a file, etc.) make it harder -- though not impossible -- for an attacker to bypass restrictions based on Sec-Fetch-* headers.

I can see the argument that it's safer for the browser to send cross-site when unsure, but that has a cost for developers: it means that applications which receive navigations from more trusted sources (e.g. a local applications) will not be able to reject web-initiated cross-site navigations because the Sec-Fetch-* values will be identical. This prevents them from deploying restrictions based on the headers.

If we want to address this in a more principled way, we could take an approach similar to what we did for extensions in #47 (comment) where we annotate the request with some information that lets a website distinguish between web-initiated and extension-initiated requests (in this case, by using an Origin: chrome-extension://... header). But, on balance, my inclination would be to go with none because it's simpler and mostly consistent with the reasoning we've applied so far.

[arturjanc]

BTW, the spec does touch upon this in the last example:

If content is dragged from elsewhere (the user agent’s bookmark bar, another app entirely, etc), then Sec-Fetch-Site: none may be appropriate.

I.e. if dragging from another application sends none, then arguably clicking on a link in another application should send the same value.

[dveditz]

"touch upon" isn't the same as "specifies", and "may be appropriate" clearly implies it might NOT be appropriate. 😃

I agree that there are many apps that I'd trust to open links without shenanigans. There are also clearly malicious cases where the link could be as deceptive as any "web" link -- particularly in mail, chat apps, and those emailed document attachments we keep telling people not to open but they clearly do anyway. Even more so on mobile where just about every popular website pushes you to use their app instead.

I don't mind losing the argument for what the header value ought to be (@annevk is not the only Mozillian happy with none), but the fact that there is a difference in behavior and it is already causing trouble for some developers shows the spec needs to take a normative stand about this case. Even if it's only a SHOULD.

[dav-oss]

I understand your point. "Touch upon" and "specifies" do have different connotations, and "may be appropriate" does imply the possibility that it may not be appropriate in certain cases. It's important to consider the potential risks associated with opening links, especially in email, chat apps, and document attachments where deceptive links can be prevalent.

While there are many trusted apps that can handle links without issues, it's undeniable that malicious cases exist. Users may unknowingly open deceptive links, particularly on mobile devices where popular websites often encourage app usage.

Regarding the argument about the header value, I recognize that there are differing opinions on what it should be. However, the fact that developers are experiencing difficulties and inconsistencies highlights the need for the specification to provide a clear stance on this matter. Even if it's only a "SHOULD" recommendation, having a normative stance would help address the challenges faced by developers.

Overall, finding the right balance between convenience and security is crucial when it comes to handling links, and it's essential for the specification to provide clear guidelines to mitigate potential risks.