-
Notifications
You must be signed in to change notification settings - Fork 39
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
Complete Security and Privacy section #257
Conversation
</div> | ||
<p> | ||
When in private browsing mode ("incognito"), the set of presentations | ||
known to the user agent must be initially empty, and all state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to be more specific - are we making a requirement of the controlling or receiving user agent?
What if I start a presentation from a non-incognito context - would I be allowed to connect to it from an incognito context (similar to connecting to it from another device)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recalled the receiving UA to be de facto in incognito, but notice that is not specified. Thus I was thinking controlling UA here initially. Now I realize this needs to be clarified. Feel free to amend the PR.
Re session started from non-incognito, then connected to from incognito. Wouldn't it be bad UX to deny this? How about asking the UA to explain to the user incognito in such a case may not work as expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the PR to clarify that this applies to the controlling user agent.
I think stating that there are no presentation connections inherited from the existing (non-incognito) session is the right assertion. If the user explicitly creates a connection via start()
, or initiating a defaultRequest
, that should be possible. Such connections should go away when the session ends.
Updated the wording to try to capture this.
Complete Security and Privacy section
This PR attempts to fix the remaining open issues in the Security and Privacy section enumerated in issue #45 (comment). These issues were blocking the wide review WD publication.
We will continue to improve the Security and Privacy sections based on new information received from horizontal reviews, and can reopen issues #45 when new information resurfaces.