RE: ACTION-364: Draft section on best practices for sites requesting exceptions

Hi Matthias,

Welcome back!

On adding to the TPE,  -0 ( no objection), on issue-151 I agree with SHOULD.

Can we talk about site-specific DNT:1 on the next TPE call?

Mike

-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 18 March 2013 14:20
To: public-tracking@w3.org
Subject: Re: ACTION-364: Draft section on best practices for sites
requesting exceptions

Hi Team,

any objections to adding this draft text (non-normative) to the TPE spec to
facilitate reviewing it?

Regards,
matthias


On 28/02/2013 02:41, David Singer wrote:
> This action is to provide informative (not normative) text on how sites
might use the exceptions API, particularly when some portion or feature of
the site is 'gated' on whether an exception has been granted by the user.
Since it's informative, I try to avoid normative words like must, should,
etc.
>
> Comments welcome, of course.
>
> XX Exception use by sites (informative)
>
> This section is to inform the authors of sites on some considerations in
using the exceptions APIs to best effect; sites of particular interest here
are those that need an exception in order to allow the user to perform some
operation or to have some access.
>
> The 'Store' calls do not have a return value, and return immediately.  If
there is a problem with the calling parameters, then a Javascript exception
[[ed: the name collision is unfortunate]] will be raised.  In addition, it
may be that the user-agent does not immediately store the exception,
possibly because it is allowing the user to confirm. Even though the site
has acquired the user's informed consent before calling the 'Store' API, it
is possible that the user will change their mind, and allow the store to
proceed but then later ask it be removed, or even by denying the storage in
the first place.
>
> Sites can call the 'Confirm' APIs to enquire whether a specific exception
has been granted and stands in the user-agent. This is the call to make to
determine whether the exception exists, and hence to control access to the
function or operation;  if it fails (the exception has been deleted, or not
yet granted), then the user is ideally again offered the information needed
to give their informed consent, and again offered the opportunity to
indicate that they grant it. As stated in the normative text, the site needs
to explain and acquire consent immediately prior to calling the Store API,
and not remember some past consent; this allows the user to change their
mind.
>
> If they do grant it (using some positive interaction such as a button),
the site can return to checking the 'Confirm' API.
>
> In this way the site:
> * does not assume that the storage is instantaneous, and mistakenly 
> grant access when the exception does not (yet) stand
> * does not call the Confirm API repeatedly without a user-interaction 
> between each call, in a loop
> * permits the user the opportunity to delete a previously granted
exception.
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>

Received on Monday, 18 March 2013 14:49:38 UTC