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

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

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 18 Nov 2009 09:46:56 -0500
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <B2F197DF-BD14-48BD-936B-8DF43D4CEDF9@nokia.com>
To: ext Max Froumentin <maxfro@opera.com>
Thanks Max.

Are the semantics of the input element with all of these types  
currently defined? If not, where would this be defined, in HTML5  
standardization or elsewhere?

For example, where would the semantics of the HTML <input  
type="camera"> be defined? Is this to be defined in conjunction with  
the API definition in DAP?

Regarding the technical approach, how much varying detail will we need  
in the API definitions regarding write assumptions, granularity of  
access control?

For example,  I assume for files the assumption is to depend on the  
file system access control mechanisms (though I don't quite understand  
how that works for a user without a local account, though it could be  
Unix "other").

What about other write accesses, e.g. gallery? In this case access  
might be limited to certain directories on the SIM, or local file  
system, for example, or a USB card, or external hard drive etc

In summary, we might need to be careful defining the semantics of the  
input type for write in the various cases and I'm looking to  
understand how this would work, especially from those who understand  
how this can be done without access control policy.

regards, Frederick

Frederick Hirsch

On Nov 17, 2009, at 7:17 AM, ext Max Froumentin wrote:

> 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:48:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC