W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Allow ... centralized dialog up front

From: Keean Schupke <keean@fry-it.com>
Date: Sat, 2 Feb 2013 10:43:06 +0000
Message-ID: <CAFpgLgJU0k-gqoF0+Eaa2KT8UoZMx5LZb+DE8r1qfrJPC-HMGQ@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Arthur Barstow <art.barstow@nokia.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, WebApps WG <public-webapps@w3.org>, Adrienne Porter Felt <adriennefelt@gmail.com>
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.


 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC