Mozilla

Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months.

The current situation

Where we are today, there’s a clear distinction between the Open Web and native APIs and how things have to be built. As many developers are aware of, we need consistent APIs across web browsers, operating systems and devices to be able to build something for the world, not just a specific device or vendor. We need a way to take the web to the next step.

What is WebAPI?

WebAPI is an effort by Mozilla to bridge together the gap, and have consistent APIs that will work in all web browsers, no matter the operating system. Specification drafts and implementation prototypes will be available, and it will be submitted to W3C for standardization. Security is a very important factor here, and it will be a mix of existing security measurements (e.g. asking the user for permission, like Geolocation) or coming up with new alternatives to ensure this.

In the nearest timeframe we are looking into building:

  • Dialer: Telephony & Messaging API, Contacts API
  • Address Book: Contacts API
  • SMS: Telephony & Messaging API, Contacts API
  • Clock
  • Camera: Camera API, Filesystem API
  • Gallery: Filesystem API (could possibly be FileReader & FileWriter in conjunction)
  • Calculator
  • Settings: Device Status API, Settings API
  • Games: Accelerometer API, Mouse Lock API
  • Maps: Geolocation API, Contacts API

Contribute

We know that there are so many talented people out there with great input, so please contribute through any of these means:

Hiring developers

We are also hiring several full time engineers for working with WebAPI. Read the job description and apply.

117 comments

