statechange at s.onstatechange.
+ statechange at s.
@@ -1015,7 +1015,7 @@
ISSUE: Do we want to distinguish the permission-denied outcome from
the no-screens-available outcome? Developers would be able to infer
- it anyway from onavailablechange.
+ it anyway from availablechange.
statechange at
- s.onstatechange.
+ named statechange at s.
@@ -1216,14 +1215,14 @@ EventHandlers registered
- to the onavailablechange event. Using this
- information, implementation specific discovery of availablechange event. Using this information,
+ implementation specific discovery of presentation displays can be resumed
or suspended, in order to save power.
The user agent must keep a list of available presentation
displays. According to the number of event handlers for
- onavailablechange, the user agent must also keep the
- list up to date by running the algorithm for availablechange, the user agent must also keep the list
+ up to date by running the algorithm for monitoring the list of available
presentation displays.
When an event handler is added to the list of event handlers
- registered for the onavailablechange event, the user
+ registered for the availablechange event, the user
agent must run the algorithm to monitor the list of
available presentation displays.
@@ -1245,7 +1244,7 @@
When an event handler is removed from the list of event handlers
- registered to the onavailablechange event, the user
+ registered to the availablechange event, the user
agent must run the following steps:
availablechange at with the event's
+ availablechange at
+ NavigatorPresentation with the event's
available property set to true.
@@ -1301,7 +1301,8 @@ availablechange with the event's
+ availablechange at
+ NavigatorPresentation with the event's
available property set to false.
@@ -1333,9 +1334,9 @@ availablechange at E (and only
- E) with the event's available property
- set to false.
+ availablechange at
+ NavigatorPresentation with the event's
+ available property set to false.
+ The availablechange event reveals one bit of information
+ about the presence (or non-presence) of a presentation
+ screen 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.
+
+ 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 ISSUE 9: + How to filter available screens according to the content being + presented? +
++ We do not want to require user permission before disclosing the + presence of a presentation display, as it is counter to the initial + purpose of improving the user experience. See ISSUE 10: Is user + permission required to prompt for screen availability information? +
++ A presentation session is allowed to be accessed across + origins; the presentation URL and presentation ID used to create the + presentation are the only information needed to join a session from any + origin in that user agent. In other words, a presentation is not tied + to a particular opening origin. +
++ This design allows controlling contexts from different domains to + connect to a shared presentation resource. The security of the + presentation ID prevents arbitrary pages from connecting to an existing + presentation. +
++ This specification does not prohibit a user agent from publishing + information about its set of presentations. The group + envisions a user agent on a another device (distinct from the + controller or presentation) becoming authorized to join the + presentation, either by user action or by discovering the + presentation's URL and id. +
++ This section should provide informative guidance as to what constitutes + a reasonable context for a Web page to become authorized to control a + presentation session. +
++ The presentation API abstracts away what "local" means for displays, + meaning that it exposes network-accessible displays as though they were + local displays. The Presentation API requires user permission for a + page to access any display to mitigate issues that could arise, such as + showing unwanted content on a display viewable by others. +
++ The presentation URL and presentation ID can be used to connect to a + presentation session from another browsing context. They can be + intercepted if an attacker can inject content into the controlling + page. +
++ Should we restrict the API to some extent in non secure contexts? +
++ The content displayed on the presentation is different from the + controller. In particular, if the user is logged in in both contexts, + then logs out of the controlling browsing context, she will not be + automatically logged out from the presenting browsing context. + Applications that use authentication should pay extra care when + communicating between devices. +
++ The set of presentations known to the user agent should be cleared when + the user requests to "clear browsing data." +
++ The spec should specify any restrictions on the presenting browsing + context when the opening browsing context is in "incognito" mode. See + ISSUE 14: + Define user agent context for rendering the presentation +
++ The spec should clarify what is to happen to the set of known + presentations in "incognito" (private browsing context) mode. +
++ This spec will not mandate communication protocols, but it should set + some guarantees of message confidentiality and authenticity. +
++ ISSUE 80: + Define security requirements for messaging channel between secure + origins +
statechange at s.onstatechange.
+ statechange at s.
ISSUE: Do we want to distinguish the permission-denied outcome from
the no-screens-available outcome? Developers would be able to infer
- it anyway from onavailablechange.
+ it anyway from availablechange.
statechange at
- s.onstatechange.
+ named statechange at s.
@@ -1241,13 +1259,13 @@ EventHandlers registered
- to the onavailablechange event. Using this
- information, implementation specific discovery of presentation displays can be resumed
+ to the availablechange event. Using this information,
+ implementation specific discovery of presentation displays can be resumed
or suspended, in order to save power.
The user agent must keep a list of available presentation
displays. According to the number of event handlers for
- onavailablechange, the user agent must also keep the
- list up to date by running the algorithm for monitoring the list of available
+ availablechange, the user agent must also keep the list
+ up to date by running the algorithm for monitoring the list of available
presentation displays.
When an event handler is added to the list of event handlers
- registered for the onavailablechange event, the user
+ registered for the availablechange event, the user
agent must run the algorithm to monitor the list of
available presentation displays.
When an event handler is removed from the list of event handlers
- registered to the onavailablechange event, the user
+ registered to the availablechange event, the user
agent must run the following steps:
availablechange at with the event's
+ availablechange at
+ NavigatorPresentation with the event's
available property set to true.
@@ -1319,7 +1338,8 @@ availablechange with the event's
+ availablechange at
+ NavigatorPresentation with the event's
available property set to false.
@@ -1349,9 +1369,9 @@ availablechange at E (and only
- E) with the event's available property
- set to false.
+ availablechange at
+ NavigatorPresentation with the event's
+ available property set to false.
+ The availablechange event reveals one bit of information
+ about the presence (or non-presence) of a presentation
+ screen 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.
+
+ 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 ISSUE 9: + How to filter available screens according to the content being + presented? +
++ We do not want to require user permission before disclosing the + presence of a presentation display, as it is counter to the initial + purpose of improving the user experience. See ISSUE 10: Is user + permission required to prompt for screen availability information? +
++ A presentation session is allowed to be accessed across + origins; the presentation URL and presentation ID used to create the + presentation are the only information needed to join a session from any + origin in that user agent. In other words, a presentation is not tied + to a particular opening origin. +
++ This design allows controlling contexts from different domains to + connect to a shared presentation resource. The security of the + presentation ID prevents arbitrary pages from connecting to an existing + presentation. +
++ This specification does not prohibit a user agent from publishing + information about its set of presentations. The group + envisions a user agent on a another device (distinct from the + controller or presentation) becoming authorized to join the + presentation, either by user action or by discovering the + presentation's URL and id. +
++ This section should provide informative guidance as to what constitutes + a reasonable context for a Web page to become authorized to control a + presentation session. +
++ The presentation API abstracts away what "local" means for displays, + meaning that it exposes network-accessible displays as though they were + local displays. The Presentation API requires user permission for a + page to access any display to mitigate issues that could arise, such as + showing unwanted content on a display viewable by others. +
++ The presentation URL and presentation ID can be used to connect to a + presentation session from another browsing context. They can be + intercepted if an attacker can inject content into the controlling + page. +
++ Should we restrict the API to some extent in non secure contexts? +
++ The content displayed on the presentation is different from the + controller. In particular, if the user is logged in in both contexts, + then logs out of the controlling browsing context, she will not be + automatically logged out from the presenting browsing context. + Applications that use authentication should pay extra care when + communicating between devices. +
++ The set of presentations known to the user agent should be cleared when + the user requests to "clear browsing data." +
++ The spec should specify any restrictions on the presenting browsing + context when the opening browsing context is in "incognito" mode. See + ISSUE 14: + Define user agent context for rendering the presentation +
++ The spec should clarify what is to happen to the set of known + presentations in "incognito" (private browsing context) mode. +
++ This spec will not mandate communication protocols, but it should set + some guarantees of message confidentiality and authenticity. +
++ ISSUE 80: + Define security requirements for messaging channel between secure + origins +