A New DAP

The process of getting a technology standardised and adopted (not necessarily in that order) across a broad spectrum of industry and community can be a complex one, with many failure points. Amongst the problems that a group may face is when the opinions of some (louder) members can give the impression that they represent the group's consensus, causing those who disagree to leave post-haste (it's not as if there wasn't a lot of work to be done elsewhere already). And as we all know, once someone has formed a negative opinion and discussed it around them, it can be very difficult to change it back no matter what the facts say — all you get from there on is confirmation bias.

With the Device APIs WG (aka DAP) we're trying to change that. The group's initial charter (under which it is currently working) originally included the definition of a "policy framework", which is to say essentially a way of telling user agents "this site can use that API, but that other one over there I wouldn't trust with it". Personally, I was never a huge fan of policy as many envisioned it back then. That is why it was made very clear early on in the group's life that irrespective of whether the group was going to eventually produce a policy framework standard, the APIs that it would create would all be defined to be entirely safe in an open environment such as a browser on the Web, without involving any manner of policy.

I did think however that some constructive discussions could be had on the topic of policy. Mozilla made noises about some web-of-trust vetting for extensions. Google showed off Powerbox, a very interesting way of peering a client with a service based on a security model that OAuth would do well to think about. Overall though, there was very little traction behind this work, and at the same time many saw it as a threat and assumed that it would define security for the whole group. As a result, the group took the decision to drop work on policy entirely. People can experiment in their own domains, and if something benefiting from the sort of support that would justify a standard comes up, then W3C can look into that then.

There is still demand for a policy framework from the mobile industry. But if it's going to be a mobile-only technology then there is nothing wrong with ratifying it in a mobile-only consortium. What DAP produces has to be part of the One Web — there just is no way around that, not matter how frustrating it may feel to some.

There have also been some complaints that some of the original proposals included things that are just too dangerous no matter what security you have around. One example that was given was that one of the proposed address book APIs mentioned a deleteAllContacts() methods. There isn't really a way to make that safe (and even if there were, I'm not sure why you'd want that in an API in the first place). Those however were just the inputs and did not represent consensus in the group. To stick to the same example, the Contacts API that is now available is defined as a read-only API, with security designed to match existing practices and interesting privacy features for data minimisation. Saving back to the local address book is left up to Javascript, which is (safely) up to the job on its own using existing APIs (as described in the annex).

All in all it's worth dispelling the causes for confusion. More importantly, it's worth getting feedback on what's right or wrong about the group in general, from all possible sources. In order to get that going, we've put up a draft charter, which you can go read at http://www.w3.org/2010/11/DeviceAPICharter.html. It removes policy, clarifies how the APIs ought to be designed, talks more about privacy, and tightens up the scope — essentially what the group has been doing, put there in a binding fashion.

It is by no means final. Comments are open to absolutely anyone. You can send them to the group, or directly to me if you prefer. Everything is up for discussion. Adding new stuff, removing old stuff, giving up altogether, using more <blink> elements in our specifications, buying me beer — you name it. You don't have to represent your company in any way, we're more than happy with people speaking for themselves.

The only rule I plan on enforcing is that if you don't provide feedback now but I later hear you bitching about DAP, you'll owe me a beer, and a round for the group. I have freakishly good hearing and an apparently endless thirst for beer — so you know you better keep those comments coming!