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

Hi Francois,

Thank you very much for taking a stab at this after I neglected to do so :)

I will reply inline since that's easier to do in email than GitHub.  It
seems like there are several issues we need to discuss further before we
can come to some conclusions:

(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:
(2a) Capability filtering
(2b) 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

m.

On Mon, May 11, 2015 at 8:53 AM, François Daoust via GitHub <
sysbot+gh@w3.org> wrote:

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

It's unclear if determining the existence of any presentation screen (or
not) is a sufficient risk factor to tick this box.  Compared to NSD, for
example, which allows the page to read detailed device information
(including persistent identifiers) the Presentation API itself actually
reveals nothing about the target device.

* "The ability to introduce some functionality for which user
> permission will be required"
>

This is true.  At the worst, an active attacker against a page in an
insecure context would be able to issue spurious presentation requests; if
the user consents it would show content the user did not want.  However, if
the user agent allows the user a mechanism to stop the remote presentation,
it seems like the user could recover from this quite easily (similar to
closing an unwanted pop-up window).

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

Interesting.  The bar should be higher for getUserMedia since it handles
local camera input.


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

How would fingerprinting be implemented?  Currently there is one bit of
information returned and it is location-sensitive, so it may not be useful
for isolating a specific device or user.  I think we should provide an
algorithm if we make this claim.

I agree that if we add capability filtering more bits could be revealed.
Could we design the filtering algorithm to minimize this?  Perhaps we
restrict filtering to secure contexts?


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

I am concerned that this restricts a number of valid use cases.   If you
look at the top N news and content sites on the Web, few are currently
served over https.

e.g., these are all http:

www.cnn.com
www.netflix.com
www.hulu.com
*.blogspot.com
*.wordpress.com
www.spiegel.de
www.theguardian.com

Perhaps the W3C has an agenda to use new Web features as an incentive to
get content owners to move to https.  A the end of the day this a good
thing.  However, I worry it would make the Presentation API useless to a
large portion of the Web today, and could present a financial and political
barrier to entry for content owners in areas where certificate
infrastructure is not mature.


> * do not enable filtering based on capabilities (at all or without
> user consent)
>

This has been requested as a long-standing usability feature for the API.

https://github.com/w3c/presentation-api/issues/9

I would like us to find a way to preserve this feature in a way that is
privacy-preserving.


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

Hm, this is probably not what the user intends.   As a user I would find it
difficult to trust this feature if it offered me the option to present to
another screen, but didn't actually do that when used.


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

This is an interesting point that I hadn't considered.  We may want to
restrict the join behavior by origin (and/or to 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
>
>