W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Re: Agenda - Distributed Meeting 2010-06-02

From: James Salsman <jsalsman@talknicer.com>
Date: Wed, 9 Jun 2010 05:05:08 -0700
Message-ID: <AANLkTin-pvuUfPNsIiA2nLmUVRcn3vd5CX_Axc5BOCGO@mail.gmail.com>
To: Frederick.Hirsch@nokia.com, public-device-apis@w3.org
On Wed, Jun 9, 2010 at 2:34 AM,  <Frederick.Hirsch@nokia.com> wrote:
> For agenda item #4, policy, please add
>
> Agree to update Policy Requirements as in proposal?
>
> Please see http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0065.html

Frederik, at http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0065/Proposal.html#prompts
it says, "Prompts should be eliminated whenever possible."

What is the alternative to prompts?  A set of defaults and a control
panel for changing them? In any case, that should probably be spelled
out.  I can not agree to suggesting that user shouldn't be prompted
each time a remote service uses a microphone, camera, file, contact
database, or other local resource, if they haven't already given
permanent permission for that access.  I am not opposed to the idea of
a security policy containing defaults with that permanent permission
in the case, for example, of corporate access to a contacts database
on corporate-issued devices.

I would much prefer to have an opt-in system, where the user is
presented with the choice to either allow or deny access to resources
when those accesses are attempted, with the user able to decide
whether to remember their choice for accesses from the same service in
the future as well, along with the ability to review and change that
choice at any time.

What was the motivation to eliminating prompts?  I assure you, opt-out
security systems go much worse in practice than opt-in; this has
proven to be the case in at least a dozen high-profile security breach
situations over the past couple decades.

Regards,
James Salsman
Received on Wednesday, 9 June 2010 12:57:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT