Re: Allow ... centralized dialog up front

Something is better than nothing, and both the iPhone and Android systems
are better than not asking the user at all. The principle of security in
depth is that you don't rely on a single security feature that may be
flawed, but have a multi layered approach to security.

I think that giving a user control of what information is released is a
necessary part of that model, and I cannot see anything in the documents
you link to that contradicts that. Are you suggesting that users should be
denied control of their information? What about information in sensitive
environments (politicians, security workers etc) who understand privacy are
suggesting we deny then the ability to control the access?

For me personally, being able to see all the information an application
will access and be able to return to this information and edit my
preferences at any time seems the best way to do this. Visibility is key -
you must be able to see what permissions have been granted so they can be
revoked, or just to reassure that certain permissions are denied. Others
may have different ideas, however nearly all on-line services are moving to
this model so it must offer some benefits. This model is also essential in
any kind of enterprise setting where the IT department will want to audit
and approve apps for use.


Cheers,
Keean.



On 6 February 2013 11:03, Robin Berjon <robin@w3.org> wrote:

> On 06/02/2013 08:36 , Keean Schupke wrote:
>
>> I don't think you can say either an up front dialog or popups do not
>> work. There are clear examples of both working, Android and iPhone
>> respectively. Each has a different set of trade-offs and is better in
>> some circumstances, worse in others.
>>
>
> If by "working" you mean that it is technically feasible and will provide
> developers with access to features then sure.
>
> If however you mean that it succeeds in protecting users against agreeing
> to escalate privileges to malicious applications then, no, it really,
> really does not work at all.
>
> Security through user prompting is sweeping the problem under the rug.
> Usually this is the point at which someone will say "but we have to
> *educate* the users!". No. We don't. Users don't want to be educated, and
> they shouldn't have to be. We're producing technology for *user* agents. It
> is *our* responsibility to ensure that users remain safe, even in as much
> as possible against their own mistakes.
>
> And I'm sorry to go all Godwin on you, but the prompting approach is the
> Java applet security model all over again. Let's just not go back there,
> shall we?
>
> It's not as if this debate hasn't been had time and over again. See (old
> and unfinished):
>
>
> http://darobin.github.com/api-**design-privacy/api-design-**
> privacy.html#privacy-**enhancing-api-patterns<http://darobin.github.com/api-design-privacy/api-design-privacy.html#privacy-enhancing-api-patterns>
>
> That includes a short discussion of why the Geolocation model is wrong.
> All of this has been extensively discussed in the DAP WG, as well as IIRC
> around the Web Notifications work. There have been a few attempts to work
> out the details (tl;dr they don't fly):
>
>     http://w3c-test.org/dap/**proposals/request-feature/<http://w3c-test.org/dap/proposals/request-feature/>
>     http://dev.w3.org/2009/dap/**docs/feat-perms/feat-perms.**html<http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html>
>
> That's one of the reasons we have a SysApps WG today. As it happens,
> they're working on a security model, too.
>
> This is not to say that declaring required privileges cannot be useful.
> There certainly are cases in which it can integrate into a larger system.
> But that larger system isn't upfront prompting.
>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>
>