WebAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Add implementation status for Presentation API)
(→‎Security: suggest solution to the conundrum about "better solutions" for exposing sensitive information to web content)
Line 560: Line 560:
Security will be a central aspect of all the APIs that we design. We wouldn't want any random webpage to be able to read the user's contact list, or able to issue arbitrary commands to any USB device which is hooked up to the user's computer.
Security will be a central aspect of all the APIs that we design. We wouldn't want any random webpage to be able to read the user's contact list, or able to issue arbitrary commands to any USB device which is hooked up to the user's computer.


In some cases the solution will be to simply ask the user, like we do today for Geolocation for example. In other cases, where security implications are scarier or where describing the risk to the user is harder, we'll have to come up with better solutions.
In some cases the solution will be to simply ask the user, like we do today for Geolocation for example. In other cases, where security implications are scarier or where describing the risk to the user is harder, we'll have to come up with better solutions. For example, enumerating sensitive information or exposing device specific configuration to the web can be avoided by implementing dialogs (like the file picker for <input type=file>). Those can be implemented in the platform and ask the user which information to expose to the current website specifically.


This is an area where we're still doing a lot of research. I really want to emphasize that we don't have all the answers yet, but that we plan on having them before we roll out these APIs to millions of users.
This is an area where we're still doing a lot of research. I really want to emphasize that we don't have all the answers yet, but that we plan on having them before we roll out these APIs to millions of users.

Revision as of 14:30, 13 November 2015

The Mozilla WebAPI team is pushing the envelope of the web to include --- and in places exceed --- the capabilities of competing stacks.

Contributing

WebAPI work is being tracked by Mozilla bug 673923. Find a dependent bug that interests you (and is unassigned), and assign it to yourself.

Documentation

This wiki page's purpose is mostly to be able to track the advancement of the work on the different APIs covered by the WebAPI team and help working on those. If you are interested in documentation for these Web APIs, you should look at the following MDN documentation page: https://developer.mozilla.org/docs/WebAPI

APIs

Here's a list of the APIs that we're working on. Some of them are done, and some of them we haven't gotten further than acknowledging that we probably need them.

Planned for initial release of B2G

Unless otherwise noted, APIs listed in the table below were available in Firefox OS v1.0.1 or will be available in v1.1.

API Description Standardization Availability See also
WebTelephony Allow placing and answering phone calls as well as build in-call UI. W3C ED (SysApps) D A B bug 674726, Security
Vibration API Control device vibration for things like haptic feedback in games. Not intended to solve things like vibration for notification. W3C REC (Device APIs) D A B bug 679966, Security
WebSMS Send/receive SMS messages as well as manage messages stored on device. W3C ED (SysApps) D A B bug 674725, Security
Idle API Get notifications when user is idle. Needs plan D A B bug 715041, Security
Screen Orientation Get notification when screen orientation changes as well as control which screen orientation a page/app wants. W3C WD (WebApps) D A B bug 720794 bug 740188 bug 673922, Security
Settings API Set system-wide configurations that are saved permanently on the device. Future? D A B bug 678695, Security
Power Management API Turn on/off screen, cpu, device power, etc. Listen and inspect resource lock events. Future? D A B bug 708964, Security
bug 1017232, implement for Android
Mobile Connection API Expose signal strength, operator, etc for GSM and other mobile connections. This does not cover WiFi. Future? D A B bug 729173, Security
bug 1017233, implementation on Android
TCP Socket API Low-level TCP socket API. Will also include SSL support. W3C ED (SysApps) D A B bug 733573 bug 892833, Security
Geolocation API Access to the end user's location. W3C REC D A B Security
WiFi Information API Privileged API to get a list of available WiFi networks. Also get signal strength and name of currently connected network, etc. Future? D A B Security
bug 1017234, Android implementation bug
Device Storage API Add/Read/Modify files stored on a central location on the device. For example the "pictures" folder on modern desktop platforms or the photo storage in mobile devices. Needs plan D A B bug 717103, Security
Contacts API Add/Read/Modify the device contacts address book. W3C ED (SysApps) D A B bug 674720, bug 857730 for Android, Security
Mouse Lock API Lock access to mouse and get access to movement deltas rather than coordinates. W3C CR (WebApps) D A B bug 633602
Open WebApps Install web apps and manage installed webapps. Also allows an installed webapp to get payment information. Everything needed to build an Open WebApps app store. W3C ED (WebAps) D A B bug 697006, Security
WebBluetooth Low level access to Bluetooth hardware. Future? D A B bug 674737, Security
Network Information API Get basic information about current network connectivity. Example: "How fast of a connection do I have?". W3C ED D A B bug 677166 bug 713199, Security
Battery Status API Information about battery charge level and if device is plugged in. W3C CR (Device APIs) D A B bug 678694, Security
Alarm API Schedule a notification, or for an application to be started, at a specific time. W3C WD (SysApps) D A B {Security
Browser API Enables implementing a browser completely in web technologies. Future? D A B bug 693515, Security
Time/Clock API Set current time. Timezone will go in the Settings API. Future? D A B bug 714357, bug 714358, API proposed
Web Activities Delegate an activity to another application. Discussed in Device APIs D A B bug 715814 bug 776027 for Android
Push Notifications API Allow the platform to send notification messages to specific applications. W3C ED (Webapps) D A B bug 822712 for B2G, bug 834033 for Android
Permissions API Allow Settings app to manage all app permissions in a centralized location Future? D A B bug 707625, Security
WebFM API For FM radio feature. Future? D A B bug 749053, Security
FileHandle API Writable files with locking. Needs plan D A B bug 726593
Network Stats API Monitor data usage and expose data to privileged apps Future? D A B bug 746069
WebPayment Allow web content to initiate payments and refunds for virtual goods. For the server implementation, see WebPaymentProvider. Beginning D A B
IndexedDB Client-side storage of structured data and high performance searches on this data W3C REC (WebApps) D A B bug 553412, Security
Archive API Blob support for Zip file contents Future? D A B bug 772434
Ambient light sensor Device light sensor support W3C WD D A B bug 738465
Proximity sensor Device proximity sensor support W3C WD D A B bug 738131
SystemXHR External (non-same origin) XMLHttpRequests ? D A B ?

Planned for the future

API Bugs Description Progress Availability
Resource lock API bug 697132 Prevent resources from being turned off, for example screen dimming, WiFi turning off, CPU going into sleep mode etc. Complete.
Security Design Complete. There is renewed interest in a standard here: http://w3c.github.io/screen-wake .
UDP Datagram Socket API bug 745283 Low-level UDP API. There are patches up for review as of mid-July 2014.
USB file-reading API bug 748350 bug 737153 When enabled, allows mounting of device storage as a USB filesystem on the tethered computer. Must be complete by June/July.
Not really a webAPI, no security design.
Camera API This is part of the larger WebRTC effort. This is a big piece of work so see the link. API and implementation underway.
Security Design Complete
Peer to Peer API This is part of the larger WebRTC effort. This is a big piece of work so see the link. API and implementation underway.
WebUSB bug 674718 Low level access to USB hardware. Security Design Complete
HTTP-cache API Query what's stored in the browsers http-cache. Add/remove entries. Update expiration time. Get data directly from cache. Likely superseded by Service Workers' cache API. None
Calendar API Add/Read/Modify to the device calendar. Implementation not planned ATM. If/when implemented, it should mimic WebAPI/ContactsAPI.
Spellcheck API Enable webpages to check if a piece of text is correctly spelled as well as get suggestions for corrections. None
Background services Enable a web application to run in the background and perform tasks like syncing or respond to incoming messages. Initial proposal of API.
Security Design Active. Potentially superseded by the Service Worker-based Background Synchronization proposal.
LogAPI Allows to register the user activity on the phone. API proposal exists. Not planned for 1.0.
Keyboard/IME API bug 737110 (WebAPI mailing list post, Extended API mailing list post) Enables implementing virtual keyboards. Only exposed to certified apps for V1. Controlled via a setting instead.] D A B
DataStore API bug 871445 Shared app/site data stores with a mechanism for multiple applications to concurrently synchronize shared data into local caches Standardization: W3C ED (SysApps) D A B
Mobile Identity API bug 1021594 Allow apps to obtain a verified phone number. D A B
WebNFC bug 674741 Low level access to NFC hardware. So far focusing on NDEF support. Shipped in FxOS 1.3.
Security Design Complete 		D A B
TV API bug 998872 Allow apps to acquire the information from TV service providers as well as to manage the native TV hardwares (i.e. tuners). Shipped in FxOS 2.2. But requires explicitly turning on the preference.
Standardization: W3C ED (TV Control API) 		D A B
Presentation API bug 1184073 bug 1184036 Enable web content to access external presentation-type displays and use them for presenting web content. Shipped in FxOS 2.5 for receiver side.
Standardization: Presentation API 		D A B

