Security and privacy considerations

[anssiko]

We should complete the Security and privacy considerations section to the Presentation API once we're better aware of the threats.

The spec has been evaluated against Self-Review Questionnaire: Security and Privacy, with results documented in this issue. Furthermore, the Privacy Interest Group (PING) has produced documentation that may be helpful, namely Fingerprinting Guidance for Web Specification Authors and Privacy Considerations for Web Protocols. The Web Security IG review and PING review of the specification have been initiated. This sections should be crafted based on feedback from the respective reviews.

[anssiko]

https://lists.w3.org/Archives/Public/public-secondscreen/2015Jan/0037.html

[anssiko]

We should evaluate the Presentation API using the Strawman Self-Review Questionnaire: Security and Privacy kindly authored by @mikewest. It is preferred to do this sooner rather than later, and for example, present and discuss the results of the evaluation at F2F.

All - please let us know if you'd like to help evaluate the spec using the questionnaire 1.

[tidoust]

I'm assigning the issue to myself as no one seems to have jumped on it. I do not claim to have any particular expertise on security and privacy issues but I'll try to follow the existing guidelines and questionnaire, and to use common sense. I'll share evaluation results before the F2F.

[anssiko]

Depending on the results of the security and privacy evaluation, the Privileged Contexts [1] spec may become relevant:

[The Privileged Contexts] specification provides guidelines for user agent implementors and spec authors for implementing features whose properties dictate that they be exposed to the web only within a trustworthy environment.

It seems the Presentation API ticks some of the boxes in Should [insert feature here] require a privileged context? [2]:

• The feature provides access to or information about other devices a user has access to.
• The feature introduces some functionality for which user permission will be required.

[1] https://w3c.github.io/webappsec/specs/powerfulfeatures/
[2] https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege

[tidoust]

What follows is a simple and naïve evaluation of the Presentation API following existing security and privacy guidelines. I tried to link to the relevant issue on GitHub each time, or propose initial thoughts. I'll try to come up with more concrete suggestions but thought this would already be a good start for discussions. Please jump in if I forgot something or got something wrong.

Secure Contexts

Looking at Secure Contexts. In the list of risks associated with insecure contexts, the Presentation API ticks the boxes:

• "The ability to access information about other devices a user has access to": the Presentation API leaks the fact that there are devices available. More information may be leaked in the future if devices can be filtered according to capability constraints though
• "The ability to introduce some functionality for which user permission will be required"

It is worth noting that the Media Capture and Streams spec requires users permission, allows one to enumerate local media devices and yet does not require a secure context (decision is up to user agents).

Self-Review Questionnaire: Security and Privacy

Looking at Self-Review Questionnaire: Security and Privacy

Does this specification deal with 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 #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.

Does this specification deal with high-value data?

No.

Does this specification introduce new state for an origin that persists across browsing sessions?

The set of presentations that are currently known to the user agent may persist across browing sessions.

