Re: Allow ... centralized dialog up front

There are benefits to the user, in that it allows all permissions to be
managed from one place.

I am not sure I like the idea of making the popups an application thing. I
think it should be decided by the browser. In any case you would still need
the ...Allow callbacks as the user may have gone to the permission
review/edit page and disabled some permissions since the app started.

Cheers,
Keean.

Cheers,
Keean.
 On 2 Feb 2013 10:27, "Florian Bösch" <pyalot@gmail.com> wrote:

> On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke <keean@fry-it.com> wrote:
>
>> I think a static declaration is better for security, so if a permission
>> is not there I don't think it should be allowed to request it later. Of
>> course how this is presented to the user is entirely separate, an the UI
>> could defer the request until the first time the restricted feature is
>> used, or allow all permissions that might be needed to be reviewed and
>> enabled/disabled in one place.
>>
> That kills any benefit a developer could derive. The very idea is that you
> can figure out up front what your user is gonna let you do, and take
> appropriate steps (not adding parts of the UI, presenting a suitable
> message that the application won't work etc.) as well as that if a user has
> agreed up front, that you can rely on that API and don't need to
> double-check at every step and add a gazillion pointless
> onFeatureYaddaYaddaAllowCallback handlers.
>

Received on Saturday, 2 February 2013 10:43:33 UTC