Legend

D = Desktop, A = Android, B = B2G
only available to certified apps on this platform
only available to privileged and certified apps on this platform
implemented and preference enabled by default on on this platform
implemented but requires explicitly turning on the preference on this platform
not implemented for this platform
not currently planned for this platform

Process

A draft specification and prototype implementation of new Web APIs will be discussed publicly on our mailing list and at our public meetings (see below). Once we have an API that we feel that we are satisfied with, we will submit the new API for standardization to the W3C. See also tips for standardizing APIs.

The goal is to standardize all APIs.

Design Principles

Security

Security will be a central aspect of all the APIs that we design. We wouldn't want any random webpage to be able to read the user's contact list, or able to issue arbitrary commands to any USB device which is hooked up to the user's computer.

In some cases the solution will be to simply ask the user, like we do today for Geolocation for example. In other cases, where security implications are scarier or where describing the risk to the user is harder, we'll have to come up with better solutions. For example, enumerating sensitive information or exposing device specific configuration to the web can be avoided by implementing dialogs (like the file picker for <input type=file>). Those can be implemented in the platform and ask the user which information to expose to the current website specifically.

This is an area where we're still doing a lot of research. I really want to emphasize that we don't have all the answers yet, but that we plan on having them before we roll out these APIs to millions of users.

Low Level vs. High Level

One question that often comes up, is should we do low level APIs, like USB access, or high level APIs, like camera access?

In many cases we are going to want to do both high level and low level APIs, with an initial priority on low level. High level APIs will let us create more friendly APIs, which are both easier to use for developers, and better for users since we can provide better security guarantees. However low level APIs will provide support for a wider range of hardware and use cases and will get the browser out of the critical path for innovation.

Plans

Meetings

We used to have weekly meetings but as of 1 October 2014 we no longer do.

If there's something you'd like to discuss, ask on dev-webapi or contact Andrew Overholt directly to schedule something. When we do meet, we use the WebAPI Vidyo room and use irc.mozilla.org #webapi for back channel conversation. Notes are often taken on this etherpad: https://etherpad.mozilla.org/webapi-meetingnotes .

Meeting Notes

2014

Communication

Mailing-list / Newsgroup

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

And the web based archive is here: http://groups.google.com/group/mozilla.dev.webapi/topics

The newsgroup lives on the news.mozilla.org server and has the name mozilla.dev.webapi

IRC

Find us on irc.mozilla.org in #webapi. Need help to use Mozilla IRC servers?

See also

Demos

Other efforts

Subpages of WebAPI

Retrieved from "https://wiki.allizom.org/index.php?title=WebAPI&oldid=1105565"