W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2015

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

From: Rigo Wenning <rigo@w3.org>
Date: Thu, 29 Oct 2015 06:30:49 +0100
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>, Mathieu Hofman <Mathieu.Hofman@citrix.com>, Harald Alvestrand <harald@alvestrand.no>, Nick Doty <npdoty@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <4579834.OP8E40JJLV@hegel>
On Thursday 29 October 2015 12:03:06 Martin Thomson wrote:
> Persistent for me is what Chrome does, or what Firefox does when you
> pick the "Always" option.  Maybe you could explain what you think
> persistent might mean other than that.

AFAI understood ekr's email, Chrome is defaulting to asking once and never ask 
again. Is this right? He wrote: "Chrome's UI of just giving persistent 
permissions without a user prompt".

If yes, then:

I now start to understand by persistent, you mean "forever" and there it is 
simply unjustifiable depending on your cultural standpoint IMHO. So this seems 
to really look like a cheap lock from the outside. Click - fatique can 
certainly not be used to justify defaulting user to allow mic and camera and 
to persist that forever. Such a default benefits certain actors from users not 
understanding what is going on, on purpose? Chrome will create damage to 
people with this. There is no doubt about it. Remember the school that gave 
its pupils laptops and used the remote controlled Apple chat and locate 
application to spy into the pupils bedrooms? You are about to broadly open 
that door. (I have a URI for this story somewhere)

If you take click-fatique seriously and not only as a pretext to justify what 
only makes sense from a certain commercial background, then you would offer :

 1/ Session
 2/ For this month
 3/ For the next six month

One click in six month to open mic and camera, given the potential for harm, 
is certainly not click-fatique and not justifiable by any means with the 
click-fatigue argument. 

BTW, if you look into RFC 7478, it says in its browser considerations: 
The browser is expected to provide mechanisms for getting user consent to use 
device resources such as camera and microphone.
Now tell me how is not asking the user getting you consent?

But furthermore it says: 
The browser is expected to provide mechanisms for informing the user that 
device resources such as camera and microphone are in use ("hot"). 

The browser must provide mechanisms for users to revise and even completely 
revoke consent to use device resources such as camera and microphone.
The parallels to the geolocation are more than tangible. You said this is more 
sensitive than geolocation? The abuse of geolocation systems has already 
killed people. We are not at this point here. But we still have to take risks 
seriously. User/Dev convenience considerations are in order, but must be on 
the height of that risk. Your click fatique argument isn't. 

If not: 



Received on Thursday, 29 October 2015 05:31:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:34 UTC