Sec-Fetch-User and Sec-Fetch-Site for user-initiated UI navigations #71
Comments
|
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). |
|
(3) and I suspect (4) keep the original From that perspective I could also see a slight argument for not setting |
|
Just a quick comment that I agree with the behavior proposed above: setting We've had some nuanced discussions about when to use |
|
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? |
|
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. |
This imports much of the specification from https://github.com/WICG/navigation-api/blob/91c2e7f959418d71e26e5b9a6723fed2944001d9/spec.bs. It includes some fixes and renamings, as well as a lot of rearranging to flow better, but the feature set is the same. In addition to the new "navigation API" section under "APIs related to navigation and session history", this makes the following changes to integrate the navigation API: * Introduces the NavigationHistoryBehavior enum, as a superset of the "history handling" specification type. This includes an "auto" value to reflect that existing entry points will sometimes default to "replace" instead of "push". The navigation API allows overriding that auto behavior in some circumstances by explicitly supplying "push". (But in some cases, i.e., the initial about:blank or javascript: URLs, this is still not allowed.) * Introduces the concept of "user navigation involvement". This will be helpful for solving issues such as w3c/webappsec-fetch-metadata#71. * Introduces the concept of "history-action user activation", which is a separate type of user activation meant to be used specifically to prevent back button tracking. It has no associated timeout (unlike transient activation), but can be flipped to false (unlike sticky activation). It is used by the navigation API to prevent calling navigateEvent.preventDefault() on two traversals in a row without intervening user activation. It is likely also to be useful for issues such as #7832. * The activation behavior for <a> and <area> elements is made more rigorous and consolidated into one place, so that we can hook into it appropriately to fire navigate events. * Some surgery was needed on "apply the history step". The result is that it now has slightly more parameters, but also several wrapper algorithms which take care of setting up those parameters correctly for the cases of: navigable creation/destruction, push/replace, reload, and traverse. It also returns a value indicating if the application of the history step was canceled, and if so, how; this is used to give informative errors as return values of navigation.traverseTo(). * The "check if unloading is user-canceled" algorithm has become "check if unloading is canceled", as it now handles firing a possibly-cancelable navigate event at the top-level traversable. Other changes scattered throughout are mostly integrating appropriate calls to the navigation API as necessary, especially to fire navigate events.
This imports much of the specification from https://github.com/WICG/navigation-api/blob/91c2e7f959418d71e26e5b9a6723fed2944001d9/spec.bs. It includes some fixes and renamings, as well as a lot of rearranging to flow better, but the feature set is the same. In addition to the new "navigation API" section under "APIs related to navigation and session history", this makes the following changes to integrate the navigation API: * Introduces the NavigationHistoryBehavior enum, as a superset of the "history handling" specification type. This includes an "auto" value to reflect that existing entry points will sometimes default to "replace" instead of "push". The navigation API allows overriding that auto behavior in some circumstances by explicitly supplying "push". (But in some cases, i.e., the initial about:blank or javascript: URLs, this is still not allowed.) * Introduces the concept of "user navigation involvement". This will be helpful for solving issues such as w3c/webappsec-fetch-metadata#71. * Introduces the concept of "history-action user activation", which is a separate type of user activation meant to be used specifically to prevent back button tracking. It has no associated timeout (unlike transient activation), but can be flipped to false (unlike sticky activation). It is used by the navigation API to prevent calling navigateEvent.preventDefault() on two traversals in a row without intervening user activation. It is likely also to be useful for issues such as whatwg#7832. * The activation behavior for <a> and <area> elements is made more rigorous and consolidated into one place, so that we can hook into it appropriately to fire navigate events. * Some surgery was needed on "apply the history step". The result is that it now has slightly more parameters, but also several wrapper algorithms which take care of setting up those parameters correctly for the cases of: navigable creation/destruction, push/replace, reload, and traverse. It also returns a value indicating if the application of the history step was canceled, and if so, how; this is used to give informative errors as return values of navigation.traverseTo(). * The "check if unloading is user-canceled" algorithm has become "check if unloading is canceled", as it now handles firing a possibly-cancelable navigate event at the top-level traversable. Other changes scattered throughout are mostly integrating appropriate calls to the navigation API as necessary, especially to fire navigate events.
This imports much of the specification from https://github.com/WICG/navigation-api/blob/91c2e7f959418d71e26e5b9a6723fed2944001d9/spec.bs. It includes some fixes and renamings, as well as a lot of rearranging to flow better, but the feature set is the same. In addition to the new "navigation API" section under "APIs related to navigation and session history", this makes the following changes to integrate the navigation API: * Introduces the NavigationHistoryBehavior enum, as a superset of the "history handling" specification type. This includes an "auto" value to reflect that existing entry points will sometimes default to "replace" instead of "push". The navigation API allows overriding that auto behavior in some circumstances by explicitly supplying "push". (But in some cases, i.e., the initial about:blank or javascript: URLs, this is still not allowed.) * Introduces the concept of "user navigation involvement". This will be helpful for solving issues such as w3c/webappsec-fetch-metadata#71. * Introduces the concept of "history-action user activation", which is a separate type of user activation meant to be used specifically to prevent back button tracking. It has no associated timeout (unlike transient activation), but can be flipped to false (unlike sticky activation). It is used by the navigation API to prevent calling navigateEvent.preventDefault() on two traversals in a row without intervening user activation. It is likely also to be useful for issues such as whatwg#7832. * The activation behavior for <a> and <area> elements is made more rigorous and consolidated into one place, so that we can hook into it appropriately to fire navigate events. * Some surgery was needed on "apply the history step". The result is that it now has slightly more parameters, but also several wrapper algorithms which take care of setting up those parameters correctly for the cases of: navigable creation/destruction, push/replace, reload, and traverse. It also returns a value indicating if the application of the history step was canceled, and if so, how; this is used to give informative errors as return values of navigation.traverseTo(). * The "check if unloading is user-canceled" algorithm has become "check if unloading is canceled", as it now handles firing a possibly-cancelable navigate event at the top-level traversable. Other changes scattered throughout are mostly integrating appropriate calls to the navigation API as necessary, especially to fire navigate events.
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:
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
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
The text was updated successfully, but these errors were encountered: