RE: ACTION-52 Look at markup options for expressing implicit user consent

Max,
I agree with the examples you give, just a couple of comments:

1) There is another form of consent, "consent-by-trust", which removes the need to rely upon either dialogs or implicit action. There are be a lot of webapp use cases that will depend upon automated behaviors (access to API's) without either dialogs or implicit action, e.g. especially those involving mobile devices. The negative effects upon user experience of dialogs and implicit action on input/control-constrained devices will require a more seamless/low-input experience.

2) The user should have the ability to say "do this automatically from now on" where applicable (ala "[+remember]"). This the current design of browsers for content-type helpers and file download ("save automatically"). We need to be sure that DAP does not diminish the usability of applications as compared to browser pages.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Max Froumentin
Sent: Tuesday, November 17, 2009 4:17 AM
To: public-device-apis@w3.org
Subject: ACTION-52 Look at markup options for expressing implicit user consent

ACTION-52 Look at markup options for expressing implicit user consent 
(like <input type="file" />)

Summary: for each API in the charter I wrote down initial thoughts on 
how to implement a "consent by initiative" privacy strategy, similar to 
HTML's file upload.

Using the <input> element to let the user allow the browser to access 
local data provides a good way to implement a "consent-by-initiative" 
policy, which works better than "consent-by-dialog" methods which the 
user tends to dismiss without reafding. If the user explicitely asks the 
page to access the device's private data, a dialog is not needed.

The existing example of thaf is File upload in HTML Forms: <input 
type="file">. The web application cannot access the device's file unless 
the user has clicked on the "upload" button. Generalising that method 
might work for other types of local access. This email explores
that idea for this group's device APIs.

- File: <input type="file"> for upload, as in current HTML but adding 
<http://www.w3.org/TR/file-upload/>. To allow file modification, the 
dialog would have a checkbox labeled "Allow modification", and the 
browser would enfore writableness of the uploaded file

- calendar: Similar with <input type="calendar"> and an API for Calendar 
manipulation. Ditto for contacts, tasks, gallery

- Gallery: ditto.

- camera: <input type="image"> would, on clicking, prompt the 
viewfinder. See <http://www.w3.org/mid/4AFD83E0.20609@opera.com>

- messaging: the webapp would compose a message and whatever send()
method would trigger the device's native UI to show a preview of the 
message which could not be sent without the user pressing a button

- system info: <input type="sysinfo">? Hard to make it practical. 
Probably better to rely on a general policy

- Application Launcher: if the launcher is based on mime types, then the 
existing mechanism: dialog, like "What should Firefox do with that file? 
Open With / Save. [+remember]"

- Application configuration. Probably too low level to have user 
initiate operation

- User Interaction: no user control needed: browser (window resize, 
alerts) or device (vibrate) should let user decide if functionality is 
enabled.

Max.

Received on Wednesday, 18 November 2009 14:10:38 UTC