You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current history API, it's clear that when sending objects as part of the history state, these objects are not persistent and totally private.
But when adding ui-state to the URL fragment (if I'm reading the explainer correctly), these objects become more persistent and less private - as users can share them and link to them (even if they don't get bookmarked, and they're invisible to cross-origin).
This would require web developers to use extra care when using them, which might make them less suitable to certain use-cases than the current API or sessionStorage.
For example, if a certain page asks the user for their age (or any other private detail), with the current state API it's OK to pass it as a state in pushState or replaceState, but with the new API the user's age might leak to the URL when they share or link to the URL they're currently viewing.
In addition to privacy, this would require extra care with regards to versioning, as different versions of the same web page would require to be backward-compatible to some extent with previous versions of whatever is in the UI state JSON.
I suggest that the preservation of UI state would be configurable with several options, for example it could have the following options:
not be preserved in the URL (behave like today)
persist as a key to session storage (private, version-specific)
persist as a key to local storage (private, backwards compatible)
Be exposed in the URL fragment (public, backwards compatible)
The text was updated successfully, but these errors were encountered:
In the current history API, it's clear that when sending objects as part of the history state, these objects are not persistent and totally private.
But when adding
ui-state
to the URL fragment (if I'm reading the explainer correctly), these objects become more persistent and less private - as users can share them and link to them (even if they don't get bookmarked, and they're invisible to cross-origin).This would require web developers to use extra care when using them, which might make them less suitable to certain use-cases than the current API or sessionStorage.
For example, if a certain page asks the user for their age (or any other private detail), with the current state API it's OK to pass it as a state in
pushState
orreplaceState
, but with the new API the user's age might leak to the URL when they share or link to the URL they're currently viewing.In addition to privacy, this would require extra care with regards to versioning, as different versions of the same web page would require to be backward-compatible to some extent with previous versions of whatever is in the UI state JSON.
I suggest that the preservation of UI state would be configurable with several options, for example it could have the following options:
The text was updated successfully, but these errors were encountered: