W3C

Presentation API

Editor's Draft 8 June 2015

This version:
http://w3c.github.io/presentation-api/
Latest published version:
http://www.w3.org/TR/presentation-api/
Latest editor's draft:
http://w3c.github.io/presentation-api/
Version history:
https://github.com/w3c/presentation-api/commits/
Participate:
Send feedback to public-secondscreen@w3.org or open a new issue (open issues)
Editors:
Mark Foltz, Google
Dominik Röttsches, Intel (until April 2015)

Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

Abstract

This specification defines an API to enable web content to access external presentation-type displays and use them for presenting web content.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was published by the Second Screen Presentation Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-secondscreen@w3.org (subscribe, archives). All comments are welcome.

This document is a work in progress and is subject to change. It builds on the final report (dated 18 November 2014) produced by the Second Screen Presentation Community Group. Algorithms have been drafted in particular. Most sections are still incomplete or underspecified. Privacy and security considerations are missing. A few open issues are noted inline. Please check the group's issue tracker on GitHub for an accurate list. Feedback from early experimentations is encouraged to allow the Second Screen Presentation Working Group to evolve the specification based on implementation issues.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This draft document may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 August 2014 W3C Process Document.

Table of Contents

  1. 1 Introduction
  2. 2 Use cases and requirements
  3. 3 Conformance
  4. 4 Terminology
  5. 5 Examples
    1. 5.1 Monitor availability of presentation displays example
    2. 5.2 Starting a new presentation session example
    3. 5.3 Joining a presentation session example
    4. 5.4 Handling an event for a UA initiated presentation session example
    5. 5.5 Monitor session's state and exchange data example
  6. 6 API
    1. 6.1 Common idioms
    2. 6.2 Interface PresentationSession
      1. 6.2.1 Sending a message through PresentationSession
      2. 6.2.2 Receiving a message through PresentationSession
      3. 6.2.3 Closing a PresentationSession
      4. 6.2.4 Event Handlers
    3. 6.3 Interface Availability
      1. 6.3.1 Monitoring the list of available presentation displays
    4. 6.4 Interface NavigatorPresentation
      1. 6.4.1 Starting a presentation session
      2. 6.4.2 Joining a presentation session
      3. 6.4.3 Establishing a presentation connection
      4. 6.4.4 Getting the presentation displays availability information
      5. 6.4.5 Event Handlers
    5. 6.5 Interface DefaultSessionStart
  7. 7 Security and privacy considerations
    1. 7.1 Personally identifiable information
    2. 7.2 Cross-origin access
    3. 7.3 Device Access
    4. 7.4 Temporary identifiers and browser state
    5. 7.5 Incognito mode and clearing of browsing data
    6. 7.6 Messaging between presentation sessions
  8. 8 References
  9. 9 Acknowledgments

1 Introduction

This section is non-normative.

This specification aims to make secondary displays such as a projector or a connected TV available to the web and takes into account displays that are attached using wired (HDMI, DVI or similar) and wireless technologies (MiraCast, Chromecast, DLNA, AirPlay or similar).

Devices with limited screen size lack the ability to show content to a larger audience, for example, a group of colleagues in a conference room, or friends and family at home. Showing content on an external large display helps to improve the perceived quality and impact of the presented content.

At its core, this specification enables an exchange of messages between a requesting page and a presentation page shown in the secondary display. How those messages are transmitted is left to the UA in order to allow for the use of display devices that can be attached to a wide variety of ways. For example, when a display device is attached using HDMI or MiraCast, the UA on the requesting device can render the requested presentation page in that same UA. Instead of displaying in a window on that same device, however, it can use whatever means the operating system provides for using those external displays. In that case, both the requesting page and the presentation page run on the requesting device and the operating system is used to route the presentation display output to the other display device. The second display device doesn't need to know anything about this spec or that the content involves HTML5.

Alternately, some types of external displays may be able to render HTML5 themselves and may have defined their way to send messages to that content. In that case, the UA on the requesting device would not need to render the presentation page itself. Instead, the UA could act as a proxy translating the request to show a page and the messages into the form understood by the display device.

This way of attaching to displays could be enhanced in the future by defining a standard protocol for delivering these types of messages that display devices could choose to implement.

The API defined here is intended to be used with UAs that attach to display devices through any of the above means.

2 Use cases and requirements

Use cases and requirements are captured in a separate Presentation API Use Cases and Requirements document.

3 Conformance

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and terminate these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc.) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

4 Terminology

The terms browsing context, event handlers, event handler event types, firing an event, navigate, queing a task are defined in [HTML5].

The term DOMException is defined in [DOM].

The term Promise is defined in [ES6]. The terms resolving a Promise, and rejecting a Promise are used as explained in [PROMGUIDE].

The term URL is defined in the WHATWG URL standard: [URL].

The terms ArrayBuffer, ArrayBufferView are defined in the Typed Array specification: [TYPEDARRAY].

The term Blob is defined in the File API specification: [FILEAPI].

This document provides interface definitions using the [WEBIDL] standard.

5 Examples

ISSUE 42: Make the Example section more concise

This section shows example codes that highlight the usage of main features of the Presentation API. In these examples, controller.html implements the controller and presentation.html implements the presentation. Both pages are served from the domain http://example.org (http://example.org/controller.html and http://example.org/presentation.html). Please refer to the comments in the code examples for further details.

5.1 Monitor availability of presentation displays example 

<!-- controller.html -->
<button id="castBtn" style="display: none;">Cast</button>
<script>
  // the cast button is visible if at least one presentation display is available
  var castBtn = document.getElementById("castBtn");
  // show or hide cast button depending on display availability
  var handleAvailabilityChange = function(available) {
    castBtn.style.display = available ? "inline" : "none";
  };
  // Promise is resolved as soon as the presentation display availability is known.
  navigator.presentation.getAvailability().then(function(availability) {
    // availability.value may be kept up-to-date by the UA as long as the availability
    // object is alive. It is advised for the web developers to discard the object
    // as soon as it's not needed.
    handleAvailabilityChange(availability.value);
    availability.onchange = function() { handleAvailabilityChange(this.value); };
  }.catch(function() {
    // Availability monitoring is not supported by the platform, discovery of presentation
    // displays will happen only after startSession() call. Pretend the devices are
    // available for simplicity (one could implement the third state for the button).
    handleAvailabilityChange(true);
  });
</script>

5.2 Starting a new presentation session example 

<!-- controller.html -->
<script>
  // it is also possible to use relative presentation URL e.g. "presentation.html"
  var presUrl = "http://example.com/presentation.html";
  // create random presId
  var presId = Math.random().toFixed(6).substr(2);
  // Start new session. presId is optional.
  navigator.presentation.startSession(presUrl, presId)
    // the new started session will be passed to setSession on success
    .then(setSession)
    // user cancels the selection dialog or an error is occurred
    .catch(endSession);
</script>

5.3 Joining a presentation session example 

<!-- controller.html -->
<script>
  // read presId from localStorage if exists
  var presId = localStorage && localStorage["presId"] || null;
  // presId is mandatory for joinSession.
  presId && navigator.presentation.joinSession(presUrl, presId)
    // The joined session will be passed to setSession on success
    .then(setSession)
    // no session found for presUrl and presId or an error is occurred
    .catch(endSession);
</script>

5.4 Handling an event for a UA initiated presentation session example 

<!-- controller.html -->
<head>
  <!-- the link element with rel='default-presentation' allows the page to specify -->
  <!-- the presentation URL and id for when the UA initiates a presentation session -->
  <link href="http://example.com/presentation.html" rel="default-presentation" id="ABCD1234" >
</head>
<script>
  navigator.presentation.ondefaultsessionstart = function (evt) {
    setSession(evt.session);
  };
</script>

5.5 Monitor session's state and exchange data example 

<!-- controller.html -->
<script>
  var session;
  var setSession = function (theSession) {
    // end existing session, if any
    endSession();
    // set the new session
    session = theSession;
    if (session) {
      // save presId in localStorage
      localStorage && (localStorage["presId"] = session.id);
      // monitor session's state
      session.onstatechange = function () {
        if (this == session && this.state == "disconnected")
          endSession();
      };
      // register message handler
      session.onmessage = function (evt) {
        console.log("receive message", evt.data);
      };
      // send message to presentation page
      session.send("say hello");
    }
  };
  var endSession = function () {
    // close old session if exists
    session && session.close();
    // remove old presId from localStorage if exists
    localStorage && delete localStorage["presId"];
  };
</script>

<!-- presentation.html -->
<script>
  var session = navigator.presentation.session;
  session.onstatechange = function () {
    // session.state is either 'connected' or 'disconnected'
    console.log("session's state is now", session.state);
  };
  session.onmessage = function (evt) {
    if (evt.data == "say hello")
      session.send("hello");
  };
</script>

6 API

6.1 Common idioms

A presentation display refers to an external screen available to the user agent via an implementation specific connection technology.

A presentation session is an object relating an controlling browsing context to its presenting browsing context and enables two-way-messaging between them. Each presentation session has a presentation session state, a presentation session identifier to distinguish it from other presentation sessions, and a presentation session URL that is a URL used to create or resume the presentation session.

A controlling browsing context (or controller for short) is a browsing context that has initiated or resumed a presentation session by calling startSession() or joinSession() or received a presentation session via ondefaultsessionstart event.

The presenting browsing context (or presentation for short) is the browsing context responsible for rendering to a presentation display. A presenting browsing context can reside in the same user agent as the controlling browsing context or a different one.

The set of presentations, initially empty, contains the presentation sessions created by the controlling browsing contexts for the user agent (or a specific user profile within the user agent). The set of presentations is represented by a list of tuples, where each tuple consists of a presentation session URL, a presentation session identifier, and the presentation session itself. The presentation session URL and presentation session identifier uniquely identify the presentation session.

6.2 Interface PresentationSession

Each presentation session is represented by a PresentationSession object. 

enum PresentationSessionState { "connected", "disconnected" /*, "resumed" */ };
enum BinaryType { "blob", "arraybuffer" };

interface PresentationSession : EventTarget {
  readonly DOMString? id;
  readonly attribute PresentationSessionState state;
  void close();
  attribute EventHandler onstatechange;

  // Communication
  attribute BinaryType binaryType;
  EventHandler onmessage;
  void send (DOMString message);
  void send (Blob data);
  void send (ArrayBuffer data);
  void send (ArrayBufferView data);
};

The id attribute specifies the presentation session's presentation session identifier. The value must consists of alphanumeric ASCII characters and be unique within the set of presentations.

The state attribute represents the presentation session's current state. It can take one of the values of PresentationSessionState depending on connection state.

When the send() method is called on a PresentationSession object with a message, the user agent must run the algorithm to send a message through a PresentationSession.

When the close() method is called on a PresentationSession, the user agent must run the algorithm to close a presentation session with PresentationSession.

ISSUE 34: Specify the presentation initialization algorithm

ISSUE 46: Define send behavior

6.2.1 Sending a message through PresentationSession

Presentation API does not mandate a specific protocol for the connection between the controlling browsing context and the presenting browsing context except that for multiple calls to send it has to be ensured that messages are delivered to the other end in sequence.

Let presentation message data be the payload data to be transmitted between two browsing contexts. Let presentation message type be the type of that data, one of text and binary.

When the user agent is to send a message through a PresentationSession S, it must run the following steps:

  1. If the state property of PresentationSession is "disconnected", throw an InvalidStateError exception.
  2. Let presentation message type messageType be binary if data is one of ArrayBuffer or Blob. Let messageType be text if data is of type DOMString)
  3. Assign the destination browsing context as follows:
    1. Let the the destination browsing context be the controlling browsing context if send is called in the presenting browsing context.
    2. Let destination browsing context be the presenting browsing context if send is called from the opening browsing context.
  4. Using an implementation specific mechanism, transmit the contents of the data argument as presentation message data and presentation message type messageType to the destination browsing context side.

6.2.2 Receiving a message through PresentationSession

When the user agent has received a transmission from the remote side consisting of presentation message data and presentation message type, it must run the following steps:

  1. If the state property of PresentationSession is "disconnected", abort these steps.
  2. Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
  3. Initialize the event's data attribute as follows:
    1. If the presentation message type is text, then initialize event's data attribute to the contents of presentation message data of type DOMString.
    2. If the presentation message type is binary, and binaryType is set to blob, then initialise event's data attribute to a new Blob object that represents presentation message data as its raw data.
    3. If the presentation message type is binary, and binaryType is set to arraybuffer, then initialise event's data attribute to a new ArrayBuffer object whose contents are presentation message data.
  4. Queue a task to fire event at PresentationSession.

ISSUE 63: Define (cross) origin relationship between opener and presenting page

6.2.3 Closing a PresentationSession

When the user agent is to close a presentation session using session, it must run the following steps:

  1. If presentation session state of session is not connected, then abort these steps.
  2. Set presentation session state of session to disconnected.
  3. Queue a task to run the following steps in order:
    1. For each known session in the set of presentations:
      1. If the presentation session identifier of known session and session are equal, run the following steps:
        1. Queue a task to fire an event named statechange at session.

ISSUE 35: Refine how to do session teardown/disconnect/closing

6.2.4 Event Handlers

The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by objects implementing the PresentationSession interface:

Event handler Event handler event type
onmessage message
onstatechange statechange

6.3 Interface Availability 

