There is a growing number of operating systems and applications frameworks that are based on, or integrate deeply with Web technologies: Intel & Samsung’s Tizen, HP (formerly Palm) WebOS, Mozilla’s boot2gecko, Windows 8 Metro apps, WAC, Webinos, PhoneGap to name a few.

In particular, most of these projects have JavaScript APIs to interact with features that are not available to browsers due to security and privacy concerns.

During the W3C Device APIs Working Group F2F in TPAC, there were some discussions around that split: some of the participants involved in the efforts above were somewhat frustrated that DAP would only work on APIs that can be used from within the Web browser (as the group’s new charter forcefully stipulates) since they would like to use standards APIs for some of the features in their OS context.

What I think is behind this tension is that APIs designed for use on the open Web need to be defined in a way that is compatible with the specific constraints of security and privacy on the Web. That in particular implies that the developer using these APIs is by default very little trusted.

There are deployed mechanisms and approaches to increase that trust for specific features, but there isn’t yet a generic mechanism that can be used to increase the level of trust significantly without compromising the user’s security or privacy. Most of the difficulties lie in providing the user with unobtrusive, informative and actionable user interfaces to make it possible for her to take decisions in her best interest.

There are a number of such mechanisms that are being explored and tested, but until there are proven to work, each additional feature to the Web platform must be gated in light of these constraints. And for many features, this simply means not making it to the Web at all for the time being.

Obviously, Web-based operating systems have usually a very different security approach, where privileged access get granted on a regular basis, usually via an installation process. Some have argued that such a process could be extended to Web applications, but there are still very strong arguments against the appropriateness of that approach on a system as open as the Web.

When security and privacy concerns are considered as an out of band process, the constraints on API design become very different; for instance:

each time the user needs to authorize an operation, the underlying API needs to be asynchronous — this means a lot more of those on the Web than in systems where access to the APIs has been pre-gated;

reducing the exposure of personal data via data minimization helps on the Web, but is perceived as awkward on Web-based operating systems.

There are ways to extend Web APIs to provide additional features for Web-based operating systems; but early feedback of experiments in this space seems to indicate that they make rather confusing APIs.

This of course doesn’t mean that the various projects using JavaScript APIs for non-Web usage shouldn’t get together to agree on a common set of APIs — it seems to me that they definitely should, provided that their security model are reasonably close enough that they can use the same rough approach to API design.

And this could happen in W3C, maybe starting with a Community Group, and then a Working Group if useful. But it looks likely best that the DAP Working Group focus on one type of APIs — Web APIs — and do them well, rather than trying to chase two hares.