Re: [presentation-api] Security and privacy evaluation and considerations

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](https://w3c.github.io/webappsec/specs/powerfulfeatures/). 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](http://w3c.github.io/mediacapture-main/getusermedia.html#enumerating-devices)
 and yet does not require a secure context (decision is [up to user 
agents](http://w3c.github.io/mediacapture-main/getusermedia.html#local-content)).


## Self-Review Questionnaire: Security and Privacy

Looking at [Self-Review Questionnaire: Security and 
Privacy](https://w3ctag.github.io/security-questionnaire/)

### 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](http://www.w3.org/2014/secondscreen/charter.html#scope)). 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.



-- 
GitHub Notif of comment by tidoust
See 
https://github.com/w3c/presentation-api/issues/45#issuecomment-100955052

Received on Monday, 11 May 2015 15:53:18 UTC