interface Availability : EventTarget {
  readonly attribute boolean value;
  attribute EventHandler onchange;  
};

The change event is fired during the execution of the monitoring presentation display availability algorithm when the presentation display availability changes. It is fired at the Availability object, using the ChangeEvent interface. The Availability object's value attribute is updated to the boolean value that the algorithm determined.

In order to satisfy the power saving non-functional requirement, the user agent must keep track of the number of Availability objects requested through the getAvailability() method. The UA may also keep track of whether the page holding the Availability object is in the foreground. 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 alive Availability objects, the user agent must also keep the list up to date by running the algorithm for monitoring the list of available presentation displays.

The user agent might not support continuous availability monitoring due to platform or power consumption restrictions, for example. In this case the Promise returned by getAvailability() is rejected and the algorithm for monitoring the list of available presentation displays will only run as part of the session start algorithm.

6.3.1 Monitoring the list of available presentation displays

When the user agent is to monitor the list of available presentation displays, it must run the following steps:

While there are alive Availability objects, the user agent should continuously keep track of the list of available presentation displays and repeat the following steps:

  1. Queue a task to retrieve the list of currently available presentation displays and let newDisplays be this list.
  2. Wait for the completion of that task.
  3. If the list of available presentation displays is empty and newDisplays is not empty, then for each alive Availability object:
    1. Set the object's value property to true.
    2. Queue a task to fire an event named change at the object.
  4. If the list of available presentation displays is not empty and newDisplays is empty, then for each alive Availability object:
    1. Set the object's value property to false.
    2. Queue a task to fire an event named change at the object.
  5. Set the list of available presentation displays to the value of newDisplays.

The mechanism used to monitor presention displays availability is left to the user agent. The UA may choose to monitor the availability of presentation displays even when there are no Availability objects.

When the user agent is to cancel monitoring the list of available presentation displays, it must run the following steps:

6.4 Interface NavigatorPresentation 

partial interface Navigator {
  readonly attribute NavigatorPresentation presentation;
};

The presentation attribute is used to retrieve an instance of the NavigatorPresentation interface, the main interface of Presentation API. 

interface NavigatorPresentation : EventTarget {
  readonly attribute PresentationSession? session;
  Promise<PresentationSession> startSession(DOMString url, DOMString? presentationId);
  Promise<PresentationSession> joinSession(DOMString url, DOMString? presentationId);
  Promise<Availability> getAvailability();
  attribute EventHandler ondefaultsessionstart;
};

ISSUE 52: Specify the NavigatorPresentation.session attribute and its related algorithms

6.4.1 Starting a presentation session

When the startSession(presentationUrl, presentationId) method is called, the user agent must run the following steps:

Input
presentationUrl, the URL of the document to be presented
presentationId, an optional identifier for the presentation
Output
P, a Promise
  1. Let P be a new Promise.
  2. Return P.
  3. If the user agent does not monitor presentation display availability, run the following steps:
    1. Monitor presentation display availability.
    2. Wait until the algorithm completes.
  4. If the list of available presentation displays is empty, then:
    1. Reject P with a DOMException named "NotFoundError".
    2. Abort all remaining steps.
  5. Queue a task T to request user permission for the use of a presentation display and selection of one presentation display.
    1. If T completes with the user granting permission to use a display, run the following steps:
      1. If presentationId is not undefined, assign I to that that presentationId.
      2. If presentationId is undefined, let I be a random alphanumeric value of at least 16 characters drawn from the characters [A-Za-z0-9].
      3. Create a new PresentationSession S.
      4. Set S.id to I, and set S.state to disconnected.
      5. Queue a task C to create a new browsing context on the user-selected presentation display and navigate to presentationUrl in it.
        1. If C completes successfully, run the following steps:
          1. Add (presentationUrl, S.id, S) to D.
          2. Resolve P with S.
          3. Establish a presentation connection with S.
        2. If C fails, run the following steps:
          1. Reject P with a DOMException named "OperationError".
    2. If T completes with the user denying permission, run the following steps:
      1. Reject P with a DOMException named "AbortError".

The details of implementing the permission request and display selection are left to the user agent; for example it may show the user a dialog and allow the user to select an available display (granting permission), or cancel the selection (denying permission).

The presentationUrl should name a resource accessible to the local or a remote user agent. This specification defines behavior for presentationUrl using the http or https schemes; behavior for other schemes is not defined by this specification.

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 getAvailability().

6.4.2 Joining a presentation session

When the joinSession(presentationUrl, presentationId) method is called, the user agent must run the following steps:

