Re: Allow ... centralized dialog up front

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

Received on Monday, 4 February 2013 00:29:23 UTC