Mozilla

As we’ve hoped, there has been a lot of interest in the newly announced WebAPI effort. So I figured that I should explain in more detail some of my thinking around what we’re hoping to do and the challenges that are ahead of us.

Goal

The goal of this effort is to create APIs to expand what the Web can do. We don’t want people to end up choosing to develop for a proprietary platform just because the Web is lacking some capability.

The main effort, at least initially, is to enable access to hardware connected to the device, and data which is stored or available to the device. As for hardware, we want to make the full range of hardware that people use available to the web platform. From common hardware like cameras, to more rarely used (but no less awesome) hardware like USB-driven Nerf cannons. We also want to enable communication hardware like Bluetooth and NFC.

For data stored on the device, the most commonly discussed data today is contacts and calendar. This includes the ability to both read and write data. That is, we both want the Web platform to be able to enumerate contacts stored on the device, and read their details, as well as add and remove contacts. In short, we want it to be possible to create a Web page or Web app which lets the user manage his contact list. Same thing for calendar events and other types of data stored on devices.

Security and Privacy

One big reason these types of APIs haven’t been developed for the Web platform yet is because of their security and privacy implications. I would obviously not want every single Web page out there to be able to mess around with my contact list or my calendar. And being able to issue any commands to any USB device that I happen to have plugged in would likely result in everyone’s computer immediately being zombified.

So as we are developing these APIs, we always have to develop a security model to go along with them. In some cases simply asking the user, which is how we currently do Geolocation, might work. In others, where security implications are scarier or where describing the risk to the user is harder, we’ll have to come up with better solutions.

I really want to emphasize that we don’t yet know what the security story is going to be, but that we’re absolutely planning on having a solid security solution before we ship an API to millions of users.

Robert O’Callahan has a really great post about permissions for Web applications.

Standards

Mozilla has always had a strong commitment to Web standards. This is of course not something we’re changing! All of the APIs that we are developing will be developed with the goal of being standardized and implemented across both browsers and devices.

But it’s important to ensure that standards are good standards. This takes experimenting. Especially in areas which are as new to the Web, and as security sensitive, as these are.

Standards organizations aren’t a good place to do research. This is why we want to experiment and do research outside the standards organizations first. But always in the open, and always listening to feedback. We’re also going to clearly prefix any APIs as to indicate that they are experiments and might change once they get standardized.

Once we have a better understanding of what we think makes a good API we will create a proposal and bring to working groups like the Device API group at W3C, WAC and WHATWG.

Throughout this process we will of course be in contact with other interested parties, such as other browser vendors and web developers. This is part of the normal research and making sure that an API is a good API.

Mozilla always has and always will be a good steward of the open Web. We are not interested in creating a Mozilla-specific Web platform. We are interested in moving the open Web platform forward.

High Level vs. Low Level

One thing that often comes up with API design is whether we should do high level or low level APIs. For example, do we provide a low-level USB API, or a high-level API for cameras?

There are pros and cons with both. High level means that we can create more developer-friendly APIs. We can also provide a better security model since we can ensure that the page won’t issue any unexpected USB commands, and we can ensure that no privacy-sensitive access is made without user approval. But high level also means that developers can’t access a type of device until we’ve added support for it. So until we’ve added an API for Nerf cannons, there will be no way to talk to them.

Exposing a low-level USB API on the other hand, means that web pages can talk to any USB device in existence, with no need for us to add an explicit API for them. However it also requires developers to get their hands dirty with the details of the USB protocol and differences between devices.

The approach we’re planning on taking is to do both high-level and low-level APIs, as well as give people the proper incentives to use the one that is best for the user. But a very important point is to provide low-level APIs early to ensure that Mozilla isn’t on the critical path for innovation. Over time, we can add high-level APIs where that makes sense.

How you can join

As with all things Mozilla, we’re planning on doing all our work in the open. In fact, we’ll be relying on your help to make this successful! As to keep discussions focused, we’re going to use the a new mozilla.dev.webapi discussion forum for all communication. This means that you can participate through email, newsgroups, or the web-based google group UI.

You can subscribe to the mailing list at https://lists.mozilla.org/listinfo/dev-webapi

For other methods go to: http://www.mozilla.org/about/forums/#dev-webapi

We also use the #webapi IRC channel on irc.mozilla.org.