Input
presentationUrl, the URL of the document being presented
presentationId, the identifier for the presentation
Output
P, a Promise
  1. Let P be a new Promise.
  2. Return P.
  3. Let D be the set of presentations for the user agent.
  4. Queue a task T to run the following steps in order:
    1. For each presentation (U, I, S) in D,
      1. Let u equal U, i equal I, and s equal S.
      2. If u is equal to presentationUrl and i is equal to presentationId, run the following steps:
        1. Resolve P with S.
        2. Establish a presentation connection with S.
        3. Abort the remaining steps of T.
    2. Reject P with a DOMException named "NotFoundError".

ISSUE: If no matching presentation is found, we could leave the Promise pending in case a matching presentation is started in the future.

6.4.3 Establishing a presentation connection

When the user agent is to establish a presentation connection using a presentation session S, it must run the following steps:

  1. If S.state is connected, then:
    1. Abort all remaining steps.
  2. Queue a task T to connect S to the document that is presenting presentationUrl.
  3. If T completes successfully, run the following steps:
    1. Set S.state to connected.
    2. Let D be the set of presentations for the user agent.
    3. Queue a task T to run the following steps in order:
      1. For each presentation (U, I, S') in D,
        1. Let i equal I, and s equal S'.
        2. If i is equal to S.id, run the following steps:
          1. Queue a task to fire an event named statechange at s.

The mechanism that is used to present on the remote display and connect the controlling browsing context with the presented document is an implementation choice of the user agent. The connection must provide a two-way messaging abstraction capable of carrying DOMString payloads in a reliable and in-order fashion as described in the Send Message and Receive Message steps below.

If T does not complete successfully, the user agent may choose to re-execute the Presentation Connection algorithm at a later time.

ISSUE: Do we want to notify the caller of a failure to connect, i.e. with an "error" onstatechange?

ISSUE: Do we want to pass the new state as a property of the statechange event?

6.4.4 Getting the presentation displays availability information

When the getAvailability() method is called, the user agent must run the following steps:

Output
P, a Promise
  1. Let P be a new Promise.
  2. Return P.
  3. If the user agent doesn't support continuous monitoring of the presentation display availability, then:
    1. Reject P.
    2. Abort all the remaining steps.
  4. If the user agent does not monitor presentation display availability, run the following steps:
    1. Monitor presentation display availability.
    2. Wait until the algorithm completes.
  5. Resolve P with a Availability object with the value property set to false if the list of the available displays is empty or true otherwise.
  6. If possible, continue running the algorithm for monitor presentation display availability as long as the returned Availability object is kept alive.

6.4.5 Event Handlers

The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by objects implementing the NavigatorPresentation interface:

Event handler Event handler event type
ondefaultsessionstart defaultsessionstart

6.5 Interface DefaultSessionStart 

[Constructor(DOMString type, optional DefaultSessionStartEventInit eventInitDict)]
interface DefaultSessionStartEvent : Event {
  readonly attribute PresentationSession session;
};

dictionary DefaultSessionStartEventInit : EventInit {
  PresentationSession session;
};

An event named defaultsessionstart is fired when the UA initiates a presentation on behalf of the page. It is fired at the NavigatorPresentation object, using the DefaultSessionStartEvent interface, with the session attribute set to the PresentationSession object provided by the UA.

7 Security and privacy considerations

ISSUE 45: Security and privacy considerations section

7.1 Personally identifiable information

The change event fired on the Availability object 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?

7.2 Cross-origin access

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.

7.3 Device Access

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

7.5 Incognito mode and clearing of browsing data

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.

7.6 Messaging between presentation sessions

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 References

[DOM]
DOM, Anne van Kesteren, Aryeh Gregor and Ms2ger. WHATWG.
[ES6]
ECMA-262 6th Edition / Draft. ECMA / Jason Orendorff.
[FILEAPI]
File API, Arun Ranganathan and Jonas Sicking. W3C.
[HTML5]
HTML5, Robin Berjon, Steve Faulkner, Travis Leithead et al.. W3C.
[PROMGUIDE]
Writing Promise-Using Specifications, Domenic Denicola. W3C.
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. IETF.
[TYPEDARRAY]
Typed Array, David Herman and Kenneth Russel. Khronos.
[URL]
URL, Anne van Kesteren. WHATWG.
[WEBIDL]
Web IDL, Cameron McCormack. W3C.

9 Acknowledgments

Thanks to Wayne Carr, Louay Bassbouss, Anssi Kostiainen, 闵洪波 (Hongbo Min), Anton Vayvod, and Mark Foltz for help with editing, reviews and feedback to this draft.