W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

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

From: Max Froumentin <maxfro@opera.com>
Date: Tue, 17 Nov 2009 13:17:29 +0100
Message-ID: <4B029459.6090405@opera.com>
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
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 Tuesday, 17 November 2009 12:18:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT