Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ui-state & privacy/persistence #27

Open
noamr opened this issue Feb 3, 2021 · 0 comments
Open

ui-state & privacy/persistence #27

noamr opened this issue Feb 3, 2021 · 0 comments

Comments

@noamr
Copy link

noamr commented Feb 3, 2021

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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant