W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2015

Proposed comments and qs on media capture streams

From: Christine Runnegar <runnegar@isoc.org>
Date: Wed, 1 Jul 2015 09:42:54 +0000
To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-ID: <A677FF6F-5D5D-405C-8471-AD8487C2AD35@isoc.org>
Dear colleagues,

As foreshadowed, here is a“write-up” of the discussion in the PING call last week. We realise that the conversation has already started with the Media Capture Task Force and that some of these comments may have already been addressed in the email exchange. Nonetheless, it would be useful to convey the discussion to the TF.

Is there anything we have omitted or anything that needs to be changed before we provide this note to the TF, apart from Nick’s additions?

Christine and Tara


Comments/Questions on Media Capture Streams – Privacy and Security Considerations

Our input is intended to help the Media Capture Task Force produce a more privacy-protecting API. 

(1) Consent/Permissions

Do permissions carry forward across sessions? Could there be a built-in sunset period for permissions?

It would be nice if there was a simple, user friendly way to revoke consent for a stream (especially audio/webcam streams). As it currently stands, once consent is granted there doesn't seem to be simple way to revoke it.

Section 10.6 states that persistent permissions must be be served over HTTPS and have no mixed content. It would be nice to see the "definition" of mixed content expanded to include the various issues mentioned in Bonneau's recent paper[1]. For example, if a site elects to use pinning, it should be considered to have mixed content if it loads non-pinned content.

[Note: This last point is perhaps more relevant to http://www.w3.org/TR/mixed-content/]

Why is there no requirement for user permission before a platform detects how many devices of each class are connected/available? Does the specification provide a mechanism to allow a user agent to deny access if an application is not in use?

(2) Identifiers

Is there a reason why the specification does not go the extra step of recommending that platforms not use persistent identifiers? What are the use cases for the use of persistent identifiers? Could identifiers change between sessions rather than simply treating identifiers as other persistent storages (e.g. cookies).  What protections are in place to ensure against leakage of identifiers?

(3) Indicators

Would it be possible to include mechanisms in the specification to display indicators beyond merely that the device is in use? (e.g. that a permission is persistent) Or, how is it expected that this will be handled?

[1] http://www.jbonneau.com/doc/KB15-NDSS-hsts_pinning_survey.pdf
Received on Wednesday, 1 July 2015 09:43:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:30 UTC