We’ll also be tracking progress on the wiki page https://wiki.mozilla.org/WebAPI

Looking forward to hearing from you to help build the next stage for the web platform!

Hiring developers

Edit: Forgot to mention, we are hiring several full time engineers for working on the WebAPI team! Read the job description and apply.

18 comments

Comments are now closed.

  1. Ferenc Mihaly wrote on August 29th, 2011 at 15:12:

    This may be a good learning opportunity for me. I’ve been involved in API design for large enterprise applications so far (no mobile experince). Following what design trade-offs you guys are making should be very interesting. Thanks for sharing! .

    1. Robert Nyman wrote on August 30th, 2011 at 12:37:

      Thanks! We’re hoping it’s going to be something exciting!

  2. Andrew wrote on August 29th, 2011 at 21:12:

    Thanks for the article Jonas as it really clears up a lot of uncertainty in this space. The key point of “… providing low-level APIs early to ensure that Mozilla isn’t on the critical path for innovation …” in combination with the Calendar and Contacts goals is music to my ears!

    1. Robert Nyman wrote on August 30th, 2011 at 12:37:

      Good that you like it!

  3. Natanael L wrote on August 30th, 2011 at 02:28:

    /me imagines hooking up a Kinect and a RepRap or MakerBot to a tablet running Firefox. Sound like a whole lot of fun to be had! :P

    1. Robert Nyman wrote on August 30th, 2011 at 12:37:

      It does, doesn’t it? :-)

  4. Robert Schultz wrote on August 30th, 2011 at 09:07:

    Sums this up: http://xkcd.com/927/

    Still though, I wish you the best of luck.

    1. Robert Nyman wrote on August 30th, 2011 at 12:38:

      Yes, it’s a good one. :-)
      The idea here though isn’t really to invent a new standard, but rather come up with new ideas and perspectives that will hopefully improve existing ones.

    2. Jonas Sicking wrote on August 30th, 2011 at 16:27:

      Haha, yes, that one has been making the rounds in the standards community. It’s going to be toooootally different this time though ;-)

  5. knygar wrote on August 30th, 2011 at 15:48:

    Hello Robert Nyman and Jonas Sicking!

    I’m glad that you have clarified the intention to work with/for existent “Web API’s” groups. There are another such a group – http://www.w3.org/community/native-web-apps/
    For me,
    it clearly shows that idea needs standardized and all-included (as possible) realization.

    > both high-level and low-level APIs, as well as give people the proper incentives to use the one that is best for the user..

    i think – that is appropriate way.

    > post about permissions
    also – there is an article by Robyn Tippins –
    http://developer.yahoo.com/blogs/ydn/posts/2010/01/securing_web_extensibility/
    more like “my kind” of the post – a lot of links, not so many
    comments :)

    I’v written to your mailing list, but you, probably, haven’t seen the message as i’v decided to place it into https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/48e2c83cb2cf1e65#
    just to make that thread a two-messaged =)

    I represent here the http://www.w3.org/community/ar Community Group:

    – AR CG would, definitely work with these “Web API’s” wherever they would be standardized, implemented,
    however – my support is strictly for the Mozilla B2G project
    it was for Chromeless but B2G seems the edge now, securing most of the AR needs.. i wonder if Mozilla encourages the developers of the related Moz projects to work for the “next steps”? for example – i’v seen that Lloyd Hilaiel has worked for the potential of WebAPI kind of API’s.

    We would create the thread on WebAPI list – when we’ll draw the Charter, among other matters – according to your effort ;)

    PS: Keep developing the real innovations for the Open Web, you are great!

    1. Jonas Sicking wrote on August 30th, 2011 at 16:39:

      The “native web apps” group in W3C is pretty new, so I haven’t had time to research it enough to comment on it.

      However mozilla has been working on web apps for a while now. I know that the intent of that team is to create a standard for web applications similar to how the WebAPI team is aiming to create standards for APIs. And similar to us they are currently focused on doing research, but the goal is to produce something that is implemented across browsers. They have even written extensions for Chrome to ensure that it’s implementable in more than Firefox.

      You can read more about it at https://apps.mozillalabs.com/

      I don’t quite understand the question related to the AR CG.

  6. knygar wrote on August 30th, 2011 at 17:58:

    > The “native web apps” group in W3C is pretty new, so I haven’t had time > to research it enough to comment on it.

    Ofc, it is the group that currently just like the small group for implementation of the interest.. there is the thread with http://lists.w3.org/Archives/Public/public-native-web-apps/2011Aug/0001.html
    introductions from the members, since it is the community group, it is pretty much – follows the people that are currently in.

    > https://apps.mozillalabs.com/
    sure, i’m keeping an eye on it from the launch,
    tried the extensions, applications, posted some feedback, thank you.
    To add – i really like the approach, some of the additional func. would depend on projects like WebAPI’s. Many of basic API’s for web are on the way already, so, yes, i believe that “Web Apps” would be the “applications that run on any device”, at least — maybe on any “open” device that you may fully and easily customize as you need. At worst – just everywhere you could root into :)

    I completely understand that Mozilla’s work is for One Web Standards,
    but in the end – the implementation for experimenting and finally – testing of the WebAPI “standards” would be in Gecko, isn’t it?
    For OpenWebApps there are extensions that now gives some basic func.
    (a little more to Firefox due to the nature of changes and ability of support, ofc.). Your WebAPI’s would, obviously, extent the possibilities.

    So the questions:
    – Does Open Web Apps team would experiment with the use of Web API’s?
    – Do you – as a WebAPI’s team – plan to work closely with that team, from a start?
    – Do you plan to work for implementation into main Firefox or you plan to work for B2G first of all?
    – Would Mozilla continue the Chromeless project – just for a desktops?
    – If no — maybe the plan is to evaluate the efforts on B2G from a start and then – push back into “separate” Browsers? (i mean – into “Desktop” Firefox and Firefox Mobile)

    > I don’t quite understand the question related to the AR CG.
    if you mean the mozilla.dev.webapi question:

    essentially – what i need to know now is –
    “confirm that this WebAPI team
    is working closely with https://wiki.mozilla.org/B2G team”

    I need it to know for W3C AR CG to be sure that first changes and testing and experimenting you(WebAPI team) are about — would be in B2G.
    By that – we’ll understand that B2G would be the kind of “main project” for latest innovations. Kind of Live Aurora in the old (some previous :) Mozilla’s means.

    Thank you in advance.

    1. Jonas Sicking wrote on August 30th, 2011 at 19:06:

      We’ll be working closely with all teams at mozilla :-)

      But yes, we are working closely both with the Web Apps team and the B2G team.

      Our plan is to implement our APIs both in Firefox (both desktop and mobile) and in B2G. This is part of ensuring that the APIs actually will work across different platforms. It’ll vary where we implement first. For example USB support is being developed for Firefox on Windows first, whereas SMS support is happening on Firefox mobile on Android currently.

      Of course, in some cases we’ll be limited by what the platform is capable of. So for example sending text messages or vibrator access won’t be available on platforms that doesn’t have phone capabilities or a built in vibration device.

  7. Mounir wrote on September 4th, 2011 at 17:57:

    Jonas wrote: ” We don’t want people to end up choosing to develop for a proprietary platform just because the Web is lacking some capability.”

    I haven’t followed the project very much so there might be a simple answer to this. But if create a web page relying on your WebAPI, isn’t that “developing for a proprietary platform”? Sure, it might be open source, but from a consumer perspective I need to rely on my users to download and install your browser.

    Would such a project be better if the whole industry comes together and creates a common WebAPI for every browser? I know that’s like asking Osama Bin Laden and the Pope to become best friends, but you get my point?

    Basically a WebAPI for one browser is as useful as WebAPI for no browsers. You lose the ubiquitous feature that HTML/JS is known for.

    1. Robert Nyman wrote on September 5th, 2011 at 01:35:

      The idea for WebAPI is rather to experiment and test things, to come up with improvements to existing standards or, if necessary create new ones. They are all about to be standardized, not owned by Mozilla.

    2. Jonas Sicking wrote on September 6th, 2011 at 00:33:

      Browser developers have a long history of coming together and creating standards together. The goal is absolutely to have that happen here too!

  8. sung wrote on September 4th, 2011 at 20:04:

    I’m really excited about the project’s potential. Do you think even people with moderate coding experience can help out with something as ambitious as this?

    1. Robert Nyman wrote on September 5th, 2011 at 01:35:

      Try out the forums to get in contact mentioned in the post, and hopefully there’s an area where you can contribute!

Comments are closed for this article.