W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

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

From: Matt Hammond <Matt.Hammond@bbc.co.uk>
Date: Tue, 12 May 2015 17:14:53 +0000
To: "mark a. foltz" <mfoltz@google.com>
CC: François Daoust <fd@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Message-ID: <A00A53F5-E2D2-4BDB-B2CF-A3AD3D2EE2C1@bbc.co.uk>
Hi Mark, François,

See inline below...

| Matt Hammond
| Senior Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

> On 11 May 2015, at 23:31, mark a. foltz <mfoltz@google.com> wrote:
> 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.

This API, as currently proposed, does not even reveal if it is another device or actually just a part of the UA that the API is implemented in.

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

Stopping the presentation may be possible for some of the underlying implementations that provide only loose coupling between the two presentations. Stopping a running application is only optional functionality in DIAL for example. And HbbTV (which uses DIAL) also does not mandate it.

( section 6.4 in DIAL 1.7.1 at http://www.dial-multiscreen.org/dial-protocol-specification )

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

Again, if the UA provides local 2nd screen presentation capabilities, then it will not be possible to tell anything about devices on the network at all.

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

I would echo this.

A BBC use case might involve presenting our "iPlayer" video on demand service on the second screen. Inevitably differences in support for codecs, container formats, and content security functions may mean it is not possible to present our content on certain devices. In an ideal world, for us, we would determine all of these things to be certain our content will play on the other device to avoid presenting the option to the user and then the frustration of waiting for the presentation to load and initialise and then be told it is not going to work.

Of course "ideal" does not necessarily equate to privacy-preserving! So there is a balance of course.

Determining, for example, that the device supports HbbTV 2.0 goes a long way to providing confidence that the content will play since the HbbTV spec profiles a lot of detail in these areas. This leaks more "bits" but far fewer than NSD.

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



This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
Received on Tuesday, 12 May 2015 17:15:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 May 2015 17:15:27 UTC