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

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 Thursday, 28 February 2013 01:42:04 UTC