- From: Robin Wilton <wilton@isoc.org>
- Date: Wed, 1 Jul 2015 11:31:39 +0000
- To: Christine Runnegar <runnegar@isoc.org>
- CC: "public-privacy mailing list) (W3C" <public-privacy@w3.org>
- Message-ID: <62B00344-1956-4DEA-A8D5-9689AEBC7903@isoc.org>
Thanks Christine - I think that’s a good summary. FWIW, having watched the to-and-fro about persistent identifiers, I am none the wiser as to whether the conclusion was to do anything about them or not. It seemed to me that Eric R was not inclined to do so, but his justification was opaque. In your view, is there a clear position on this question currently, or is it something that would benefit from being raised again explicitly? Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 1 Jul 2015, at 10:42, Christine Runnegar <runnegar@isoc.org> wrote: > 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 11:32:11 UTC