-
Notifications
You must be signed in to change notification settings - Fork 55
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 and origins <> origin groups #34
Comments
What does the "<>" in the title mean? |
Probably something like: "versus" / "something of conflicting nature". |
I see, I wasn't sure whether to read it as the Visual Basic inequality operator :) |
The current text for this seems adequate to me actually. Especially after 08dbaf9. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For the sake of this discussion, an origin group are all origins that share a domain label + public suffix (and have the same scheme, but not necessarily the same port).
If a user agent wants to group cookies with other kinds of storage in the UI, which is quite reasonable as they can be used to revive each other and generally share a bunch of properties, and cookies use origin group and storage and the "persistentstorage" permission uses origins, how is this reconciled?
And if the UI aligns with origin groups, does it make sense for the API to be origin-based?
I'd be interested in hearing from other implementers. I think at Mozilla we tentatively concluded that's it's probably okay to keep as much origin-bound as possible, while not necessarily surfacing that to the UI.
The text was updated successfully, but these errors were encountered: