Re: Allow ... centralized dialog up front

So how exactly do you imagine this going down when an application that uses
half a dozen such capabilities starts? Clicking trough half a dozen allow
-> allow -> allow -> allow -> allow -> allow, you really think the user's
gonna bother what the 5th or sixth allow is about? You'll end up annoying
the user, the developer and scaring people off a page. Somehow I can't see
that as the function of new capabilities you can offer on a page.
Furthermore, some capabilities (like pointerlock) actively interfere with
the idea that when you need it you can click it (such as the concept of
pointer-lock-drag which requests pointerlock on mousedown and releases it
on mouseup) where your "click it when you need it" idea will always fail
the first usage. Not exactly confidence inspiring either, as a UX.


On Mon, Feb 4, 2013 at 1:28 AM, Tobie Langel <tobie@fb.com> wrote:

> On 2/2/13 12:16 PM, "Florian Bösch" <pyalot@gmail.com> wrote:
>
> >Usually games (especially 3D applications) would like to get capabilities
> >that they can use out of the way up front so they don't have to care
> >about it later on.
>
> This is not an either / or problem.
>
> First, lets clarify that the granting of a permission (and for how long it
> is granted) can be dependent on a variety of factors defined by the user
> and or the user agent and is out of control of the developer and of any
> spec body to standardize.
>
> Different User Agents will behave differently depending on what market
> they target. Different users will react differently depending on their
> security and privacy thresholds, the trust relationship they have with the
> URL they're visiting, etc.
>
> The permission to carry out a certain task on the user's behalf (such as
> taking a picture) might change at any time for any number of reasons (such
> as the device's camera being unplugged or broken). There's only one
> solution to this: code defensively.
>
> APIs that require specific user permissions are designed so that the
> user's can be prompted every time the API is required to be used. Whether
> the device chooses to do so or not is implementation specific (and again,
> depends on external factors such as user settings, etc.).
>
> Generally, this solution has proven to be both flexible and secure.
>
> Handling permissions up front has three unwanted effects:
>
> 1. Users tend to not read the upfront permission settings that much thus
> often accidentally granting more privileges than they would like to.
> That's a security and privacy issue.
> 2. Users tend to reject apps which have too many permission requests or
> permission requests that feel out of scoop of the app. Eg. A chess game
> asking for permissions to use the camera is rather off-putting until you
> realize it uses it to take snapshots of a chess-board and suggest next
> moves. This awareness generally comes with app usage, or because you're
> aware of the feature set of the app through information provided by the
> developer (marketing) or third parties (reviews, friends, etc.).
> 3. Upfront permission lists rapidly get out of sync with real application
> requirements. What happens then?
>
> In fact, Upfront permission requirement only really makes sense when the
> user has already built a relationship of trust with the developer of the
> application or trusts a third party that has means of enforcing good
> behavior from the app developer (e.g. through an app store system).
>
> A hybrid approach that considers upfront permissions as hints of
> permission requirements to come offers the best of both worlds. It allows
> developers to ask permissions upfront for things that make sense given the
> context (e.g. a camera app would require camera access upfront) and at a
> later stage for features that might not be so obviously connected to the
> app's main use case or present a bigger risk for the user. It also allows
> the User Agent to treat these hints as it wishes, e.g. by prompting the
> user upfront, by automatically granting some permissions using various
> kinds of heuristics, or by deciding to only prompt the user when the
> feature is actually going to be used.
>
> It is worth noting that the developer will still need to code defensively
> for such an approach, as the user (or user agent) might very well not
> grant all permissions upfront and still require prompting at a later
> stage. Previously granted permissions might also be recalled at any time.
>
> This approach doesn't require the User Agent to let the developer know
> which permissions the user has granted upfront nor would that be useful
> given permissions can change at any time.
>
>
> --tobie
>
>