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.
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.
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.
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.