Re: Edit new proposal for device enumeration into draft

On 17 April 2013 00:09, Stefan HÃ¥kansson LK
<> wrote:
> On 2013-04-16 18:45, Martin Thomson wrote:
>> Let's get this crystal clear.  The substance of the change is to:
>> a) provide a structure in place of an identifier, where the structure
>> includes id, label, kind, and facing attributes
>> b) provide access only to the id and kind attributes prior to
>> obtaining any form of user consent
>> c) provide access to id, kind AND label attributes (not facing) once
>> permissions for ANY source is granted
>> Your intent here is not to discuss Harald's suggested change to user
>> interface, but the above.  Is that correct?
> Yes, that is correct (basically what is between <proposal begins> and
> <proposal ends> in [1]).
> I did not read any suggested changes to the user interface in Harald
> proposal, only a discussion on how the suggested changes could be used when
> it comes to UI.

The UI changes* that Harald suggested was in the same email.  I say
"changes" because we have all had certain expectations about what a
user is asked based on what early implementations did that differs
from what Harald discussed.

The reason I raised this point is that I believe it to have a material
effect on how I answer this question.  While we might not make
decisions here about what user interfaces do and do not do, we do have
certain expectations about them.  The nature of user interaction is
key to understanding what the privacy implications of a choice are.
In many respects, the questions that a browser asks a user are the
most important thing in considering privacy implications.

In this case, if we expect that user interface will provide, as a
default choice, an option where the user grants access to all devices
(of a given type), then I don't believe that point (c) above is
necessary.  That option undermines an active choice that a user makes
- to select *only* a specific device.

I believe that the UI Harald describes is a worthwhile and valuable
thing to have.  As a consequence, the API proposal goes too far, but
only point (c) is excessive.  The extra information is valuable on
points (a) and (b).


Received on Wednesday, 17 April 2013 19:49:25 UTC