Don’t call me DOM

28 November 2011

Web APIs vs APIs for Web-based OS

Filed under:

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.

5 Responses to “Web APIs vs APIs for Web-based OS”

  1. Dave Raggett Says:

    I don’t think there needs to be such a strong distinction between WebOS APIs and Web APIs. The approach taken by Android may satisfy minimal legal requirements, but fails to provide users with adequate information on what applications will do with the data they gather to allow for an informed choice at installation time. Users are pressured into clicking their assent. On the other hand the approach advocated by Robert O’Callahan can in the worst case result in the user being bombarded by a sequence of permission requests for web apps that seek access to multiple APIs, although these requests are hopefully in context and in some cases implicit in the user’s action, e.g clicking on a button “show my location” for a map application.

    You note that on the open web the developer using these APIs is by default very little trusted. On Android, the developer is overly trusted. This suggests that there is a middle ground where users are given reasonable and informed grounds to trust applications for specific purposes.

  2. markus Says:

    As a user, I want to have a WebOS where I am in full charge of EVERY element EASILY.

    Security may be a problem for many, but for me, I just don’t care. I don’t care about when others laugh about it either.

    I want the features. I want tools that help me more.

    I don’t care about W3C though. Standards are nice, but honestly if something today already works, which gives me new features, than I will use it.

  3. Web APIs vs APIs for Web-based OS | FM52.COM Says:

    […] 文章来源:Web APIs vs APIs for Web-based OS Posted in 移动开发 « HTML5未来发展的六大趋势 Firefox遭遇市场份额和资金困境 » You can skip to the end and leave a response. Pinging is currently not allowed.  […]

  4. Web APIs vs APIs for Web-based OS | Web App Trend Says:

    […] 文章来源:Web APIs vs APIs for Web-based OS […]

  5. web hosting Says:

    WEBOS seems to be cool however I don’t like the fact that the security is not there, I mean it is cool that it will be bringing more tools and feature but without the proper security what I’m I going to do with theses cool things it just not that appealing. is like here I’m going to give you 1 million dollars but you will not have the security necessary to keep it from being stolen.

Picture of Dominique Hazael-MassieuxDominique Hazaël-Massieux ( is part of the World Wide Web Consortium (W3C) Staff; his interests cover a number of Web technologies, as well as the usage of open source software in a distributed work environment.