Comments are now closed.

  1. Reg wrote on August 28th, 2011 at 3:20 pm:

    Sorry to be the cause of another round of derisive laughter, but the top issue for our organisation is DRM. We deliver internet video-on-demand solutions, and any delivery mechanism that doesn’t allow us a reasonable attempt to protect our client’s content from theft simply doesn’t get considered. For a long time the most favoured solution was Flash, but now clients are starting to insist on Silverlight.

    Ideally we would be able to take advantage of decryption beyond control of the browser – especially an open source one (no offence intended). This could be handing an encrypted video stream over to a HDMI device. After all IP TV is here – well almost.

    Not everyone will be using a HDMI device, and lower quality streams often do not require such strict protection. It would good to be able to push out a native build of a codec with our own decryption in it.

    1. Robert Nyman wrote on August 29th, 2011 at 5:51 am:

      I do understand the need for DRM, and it is not something that will just go away. I would say it’s not currently within the scope for WebAPI, though. Only the future can tell where it all evolves with DRM and solutions.

    2. Natanael L wrote on August 29th, 2011 at 5:59 am:

      DRM never works. It only needs ONE person to figure out how to break it, and then it’s broken.
      Combine that fact with open source, and…

      1. Robert Nyman wrote on August 29th, 2011 at 6:35 am:

        I think that, no matter the opinion, a lot of organizations require DRM for content they share (think all kinds of media houses etc). I the end, even if it’s broken, I believe it’s about making it harder for people to share content that they don’t own.

        1. Natanael L wrote on August 29th, 2011 at 6:57 am:

          And yet it is only an inconvenience to the honest people while only the original hacker among the the “less honest” sees it.

          1. Robert Nyman wrote on August 29th, 2011 at 7:03 am:

            I’d agree that most implementations of DRM are a nuisance for most users, yes.

    3. Foo Bar wrote on September 3rd, 2011 at 4:09 pm:

      DRM on audio/video content is simply physically impossible.

      Even if a software scheme cannot be defeated, anyone can just hook the audio/video outputs to a capture card, or just point a camera at the screen or attach a microphone to the speaker (if done properly, quality loss is negligible).

      The only thing you can successfully use DRM on is console games, provided that the console platform is properly designed for that.

      1. Robert Nyman wrote on September 5th, 2011 at 1:37 am:

        We know that, but I believe it’s more of making it harder for end users, thus hoping they won’t go through the effort of trying to break it.

  2. Fredrik Söderström wrote on August 31st, 2011 at 11:19 am:

    This is great, I can’t wait to use this!

    This is a great way of keeping the web open instead of everything becoming closed source apps.

    1. Robert Nyman wrote on September 1st, 2011 at 2:40 am:

      Thank you, good to hear!

  3. Julien Gouesse wrote on September 1st, 2011 at 6:07 am:

    Please don’t use DRM. This is not what I expect from Mozilla foundation! It is absolutely unacceptable. Defending DRM consists in defending a technical mean to protect industries refusing to adapt their business model, it is not what I expect from an open source product. Supporting DRM in WebAPI means that you plan to give more power to corporations and less power to users, it is exactly the opposite direction taken by the vast majority of free open source softwares. DRM endangers our rights, it allows to disable features, block products, censor and delete content even without the consent of the users. Putting such a thing in WebAPI would lead to allow such things remotely in both desktop and embedded environments. Do not sacrify our freedom to increase their profits. Our lives are worth more than their profits! Say NO to DRM, say YES to free open source softwares respecting our rights.

    1. Robert Nyman wrote on September 1st, 2011 at 7:15 am:

      I understand your strong opinions about DRM, and I’ve mentioned above that it not in the scope of WebAPI at all. What I am personally saying, though, is that for a number of legal reasons a number of media outlets are required to have a certain level of protection of their content – something HTML5 can’t offer at this time.

      So, I understand that the need is there in the market, but I don’t see Mozilla any time putting work into enabling DRM.

  4. Julien Gouesse wrote on September 1st, 2011 at 7:53 am:

    Thank you for this clarification. In my humble opinion, the world can live without DRM and the market must evolve so that it does not need such a control on contents. If the market refuses to evolve, we should not encourage it to preserve “old” mechanisms by any means dangerous for our rights.

    As you say, it is clear that DRM is technically not in the scope of WebAPI. Maybe I expect too much from Mozilla Foundation but even the principle of restricting users’ ability to freely use purchased products should not be tolerated.

    1. Robert Nyman wrote on September 1st, 2011 at 8:34 am:

      Personally, I’m not a believer in DRM either. But I do sympathize with the problems some developers/organizations have to face.

      Like you mention, from a Mozilla perspective, we do all kinds of activities to promote openness and the Open Web, and we aim to help out with offering open alternatives.

  5. David Rogers wrote on September 2nd, 2011 at 3:22 am:

    Sorry for my late response. Whilst I am pleased that Mozilla have finally come round on device APIs, I am equally frustrated that for the past three years they refused to engage with the OMTP BONDI, W3C DAP and WAC work on this. The scope was always there to be expanded and you could easily have contributed to the charter that I and others wrote. It is still unclear from the comments above as to whether you intend to fully contribute to the efforts ongoing in DAP and make this truly cross-browser and cross-industry. Also, please can you explain how you intend to handle access security and different user needs e.g. privacy?

    1. Robert Nyman wrote on September 2nd, 2011 at 3:29 am:

      Personally I weren’t around with Mozilla back then and I don’t know enough about the history to have a comment on that. Hopefully the follow-up blog post addresses some of your questions.

  6. Daniel Pavlic wrote on October 7th, 2011 at 2:54 pm:

    Hello,

    The WebAPI project looks very interesting. However, I don’t see any reference to the element in your spec. I think it would be a very good idea to make an API for drawing objects on the canvas which would make much easier to make a GUI than now is. The former Mozilla SkyWriter project (now http://cloud9ide.com/) has accomplished just this. It would be great to publish this engine so that everybody would be able to use it. Is this part of the WebAPI project?

    1. Robert Nyman wrote on October 8th, 2011 at 3:03 pm:

      That is not part of the WebAPI project at this time, but I agree it would be nice to be able to see that. We’ll see how it evolves.

  7. Daniel Pavlic wrote on October 8th, 2011 at 5:54 pm:

    Hi Robert, thanks for your reply. If an engine for drawing on the HTML canvas element is not part of the WebAPI project, and if I understand the accomplishments in the former SkyWriter i.e. former Bespin project correctly (http://benzilla.galbraiths.org/2009/02/17/bespin-and-canvas/), then it seems to me that Mozilla Labs already created an engine for drawing on the canvas 2 years ago? How would it be possible to create those menus, tabs, buttons etc. There must be an api created by the Bespin project so you can say e.g. WINDOW(x,y,length,height) and you get a window on the canvas which you can drag, minimize, maximize, put buttons on etc. I did not investigate deeper into what is now Cloud9 IDE, I’ve just read the blog articles about Bespin and I’ve seen the screenshots of the IDE so I might be missing something.

  8. Majid wrote on April 17th, 2012 at 2:18 am:

    Great work!.

    1. Robert Nyman wrote on April 17th, 2012 at 3:53 am:

      Thanks!

  9. Davy McAleer wrote on April 22nd, 2012 at 1:34 pm:

    Hi Robert,
    firstly you have the patience of a saint replying to all the varied requests and opinions!
    This is possibly a bit early in the day to consider, but one of the big issues at present with Android versus Apple is the ability to securely control the device in the business environment and the level of security overall for both consumers and business users. Is there any thought to creating an MDM (Mobile Device Management) API to enable encryption, implementing settings and restrictions remotely and lock and wipe type functionality in the case of a device being lost?
    Android OEMs have implemented this in a very piece meal fashion and this greatly diminishes the usefulness of the devices in the corporate environment – and with BYOD policies starting to come into play more and more Apple now looks alot more compelling for businesses and consumers in terms of security.
    Just wondered if you guys had any thoughts on remotely managing B2G devices or some form of permissions type roles function to be able to access your APIs if one of the MDM companies creates an App to run on the devices and access all the APIs you are exposing.
    Thanks and looking forward to seeing this stuff hit the real world – hats off to all those dedicated open sourcers!
    Regards
    Davy

    1. Robert Nyman wrote on April 24th, 2012 at 3:04 pm:

      > firstly you have the patience of a saint replying to all the varied requests and opinions!

      Thanks! :-)

      When it comes to current state and future plans for WebAPI, I’m personally not aware of work being done on that at the moment. But please keep track of the WebAPI page to see the progress!

  10. Gene Vayngrib wrote on April 27th, 2012 at 7:24 pm:

    This so is overdue! W3C is indescribably slow in this area. And Apple does not push device api in Safari as it will disrupt its App Store. Google behaves exactly the same as Apple on this issue. We have tried to remedy this with our own project 4 years ago, bhoost.com by creating a shell around webkit and know that it is no small undertaking. The problem is that people want to use a regular browser, not download a special one that gives access to Device Web APIs. So Mozilla entering this game may finally make Web Apps accessing Device APIs a reality. Besides, this would give Mozilla a leg up. Imagine a runaway popular Device-enabled Web App which works only on Mozilla for a while, until WebKit catches up. That App could be a Facebook Messenger, since Facebook pushes HTML5 agenda heavily as opposed to native Apps, or it could be something new.

    Some thoughts:
    1. What would be cool, is to have an ability in JS to check if browser supports Device API. This way we could offer user to download Mozilla browser.
    2. To compete with the Native Apps we need an easy way to register an icon on the home screen.
    3. To compete with the Native Apps we need an ability for a Web App to run in the background, or wake up upon some Device event.
    4. To compete with the Native Apps we need a way to autostart the background component of the browser and certain startup Web Apps. Imagine if user after a phone reboot needed to start the Phone and SMS apps manually. Can’t write a Web App that alerts me when some of my friends are in the vicinity if this ability is not present.

    1. Robert Nyman wrote on April 29th, 2012 at 8:42 am:

      Yes, we look to have everything standardized and hope that all the major players will follow suit.

      Regarding the thoughts:

      1. Generally it’s rather up to what kind of API that you want to use, than having a collective check for all. Besides, the number of APIs included change all the time, so maintaining that isn’t realistic.

      2. I completely agree.

      3. Platform dependent, but yes, they should be able to run in the background.

      4. When it comes to phone and SMS specifically, I think it depends on what application will have the right to access that and also how you can detect things in the background.

  11. Gene Vayngrib wrote on April 29th, 2012 at 8:53 am:

    Robert, thank you for your reply.
    1. Right, it is best to do checks on per feature basis. Can this be part of the new APIs? This way we will not need to come up with some ingenious and always different discovery mechanisms.
    4. May be I was not clear enough. I was referring to the Phone and SMS as examples of the apps which auto-start upon the phone reboot. If I were to create a new Siri, a new augmented reality app, a new social discovery app that reacts to where the user is in the environment and what is around him, I need to rely on the fact that my Web App is started after phone reboots.

    1. Robert Nyman wrote on May 8th, 2012 at 5:49 am:

      1. Well, the hope is that general feature detection should work. Web browsers shouldn’t claim to support, for instance, a method if it isn’t fully implemented.

      4. Ah, I see. Not sure exactly where we stand with that at the moment, but I agree.

  12. Aravind R S wrote on July 12th, 2012 at 7:24 am:

    Are there any plans in B2G for APIs to allow web applications to interact with each other? I think there is definitely a use case for simple interactions like Android Intents (WebIntents?).

    There might also be a need for something like background services that other applications on the device can communicate with via something like RPC.

    Intent use case: users may install multiple apps that provide “share” functionality on various social networks; Apps with content that can be shared could raise a generic “Share” intent and the user can then choose among the apps that provide that functionality.

    Intent/Services use case: users may have multiple internet radio apps from different websites, as well as a generic “music hub” app. The music hub app should be able to obtain a list of installed apps that have the “music playing service” capability, start/stop the services, and send messages to them for pause/play etc.

    1. Robert Nyman wrote on July 31st, 2012 at 8:28 am:

      Intents and working cross-apps are indeed interesting! It’s not clear at this moment exactly how that will be, but I do hope we will see some good progress there!

  13. robert wrote on July 16th, 2012 at 11:53 am:

    I think this first line
    Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months.

    is very misleading. From what I understand, as a newbie, WebAPI is trying increase the number of cross browser APIs. They are not specifically targeting mobile or phones.

    1. Robert Nyman wrote on July 31st, 2012 at 8:31 am:

      If you have seen the progress with Firefox OS, and with the hope of other mobile vendors following suit, it was exactly the first goal which has now been reached.

      Then, of course, we want as many APIs as possible be cross browser, no matter the platform.

  14. Himan Chen wrote on August 14th, 2012 at 7:59 pm:

    Hi,will you please tell me how to add a WebAPI to B2G,in other words,how can I write a WebAPI? Thank you!!!

    1. Robert Nyman wrote on August 15th, 2012 at 1:14 am:

      WebAPIs are developed by Mozilla and the community and then submitted to the W3C for standardization. Please join that project and share any ideas you might have!

1 2

Comments are closed for this article.