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.

[markafoltz]

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