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.

Sign up for GitHub

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

Jump to bottom

Complete Security and Privacy section #257

Merged
merged 7 commits into from Feb 4, 2016
Merged

Complete Security and Privacy section #257

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
fad91a1
Clarify incognito requirements
anssiko Feb 4, 2016
d3bdd76
Note DIAL URL probing in S&P section
anssiko Feb 4, 2016
223c622
Fix #45: Remove issue #45 pointer
anssiko Feb 4, 2016
014cebc
Add xref for DIAL. Clarify connections in incognito.
mfoltzgoogle Feb 4, 2016
20d5590
Tidy
mfoltzgoogle Feb 4, 2016
f772d29
Merge branch 'gh-pages' into issue-45-security-privacy
mfoltzgoogle Feb 4, 2016
0632789
Fix typo
mfoltzgoogle Feb 4, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
20 changes: 15 additions & 5 deletions index.html
View file
Open in desktop
Expand Up @@ -2360,7 +2360,6 @@ <h3>
<h2>
Security and privacy considerations
</h2>
<div class="issue" data-number="45"></div>
<h3>
Personally identifiable information
</h3>
Expand All @@ -2373,6 +2372,15 @@ <h3>
However, this information is also dependent on the user's local network
context, so the risk is minimized.
</p>
<p>
The API enables <a href=
"#monitoring-the-list-of-available-presentation-displays">monitoring
the list of available presentation displays</a>. How the user agent
determines the compatibility and availability of a presentation display
with a given URL is an implementation detail. This feature can be used
to probe information about DIAL applications the user has installed on
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe,

If a controlling user agent can match a presentation request URL to a DIAL application and determine its availability, this feature can be used to probe information about which applications ...

Also, add a reference for DIAL?

http://www.dial-multiscreen.org/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. Please feel free to update the PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

the presentation display without user interaction.
</p>
<h3>
Cross-origin access
</h3>
Expand Down Expand Up @@ -2497,10 +2505,12 @@ <h3>
The set of presentations known to the user agent should be cleared when
the user requests to "clear browsing data."
</p>
<div class="issue">
The spec should clarify what is to happen to the set of known
presentations in "incognito" (private browsing context) mode.
</div>
<p>
When in private browsing mode ("incognito"), the set of presentations
known to the user agent must be initially empty, and all state
Copy link
Contributor

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)?

Copy link
Member Author

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?

Copy link
Contributor

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.

associated with the browsing session must be made unavailable after the
session terminates.
</p>
<h3>
Messaging between presentation connections
</h3>
Expand Down