search

w3c / webappsec-fetch-metadata

Fetch Metadata
https://w3c.github.io/webappsec-fetch-metadata/
Other
75 stars 28 forks source link

Sec-Fetch-User and Sec-Fetch-Site for user-initiated UI navigations #71

Open annevk opened 3 years ago

annevk commented 3 years ago

There's a set of actions that a user can take that are not well covered by the current specification nor by HTML's navigate:

  1. Clicking a bookmark
  2. Manipulating the address bar and hitting enter
  3. Clicking the refresh button
  4. Clicking the back button and there's no bfcache entry

It seems to me that in these cases Sec-Fetch-User is true and in a subset of these cases Sec-Fetch-Site is none (the first two).

I'm filing this here as

If sourceBrowsingContext's WindowProxy's [[Window]] value has transient activation, then set request's user-activation to true.

what is in HTML today cannot ever cover these scenarios. There are plans to refactor HTML's navigate algorithm so it can cover this better and it's probably not worth fixing this before that happens. In the meantime though implementations ought to agree on behavior.

cc @arturjanc @domenic @mikewest

domenic commented 3 years ago

https://wicg.github.io/app-history/#user-initiated-patches covers some of these, in particular (1) and (2).

It should probably cover (3) as well, I think I just forgot that it exists. (In HTML it's around here: "When a user requests that the active document of a browsing context be reloaded through a user interface element...").

It could be expanded to cover (4), by threading through "browser UI" from "traverse the history by a delta" back into "navigate". It doesn't need to do so for the app history navigate event, but it'd be good to do so for consistency.

It's surprising to me that you'd distinguish (3) and (4) from (1) and (2).

annevk commented 3 years ago

(3) and I suspect (4) keep the original Referer header, so I think that should also be the case for Sec-Fetch-Site. This isn't really defined at the moment I think.

From that perspective I could also see a slight argument for not setting Sec-Fetch-User to true for 4) (though not really for (3)) as it's slightly less likely the user would get the document they expected. But I think I have convinced myself that true is fine for both.

arturjanc commented 3 years ago

Just a quick comment that I agree with the behavior proposed above: setting Sec-Fetch-User in these cases and, in cases (1) and (2) setting Sec-Fetch-Site: none.

We've had some nuanced discussions about when to use none in Sec-Fetch-Site and the general idea was to do it for requests that cannot be made by a website, at least without substantial help from the user. So navigations from bookmarks/address bar match that interpretation well; refresh/back button navigate you to URLs under control of web content, so they should set Sec-Fetch-Site based on the site that put the given entry in the history (i.e. either same-origin, same-site, or cross-site).

mikewest commented 3 years ago

I should have mentioned earlier that I generally agree with @arturjanc agreeing with @annevk. :)

Are there concrete changes y'all would suggest to the document in order to lock those in to some extent?

annevk commented 3 years ago

I think we should wait for HTML to have the necessary infrastructure, then ensure that everything is aligned with the tentative conclusions here, and then close this.