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

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

From: Francois Daoust <fd@w3.org>
Date: Tue, 12 May 2015 17:36:40 +0200
Message-ID: <55521E08.7050403@w3.org>
To: "mark a. foltz" <mfoltz@google.com>
CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Hi Mark,

A few comments inline,

On 2015-05-12 00:31, mark a. foltz wrote:
> Hi Francois,
>
> Thank you very much for taking a stab at this after I neglected to do so :)

Ah, I thought you would rather complain that I should have done that way 
before :)

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

At first glance, I see no compelling reason to have a blanket 
"restricted to secure contexts" requirement for the Presentation API, so 
I think we should leave that question open and proceed as if the answer 
was "no". It's easy to add that restriction later on, much harder to 
drop it if it's already there (as the other questions would then come 
back to the table).

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

Nice summary!

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

Surprisingly perhaps but also closer to our case, getUserMedia also lets 
one enumerate *output* devices (restricted to audio devices for the time 
being) [1]. This is used in combination with the Audio Output Devices 
API [2]. We should keep these specifications on our radar when it comes 
to presenting audio/video content, actually, but I'll raise that in the 
appropriate issue.

[1] http://w3c.github.io/mediacapture-main/#enumerating-devices
[2] http://w3c.github.io/mediacapture-output/


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

Right, I did not have more in mind than "one bit of location-sensitive 
information".


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

It might be useful to precise filtering needs as well. For instance, are 
most filtering needs around media use cases? If so, we may not need to 
add capability filtering for the generic Presentation API, "only" for 
the mechanism that we will use for audio/video presentations. I think 
the Web Audio Working Group expressed similar needs for the enumeration 
of media devices in getUserMedia in particular (although the spec does 
not define any such filtering mechanism yet).

>
>
>     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 <http://www.cnn.com>
> www.netflix.com <http://www.netflix.com>
> www.hulu.com <http://www.hulu.com>
> *.blogspot.com <http://blogspot.com>
> *.wordpress.com <http://wordpress.com>
> www.spiegel.de <http://www.spiegel.de>
> www.theguardian.com <http://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.

The agenda at W3C depends on what members want and they have opposite 
views from time to time... It is true that there exists an incentive to 
move powerful features to HTTPS-only. The evaluation of whether we think 
of the Presentation API as a powerful feature that should be entirely 
restricted to a secure context is up to the working group. I would 
personally prefer the Presentation API not to require secure contexts as 
well.

Thanks,
Francois.
Received on Tuesday, 12 May 2015 15:36:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 May 2015 15:36:52 UTC