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: Robin Berjon <robin@robineko.com>
Date: Wed, 18 Nov 2009 14:57:21 +0100
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <0E6DA66A-E842-4BE3-9DE7-25EA27A4732D@robineko.com>
To: Max Froumentin <maxfro@opera.com>
On Nov 17, 2009, at 13:17 , Max Froumentin wrote:
> ACTION-52 Look at markup options for expressing implicit user consent (like <input type="file" />)

Thanks Max, this is very helpful.

> 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.

I thought we had decided on an action item for someone to draft definitions of the various types of consent but I can't seem to find any trace of that now. Did I dream it up? (I'm not saying it was you :).

> - File: <input type="file"> for upload, as in current HTML but adding <http://www.w3.org/TR/file-upload/>. 

I think you mean http://www.w3.org/TR/FileAPI/, the one you cite is deprecated (we should redirect to the new one).

> To allow file modification, the dialog would have a checkbox labeled "Allow modification", and the browser would enfore writableness of the uploaded file

That's one option. Another could be a "Save" file picker which the user would have to action with an <input type="save"> action. Note that this only covers reading and writing, not navigating directories.

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

We don't have to rely on general policy, there's also asynchronous consent  la Geolocation.

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

We dropped that deliverable anyway.

My issue with the <input type="foo"> extensions is with the quality of fallback. If the implementation doesn't support it, you get a text field. That can be worked around but it's still a bit annoying. Another approach could perhaps be to add an attribute to <form> and use that  with the fallback being regular input fields as the form's content that could be used to enter the same information manually.

It's worth noting that most of these APIs likely call for multiple entry points.

Robin Berjon
  robineko  hired gun, higher standards
Received on Wednesday, 18 November 2009 13:57:56 UTC

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