From 37117d434eb19b976ee16c8898ce0db2c102577d Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Mon, 1 Jun 2015 17:51:36 -0700 Subject: [PATCH 1/5] Initial copy for S+P section --- Overview.src.html | 131 +++++++++++++++++++++++++++++++++++-- index.html | 160 +++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 278 insertions(+), 13 deletions(-) diff --git a/Overview.src.html b/Overview.src.html index 5b21538..6313bb5 100755 --- a/Overview.src.html +++ b/Overview.src.html @@ -1216,14 +1216,14 @@

"https://github.com/w3c/presentation-api/blob/gh-pages/uc-req.md#req08-power-saving-friendly"> power saving non-functional requirement, the user agent must keep track of the number of EventHandlers registered - to the availablechange 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 - availablechange, 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.
@@ -1405,6 +1405,129 @@

ISSUE 45: Security and privacy considerations section

+

+ Personally Identifiable Information +

+

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

+

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

+

+ A few possible mitigations (not necessarily exclusive): +

+
    +
  • +

    + Restrict the API to secure contexts. +

    +
    • +
  • +

    + Do not enable filtering based on capabilities (at all, or without + user consent). +

    +
    • +
  • +

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

    +
    • +
+

+ Cross-origin presentations +

+

+ The set of presentations for a user agent (or a user + profile within that user agent) may persist across browing sessions. +

+

+ Cross-origin presentation sessions are allowed; the URL to present and + the presentation ID are the only information needed to join a session. + In other words, a presentation is not tied to a particular opening + origin. We could restrict the set of presentations per origin to ensure + that a third-party Web site cannot hijack a presentation it did not + create, for example by saying that D is represented as a set of tuples + (O, U, I, S) where O is the URL of the opening browsing context, and by + adjusting algorithms accordingly. +

+

+ The specification is also silent about exchanging information in that + set of presentations across user agents to authorize other devices to + join an existing presentation but that is envisioned (at least in the + charter of the group). +

+

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

+

+ Device Access +

+

+ The presentation API abstracts away what "local" means for screens, + meaning that it exposes network-based screens as though they were local + screens. The Presentation API requires user permission to mitigate + issues that could arise here. +

+

+ Temporary identifiers and browser state +

+

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

+

+ Incognito mode +

+

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

+

+ The content displayed on the presenting context is different from the + local one. In particular, if the user is logged in in both contexts, + then logs out on opening 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. +

+

+ ISSUE 14: + Define user agent context for rendering the presentation +

+

+ The set of presentations known to the user agent should be cleared when + the user requests to "clear browsing data." +

+

+ Messaging channel +

+

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

diff --git a/index.html b/index.html index 4c588c8..a425e42 100644 --- a/index.html +++ b/index.html @@ -77,8 +77,8 @@

Presentation API

-

- Editor's Draft 1 June 2015 +

+ Editor's Draft 2 June 2015

@@ -302,7 +302,26 @@

  • 7 Security and privacy considerations + +
      +
    1. 7.1 + Personally Identifiable Information +
      2. +
    2. 7.2 + Cross-origin presentations +
      3. +
    3. 7.3 + Device Access +
      4. +
    4. 7.4 + Temporary identifiers and browser state +
      5. +
    5. 7.5 + Incognito mode
      6. +
    6. 7.6 + Messaging channel +
  • 8 References
    • @@ -1053,7 +1072,7 @@

    6.4.1

    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.

    @@ -1245,13 +1264,13 @@

    6.4.4 In order to satisfy the power saving non-functional requirement, the user agent must keep track of the number of 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.
    6.4.4.1 @@ -1260,7 +1279,7 @@
    6.4.4.1

    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.

    @@ -1271,7 +1290,7 @@
    6.4.4.2

    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:

      @@ -1423,6 +1442,129 @@

      7 ISSUE 45: Security and privacy considerations section

      +

      7.1 + Personally Identifiable Information +

      +

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

      +

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

      +

      + A few possible mitigations (not necessarily exclusive): +

      +
        +
      • +

        + Restrict the API to secure contexts. +

        +
        • +
      • +

        + Do not enable filtering based on capabilities (at all, or without + user consent). +

        +
        • +
      • +

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

        +
        • +
      +

      7.2 + Cross-origin presentations +

      +

      + The set of presentations for a user agent (or a user + profile within that user agent) may persist across browing sessions. +

      +

      + Cross-origin presentation sessions are allowed; the URL to present and + the presentation ID are the only information needed to join a session. + In other words, a presentation is not tied to a particular opening + origin. We could restrict the set of presentations per origin to ensure + that a third-party Web site cannot hijack a presentation it did not + create, for example by saying that D is represented as a set of tuples + (O, U, I, S) where O is the URL of the opening browsing context, and by + adjusting algorithms accordingly. +

      +

      + The specification is also silent about exchanging information in that + set of presentations across user agents to authorize other devices to + join an existing presentation but that is envisioned (at least in the + charter of the group). +

      +

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

      +

      7.3 + Device Access +

      +

      + The presentation API abstracts away what "local" means for screens, + meaning that it exposes network-based screens as though they were local + screens. The Presentation API requires user permission to mitigate + issues that could arise here. +

      +

      7.4 + Temporary identifiers and browser state +

      +

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

      +

      7.5 + Incognito mode +

      +

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

      +

      + The content displayed on the presenting context is different from the + local one. In particular, if the user is logged in in both contexts, + then logs out on opening 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. +

      +

      + ISSUE 14: + Define user agent context for rendering the presentation +

      +

      + The set of presentations known to the user agent should be cleared when + the user requests to "clear browsing data." +

      +

      7.6 + Messaging channel +

      +

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

    8 From 13842abb4da8ebfaa4694aa746d90ca85a593c1c Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Tue, 2 Jun 2015 14:17:15 -0700 Subject: [PATCH 2/5] Copy edits in progress --- Overview.src.html | 81 ++++++++++++++++++++--------------------------- 1 file changed, 34 insertions(+), 47 deletions(-) diff --git a/Overview.src.html b/Overview.src.html index 6313bb5..264a263 100755 --- a/Overview.src.html +++ b/Overview.src.html @@ -1406,47 +1406,34 @@

    Security and privacy considerations section

    - Personally Identifiable Information + Personally identifiable information

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

    -

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

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

    -

    - A few possible mitigations (not necessarily exclusive): +

    + Requiring user permission before disclosing the presence of a + presentation display is counter to the initial purpose of improving the + user experience. See + ISSUE 10: Is + user permission required to prompt for screen availability + information?

    -
      -
    • -

      - Restrict the API to secure contexts. -

      -
      • -
    • -

      - Do not enable filtering based on capabilities (at all, or without - user consent). -

      -
      • -
    • -

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

      -
      • -

    - Cross-origin presentations + Cross-origin access

    The set of presentations for a user agent (or a user @@ -1489,17 +1476,11 @@

    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.

    - Incognito mode + Incognito mode and clearing of browsing data

    -

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

    The content displayed on the presenting context is different from the local one. In particular, if the user is logged in in both contexts, @@ -1508,16 +1489,22 @@

    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 set of presentations known to the user agent should be cleared when - the user requests to "clear browsing data." +

    + The spec should clarify what is to happen to the set of known + presentations in "incognito" (private browsing context) mode.

    - Messaging channel + Messaging between presentation sessions

    This spec will not mandate communication protocols, but it should set From a4f17b13e0e55441b8f96c9f949bd2a7457afbbd Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Tue, 2 Jun 2015 14:18:15 -0700 Subject: [PATCH 3/5] Update index.html --- Overview.src.html | 9 ++--- index.html | 99 ++++++++++++++++++++--------------------------- 2 files changed, 46 insertions(+), 62 deletions(-) diff --git a/Overview.src.html b/Overview.src.html index 264a263..ee0a9a2 100755 --- a/Overview.src.html +++ b/Overview.src.html @@ -1427,10 +1427,9 @@

    Requiring user permission before disclosing the presence of a presentation display is counter to the initial purpose of improving the - user experience. See - ISSUE 10: Is - user permission required to prompt for screen availability - information? + user experience. See ISSUE 10: Is user + permission required to prompt for screen availability information?

    Cross-origin access @@ -1495,7 +1494,7 @@

    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 ISSUE 14: Define user agent context for rendering the presentation

    diff --git a/index.html b/index.html index a425e42..776ee60 100644 --- a/index.html +++ b/index.html @@ -305,10 +305,10 @@

    1. 7.1 - Personally Identifiable Information + Personally identifiable information
      2. -
    2. 7.2 - Cross-origin presentations +
    3. 7.2 + Cross-origin access
    4. 7.3 Device Access @@ -316,11 +316,11 @@

    5. 7.4 Temporary identifiers and browser state
      6. -
    6. 7.5 - Incognito mode +
    7. 7.5 + Incognito mode and clearing of browsing data
      8. -
    8. 7.6 - Messaging channel +
    9. 7.6 + Messaging between presentation sessions

  • 8 References @@ -1443,47 +1443,32 @@

    7 Security and privacy considerations section

    7.1 - Personally Identifiable Information + Personally identifiable information

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

    -

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

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

    -

    - A few possible mitigations (not necessarily exclusive): +

    + Requiring user permission before disclosing the presence of a + presentation display is counter to the initial purpose of improving the + user experience. See ISSUE 10: Is user + permission required to prompt for screen availability information?

    -
      -
    • -

      - Restrict the API to secure contexts. -

      -
      • -
    • -

      - Do not enable filtering based on capabilities (at all, or without - user consent). -

      -
      • -
    • -

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

      -
      • -
    -

    7.2 - Cross-origin presentations +

    7.2 + Cross-origin access

    The set of presentations for a user agent (or a user @@ -1526,17 +1511,11 @@

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

    -

    7.5 - Incognito mode +

    7.5 + Incognito mode and clearing of browsing data

    -

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

    The content displayed on the presenting context is different from the local one. In particular, if the user is logged in in both contexts, @@ -1545,16 +1524,22 @@

    7.5 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 set of presentations known to the user agent should be cleared when - the user requests to "clear browsing data." +

    + The spec should clarify what is to happen to the set of known + presentations in "incognito" (private browsing context) mode.

    -

    7.6 - Messaging channel +

    7.6 + Messaging between presentation sessions

    This spec will not mandate communication protocols, but it should set From c88ff79bb49ec5d2802b7dc83481f1bf0d7d416a Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Tue, 2 Jun 2015 14:59:56 -0700 Subject: [PATCH 4/5] More copy editing --- Overview.src.html | 79 ++++++++++++++++++++++++++--------------------- index.html | 79 ++++++++++++++++++++++++++--------------------- 2 files changed, 86 insertions(+), 72 deletions(-) diff --git a/Overview.src.html b/Overview.src.html index ee0a9a2..a2b96a1 100755 --- a/Overview.src.html +++ b/Overview.src.html @@ -1409,12 +1409,12 @@

    Personally identifiable information

    - The Presentation API 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. + 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 @@ -1425,9 +1425,9 @@

    presented?

    - Requiring user permission before disclosing the presence of a - presentation display is counter to the initial purpose of improving the - user experience. See ISSUE 10: Is user permission required to prompt for screen availability information?

    @@ -1435,26 +1435,31 @@

    Cross-origin access

    - The set of presentations for a user agent (or a user - profile within that user agent) may persist across browing sessions. + A presentation session is allowed to be accessed across + origins; the URL that started the presentation and the presentation ID + 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.

    - Cross-origin presentation sessions are allowed; the URL to present and - the presentation ID are the only information needed to join a session. - In other words, a presentation is not tied to a particular opening - origin. We could restrict the set of presentations per origin to ensure - that a third-party Web site cannot hijack a presentation it did not - create, for example by saying that D is represented as a set of tuples - (O, U, I, S) where O is the URL of the opening browsing context, and by - adjusting algorithms accordingly. + The security of the presentation ID prevents arbitrary pages from + connecting to an existing presentation. We could further restrict the + set of presentations per origin to ensure that an unwanted page cannot + hijack a presentation it did not create, for example by saying that D + is represented as a set of tuples (O, U, I, S) where O is the URL of + the opening browsing context, and by adjusting algorithms accordingly. + However, this would prevent controlling contexts from different domains + from connecting to a shared presentation resource.

    - The specification is also silent about exchanging information in that - set of presentations across user agents to authorize other devices to - join an existing presentation but that is envisioned (at least in the - charter of the group). + This specification does not prohibit a user agent from publishing + information about its set of presentations. The charter + 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. @@ -1463,27 +1468,29 @@

    Device Access

    - The presentation API abstracts away what "local" means for screens, - meaning that it exposes network-based screens as though they were local - screens. The Presentation API requires user permission to mitigate - issues that could arise here. + 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.

    Temporary identifiers and browser state

    - 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 to secure contexts. + 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. Again, one possible solution would be to restrict the API to + secure contexts.

    Incognito mode and clearing of browsing data

    - The content displayed on the presenting context is different from the - local one. In particular, if the user is logged in in both contexts, - then logs out on opening browsing context, she will not be + 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. @@ -1498,7 +1505,7 @@

    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.

    diff --git a/index.html b/index.html index 776ee60..159beb9 100644 --- a/index.html +++ b/index.html @@ -1446,12 +1446,12 @@

    7.1 Personally identifiable information

    - The Presentation API 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. + 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 @@ -1462,35 +1462,40 @@

    7.1 presented?

    - Requiring user permission before disclosing the presence of a - presentation display is counter to the initial purpose of improving the - user experience. See ISSUE 10: Is user + 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?

    7.2 Cross-origin access

    - The set of presentations for a user agent (or a user - profile within that user agent) may persist across browing sessions. + A presentation session is allowed to be accessed across + origins; the URL that started the presentation and the presentation ID + 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.

    - Cross-origin presentation sessions are allowed; the URL to present and - the presentation ID are the only information needed to join a session. - In other words, a presentation is not tied to a particular opening - origin. We could restrict the set of presentations per origin to ensure - that a third-party Web site cannot hijack a presentation it did not - create, for example by saying that D is represented as a set of tuples - (O, U, I, S) where O is the URL of the opening browsing context, and by - adjusting algorithms accordingly. + The security of the presentation ID prevents arbitrary pages from + connecting to an existing presentation. We could further restrict the + set of presentations per origin to ensure that an unwanted page cannot + hijack a presentation it did not create, for example by saying that D + is represented as a set of tuples (O, U, I, S) where O is the URL of + the opening browsing context, and by adjusting algorithms accordingly. + However, this would prevent controlling contexts from different domains + from connecting to a shared presentation resource.

    - The specification is also silent about exchanging information in that - set of presentations across user agents to authorize other devices to - join an existing presentation but that is envisioned (at least in the - charter of the group). + This specification does not prohibit a user agent from publishing + information about its set of presentations. The charter + 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. @@ -1499,27 +1504,29 @@

    7.3 Device Access

    - The presentation API abstracts away what "local" means for screens, - meaning that it exposes network-based screens as though they were local - screens. The Presentation API requires user permission to mitigate - issues that could arise here. + 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.

    7.4 Temporary identifiers and browser state

    - 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 to secure contexts. + 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. Again, one possible solution would be to restrict the API to + secure contexts.

    7.5 Incognito mode and clearing of browsing data

    - The content displayed on the presenting context is different from the - local one. In particular, if the user is logged in in both contexts, - then logs out on opening browsing context, she will not be + 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. @@ -1534,7 +1541,7 @@

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

    From 4b1cc8e6c4c8f12b05b579c1036bffb0783fbb00 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Wed, 3 Jun 2015 15:31:16 -0700 Subject: [PATCH 5/5] Incorporate tidoust suggestions --- Overview.src.html | 28 +++++++++++++--------------- index.html | 32 +++++++++++++++----------------- 2 files changed, 28 insertions(+), 32 deletions(-) diff --git a/Overview.src.html b/Overview.src.html index a2b96a1..18b808a 100755 --- a/Overview.src.html +++ b/Overview.src.html @@ -1436,24 +1436,20 @@

    A presentation session is allowed to be accessed across - origins; the URL that started the presentation and the presentation ID - 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. + 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.

    - The security of the presentation ID prevents arbitrary pages from - connecting to an existing presentation. We could further restrict the - set of presentations per origin to ensure that an unwanted page cannot - hijack a presentation it did not create, for example by saying that D - is represented as a set of tuples (O, U, I, S) where O is the URL of - the opening browsing context, and by adjusting algorithms accordingly. - However, this would prevent controlling contexts from different domains - from connecting to a shared presentation resource. + 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 charter + 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 @@ -1481,8 +1477,10 @@

    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. Again, one possible solution would be to restrict the API to - secure contexts. + page. +

    +

    + Should we restrict the API to some extent in non secure contexts?

    Incognito mode and clearing of browsing data diff --git a/index.html b/index.html index 159beb9..e8a8d54 100644 --- a/index.html +++ b/index.html @@ -77,8 +77,8 @@

    Presentation API

    -

    - Editor's Draft 2 June 2015 +

    + Editor's Draft 3 June 2015

    @@ -1472,24 +1472,20 @@

    7.2

    A presentation session is allowed to be accessed across - origins; the URL that started the presentation and the presentation ID - 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. + 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.

    - The security of the presentation ID prevents arbitrary pages from - connecting to an existing presentation. We could further restrict the - set of presentations per origin to ensure that an unwanted page cannot - hijack a presentation it did not create, for example by saying that D - is represented as a set of tuples (O, U, I, S) where O is the URL of - the opening browsing context, and by adjusting algorithms accordingly. - However, this would prevent controlling contexts from different domains - from connecting to a shared presentation resource. + 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 charter + 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 @@ -1517,8 +1513,10 @@

    7.4 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. Again, one possible solution would be to restrict the API to - secure contexts. + page. +

    +

    + Should we restrict the API to some extent in non secure contexts?

    7.5 Incognito mode and clearing of browsing data