Skip to content

Commit

Permalink
Update index.html
Browse files Browse the repository at this point in the history
  • Loading branch information
@mfoltzgoogle @anssiko
mfoltzgoogle authored and anssiko committed Jun 5, 2015
1 parent db1690c commit ad04ae3
Show file tree
Hide file tree
Showing 2 changed files with 46 additions and 62 deletions.
9 changes: 4 additions & 5 deletions Overview.src.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1426,10 +1426,9 @@ <h3>
<p class="open-issue">
Requiring user permission before disclosing the presence of a
presentation display is counter to the initial purpose of improving the
user experience. See
<a href="https://github.com/w3c/presentation-api/issues/10">ISSUE 10: Is
user permission required to prompt for screen availability
information?</a>
user experience. See <a href=
"https://github.com/w3c/presentation-api/issues/10">ISSUE 10: Is user
permission required to prompt for screen availability information?</a>
</p>
<h3>
Cross-origin access
Expand Down Expand Up @@ -1494,7 +1493,7 @@ <h3>
</p>
<p class="open-issue">
The spec should specify any restrictions on the presenting browsing
context when the opening browsing context is in "incognito" mode. See
context when the opening browsing context is in "incognito" mode. See
<a href="https://github.com/w3c/presentation-api/issues/14">ISSUE 14:
Define user agent context for rendering the presentation</a>
</p>
Expand Down
99 changes: 42 additions & 57 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -302,22 +302,22 @@ <h2 class="no-num no-toc" id="table-of-contents">
</a>
<ol>
<li><a href="#personally-identifiable-information"><span class="secno">7.1 </span>
Personally Identifiable Information
Personally identifiable information
</a></li>
<li><a href="#cross-origin-presentations"><span class="secno">7.2 </span>
Cross-origin presentations
<li><a href="#cross-origin-access"><span class="secno">7.2 </span>
Cross-origin access
</a></li>
<li><a href="#device-access"><span class="secno">7.3 </span>
Device Access
</a></li>
<li><a href="#temporary-identifiers-and-browser-state"><span class="secno">7.4 </span>
Temporary identifiers and browser state
</a></li>
<li><a href="#incognito-mode"><span class="secno">7.5 </span>
Incognito mode
<li><a href="#incognito-mode-and-clearing-of-browsing-data"><span class="secno">7.5 </span>
Incognito mode and clearing of browsing data
</a></li>
<li><a href="#messaging-channel"><span class="secno">7.6 </span>
Messaging channel
<li><a href="#messaging-between-presentation-sessions"><span class="secno">7.6 </span>
Messaging between presentation sessions
</a></ol></li>
<li><a href="#references"><span class="secno">8 </span>
References
Expand Down Expand Up @@ -1438,47 +1438,32 @@ <h2 id="security-and-privacy-considerations"><span class="secno">7 </span>
Security and privacy considerations section</a>
</p>
<h3 id="personally-identifiable-information"><span class="secno">7.1 </span>
Personally Identifiable Information
Personally identifiable information
</h3>
<p>
The Presentation API reveals a bit of information about the presence of
secondary devices typically discovered through network discovery. This
can be used for fingerprinting. More information may be leaked in the
future if some sort of filtering based on capabilities is added to the
spec (see ISSUE #9 How to filter available screens according to the
content being presented).
The Presentation API reveals one bit of information about the presence
(or non-presence) of a <span>presentation screen</span> typically
discovered through the local area network. This could be used in
conjunction with other information for fingerprinting the user.
However, this information is also dependent on the user's local network
context, so the risk is minimized.
</p>
<p>
Requiring user permission before disclosing that information dismisses
the initial purpose of improving the user experience (tracked in #10 Is
user permission required to prompt for screen availability
information?).
<p class="open-issue">
If we allow the page to filter the set of presentation screens based on
capabilities, then more bits of more information would be revealed.
This feature, if implemented, should take privacy into consideration.
See <a href="https://github.com/w3c/presentation-api/issues/9">ISSUE 9:
How to filter available screens according to the content being
presented?</a>
</p>
<p>
A few possible mitigations (not necessarily exclusive):
<p class="open-issue">
Requiring user permission before disclosing the presence of a
presentation display is counter to the initial purpose of improving the
user experience. See <a href="https://github.com/w3c/presentation-api/issues/10">ISSUE 10: Is user
permission required to prompt for screen availability information?</a>
</p>
<ul>
<li>
<p>
Restrict the API to secure contexts.
</p>
</li>
<li>
<p>
Do not enable filtering based on capabilities (at all, or without
user consent).
</p>
</li>
<li>
<p>
Make the need useless, e.g. by having the Presentation API fall
back to a pop-up window if there are no other screens available.
User experience would greatly suffer though.
</p>
</li>
</ul>
<h3 id="cross-origin-presentations"><span class="secno">7.2 </span>
Cross-origin presentations
<h3 id="cross-origin-access"><span class="secno">7.2 </span>
Cross-origin access
</h3>
<p>
The <span>set of presentations</span> for a user agent (or a user
Expand Down Expand Up @@ -1521,17 +1506,11 @@ <h3 id="temporary-identifiers-and-browser-state"><span class="secno">7.4 </span>
The presentation URL and presentation ID could be used to connect to a
running session from another tab or another user agent. They can easily
be retrieved if an attacker can inject content in the page. Again, one
possible solution would be to restrict the API over secure contexts.
possible solution would be to restrict the API to secure contexts.
</p>
<h3 id="incognito-mode"><span class="secno">7.5 </span>
Incognito mode
<h3 id="incognito-mode-and-clearing-of-browsing-data"><span class="secno">7.5 </span>
Incognito mode and clearing of browsing data
</h3>
<p>
The spec should clarify what is to happen to the set of known
presentations in "incognito" mode. The spec should also specify the
restrictions on the presenting browsing context when the opening
browsing context is in "incognito" mode.
</p>
<p>
The content displayed on the presenting context is different from the
local one. In particular, if the user is logged in in both contexts,
Expand All @@ -1540,16 +1519,22 @@ <h3 id="incognito-mode"><span class="secno">7.5 </span>
Applications that use authentication should pay extra care when
communicating between devices.
</p>
<p>
The set of presentations known to the user agent should be cleared when
the user requests to "clear browsing data."
</p>
<p class="open-issue">
The spec should specify any restrictions on the presenting browsing
context when the opening browsing context is in "incognito" mode. See
<a href="https://github.com/w3c/presentation-api/issues/14">ISSUE 14:
Define user agent context for rendering the presentation</a>
</p>
<p>
The set of presentations known to the user agent should be cleared when
the user requests to "clear browsing data."
<p class="note">
The spec should clarify what is to happen to the set of known
presentations in "incognito" (private browsing context) mode.
</p>
<h3 id="messaging-channel"><span class="secno">7.6 </span>
Messaging channel
<h3 id="messaging-between-presentation-sessions"><span class="secno">7.6 </span>
Messaging between presentation sessions
</h3>
<p>
This spec will not mandate communication protocols, but it should set
Expand Down

0 comments on commit ad04ae3

Please sign in to comment.