If we enable cross-origin presentation sessions (tracked in #63 Define (cross) origin relationship between opener and presenting page), the URL to present and the presentation ID are the only information needed to join a session. In other words, a presentation would then not be tied to a particular opening origin. We could restrict the set of presentations that are currently known to the user agent 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). The Security and Privacy Considerations section should provide informative guidance as to what constitutes a reasonable context for a Web page to become authorized to control a presentation session.

Does this specification expose persistent, cross-origin state to the web?

See above discussion on fingerprinting.

Does this specification expose any other data to an origin that it doesn’t currently have access to?

No.

Does this specification enable new script execution/loading mechanisms?

No.

Does this specification allow an origin access to a user’s location?

No.

Does this specification allow an origin access to sensors on a user’s device?

No.

Does this specification allow an origin access to aspects of a user’s local computing environment?

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

Does this specification allow an origin access to other devices?

Yes but note that exposed devices that are able to render HTML content are already exposed to the web, so the Presentation API does not expose devices to the web that aren't created with the web in mind.

This may need to be revisited depending on the outcomes of the discussions in #76 URL schemes supported in presentation API, since custom schemes may mean exposing devices that aren't created with the web in mind.

Does this specification allow an origin some measure of control over a user agent’s native UI?

It might if we allow the Web application to inject additional cloud-based screens to the list assembled by the user agent's native UI (see #61 Add facility for the opening page to add cloud paired screens as presentation targets). If we do allow that, the spec should clearly label these screens as belonging to the site (as noted in the description of the issue)

Does this specification expose temporary identifiers to the web?

Not sure what "the web" cover in that question, but note that 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.

Does this specification distinguish between behavior in first-party and third-party contexts?

Not clear whether that applies to the Presentation API

How should this specification work in the context of a user agent’s "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 spec should also probaby note in the "Security and privacy considerations" section that 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.

This is being tracked by #14 Define user agent context for rendering the presentation.

Does this specification persist data to a user’s local device?

Yes, the set of presentations known to the user agent should be cleared when the user requests to "clear browsing data" in particular.

Does this specification have a "Security Considerations" and "Privacy Considerations" section?

Yes. That's the whole purpose of the exercise.

Does this specification allow downgrading default security characteristics?

No

Miscellaneous

Messaging channel

See #80 Define security requirements for messaging channel between secure origins.

While the spec will not mandate communication protocols, it should set some guarantees of message confidentiality and authenticity.

[anssiko]

Thanks @tidoust, this is very helpful. Since the specific issues are conveniently cross-referenced from the questionnaire, we should (also) discuss the security and privacy implications in the respective issues/F2F slots where it makes sense.

[mfoltzgoogle]

In the corresponding thread on public-webscreens, I summarized the open issues around security and privacy as follows:

1. Do the risk factors vs. utility/usability warrant restriction of the API as a whole to secure contexts?
2. Same question for specific features: e.g. capability filtering, and joining of existing sessions
3. Which features require user permission?
4. What are the fingerprinting risks from the API? How can they be mitigated?
5. Security requirements on the communication channel for 2-UA use
6. Behavior in incognito contexts
7. Behavior when the user clears browsing data

[anssiko]

ACTION: @mfoltzgoogle to see if there is any data that can be shared about initiating [a user's action] from the browser or the page. [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action04]

• Closed with https://lists.w3.org/Archives/Public/public-secondscreen/2015Jun/0044.html

[anssiko]

ACTION: @avayvod to explore browser initiated presentation via declarative approach [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action05]

[anssiko]

ACTION: @tidoust to look into WebRTC WG's Audio Output Devices API and its reuse in the context of the Presentation API [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action06]

ACTION: @tidoust to look into "incognito" requirements on the spec [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action07]

• Closed with https://lists.w3.org/Archives/Public/public-secondscreen/2015Jun/0049.html

ACTION: @tidoust tidoust to seek review from PING and Web Security IG when the spec has adapted F2F changes [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action08]

ACTION: @mfoltzgoogle to prime the Security and Privacy Considerations section with content from #45 [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action09]

• Closed with Issue #45: Security and Privacy Considerations #104

[tidoust]

Ref. my action to look into other specs that have "incognito" requirements, I may have been a bit optimistic... I checked and asked around but could not find a specification that imposes additional requirements for the incognito mode. Which does not mean that we should not.

In practice, the Technical Architecture Group (TAG) that develops the Private mode browsing spec and with the Privacy Interest Group (PING) are interested in seeing specifications that use this concept. We should get in touch with both of them to seek feedback and advice once we have some initial wording.

[anssiko]

[Since we didn't use a purpose built action tracker and just piggybacked on the GH issues for tracking F2F actions, I took the liberty to just amend the corresponding comment above.]

Closed actions from the F2F:

ACTION: @mfoltzgoogle to see if there is any data that can be shared about initiating [a user's action] from the browser or the page. [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action04]

@mfoltzgoogle Thanks for the data. In the light of this, I suggest the group attempts to accommodate both the use cases as proposed.

ACTION: @tidoust to look into "incognito" requirements on the spec [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action07]

@tidoust Thanks for looking into this. For the record, the Private Mode Browsing spec is currently very much work-in-progress. The "incognito" requirements should be brought up during the TAG review as they may raise the priority of the said spec, volunteers.

ACTION: @mfoltzgoogle to prime the Security and Privacy Considerations section with content from #45 [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action09]

Closed with #104

[mfoltzgoogle]

Assuming we plan to have feedback from the PING in time for our F2F, I propose we revisit open issues from the security and privacy considerations section.

[tidoust]

Note feedback from TAG, notably on the Private Browsing Mode, in:

[[
To my knowledge we don't have a concrete plan for the Private Mode Browsing release. In general a "private mode" would seek to limit the amount of fingerprinting and or state that is maintained between and during navigations. Several aspects of the Presentation API require presentation session objects to be consistent on return from a navigation, and a private browsing mode might of necessity destroy the consistency between these sessions for privacy reasons. It might also chose to limit the ability to launch new browsing sessions. In general, we cannot clearly define what the private browsing mode will do at this time, but requiring it as a prerequisit or dependency to the availablility of the presentation API seems to be a non-starter.
]]
https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md

[anssiko]

Current status re privacy (TL;DR: the PING privacy review results are out):

• The Presentation API privacy considerations this group had initially identified were discussed on the PING call 13 Aug 2015. Please see the informal chairs summary of the call.
• There was an action from the call on Greg Norcie of PING to conduct a more thorough privacy review on the Presentation API. The results of the privacy review are now available.

We should review the results at our upcoming F2F and see how to craft the privacy and security section in the spec (the privacy part of it) based on this guidance. Furthermore, we should evaluate whether these review results motivate any changes to the other sections of the specification.

[sicking]

My main privacy concern with the API as it is currently defined, is that it enables probing which DIAL applications the user has installed on their TV. Especially the fact that this can be done without user interaction is concerning.

My main concern here isn't the fingerprinting issue, but rather that this might leak personal information about the user.

[anssiko]

Good catch. We should note the probing issue in the Security and privacy considerations section. This was not touched upon by PING, likely since the spec does not mention DIAL explicitly. We could also consider amending the respective algorithms with a note. E.g. in Monitor the list of available presentation displays:

NOTE
The mechanism used to monitor presentation displays availability and determine the compatibility of a presentation display with a given URL is left to the user agent.

This could be amended with text that makes it clear that the given URL may reveal information about the user's system, e.g. apps installed to handle the specifically crafted URL. Also note the UAs may implement measures to mitigate that and how. If this warrants changes to the algorithm, we should look at that too.

[tidoust]

See relevant discussions at TPAC F2F during TAG review, privacy review, security review:
http://www.w3.org/2015/10/29-webscreens-minutes.html#item02
http://www.w3.org/2015/10/29-webscreens-minutes.html#item03
http://www.w3.org/2015/10/29-webscreens-minutes.html#item06

ACTION: Mark to define a presenting browsing context that sets an empty initial state. Including storage and permissions.
ACTION: Mark to reach out to Permission API editors to see how it interacts with Availability
ACTION: Francois to contact PING to better explain the Presentation API and that audio/video will be done in a separate specification
ACTION: mfoltzgoogle to propose wording to prevent mixing HTTP and HTTPS
ACTION: Francois to send self-review security evaluation to WebAppSec WG for review.

[tidoust]

@mfoltzgoogle and myself discussed privacy implications of the Presentation API with PING last week. Christine will send out an email summary. Draft minutes are available at:
http://www.w3.org/2015/12/03-privacy-minutes.html#item02

The gist of the feedback is that the Second Screen WG is doing well with regards to privacy, having already considered the main privacy issues that the specification raises. The privacy evaluation in itself does not reveal new major issues, although we may of course want to consider a couple of notes in the spec to raise awareness on some of the points. The focus on audio/video streaming was intended: streaming audio/video to a remote device is privacy-sensitive, the user needs to be in control (she is in control with the Presentation API through the selection of the second screen and the fact that the user is asked for each new request).

That said, Nick raised a couple of new comments during the discussion that I do not remember having been addressed:

1. the need to ensure users can always tell which origin is being presented (now tracked in issue Implementation guideline: users should have a way to know which origin is being presented at any time  #223)
2. possible privacy-related implications of multi-user scenarios (now tracked in issue Think more about privacy implications in multi-user scenarios #224)

See specific issue for details and discussions.

[mfoltzgoogle]

Status:

• I filed Is a new Permission type required for presentation display availability? #255 and CCed the editors of the Permissions API to follow up on action Moving demo to its own repository. #2 above.
• Outstanding PR Additional UI guidelines for user agents #251 addresses Implementation guideline: users should have a way to know which origin is being presented at any time  #223 and Think more about privacy implications in multi-user scenarios #224 raised by the recent PING review.

I see there are a couple of comments above regarding DIAL URLs and one inline issue, let's address these and then I will move to close this, assuming no outstanding comments.

• Security and privacy considerations #45 (comment)
• Security and privacy considerations #45 (comment)
• The spec should clarify what is to happen to the set of known presentations in "incognito" (private browsing context) mode.