WebExtensions/policy: Difference between revisions

This document outlines the policy surrounding the WebExtensions API and aims to provide guidance on what makes a good API. When a change to the WebExtensions API is proposed, this document should be consulted to determine if the change makes sense. Changes can include adding a new API, changing an existing API, and/or removing (deprecating) an API.  This process is necessary if you intend to make "substantial" changes to the WebExtensions API. What constitutes a "substantial" change evolves based on community norms and varies depending on what part of the ecosystem you are proposing to change, but may include the following:

* Adding an API to expose new areas of browser control or customization

This document only helps answer the question of '''''should''''' something be part of the WebExtensions API. It does not cover the actual process of '''''how''''' something becomes part of the WebExtensions API.

The process of maintaining and improving the WebExtensions API is a joint exploration of design space and tradeoffs, and requires consensus-building. The process is at its best when all participants recognize that people have differences of opinion and that every design or implementation choice carries a trade-off. There is seldom one right answer.

People wishing to participate in the definition and development of the WebExtensions API, including both Mozilla staff and community members, are expected to adhere to the [https://www.mozilla.org/en-US/about/governance/policies/participation/ Mozilla Community Participation Guidelines]. These guidelines offer advice on how to participate in a healthy and constructive manner and also include language about harassment and marginalized groups.

When evaluating changes or additions to the WebExtensions API, the following items will be considered:

:: ''Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent.''

:* ''Does this API align with the Mozilla mission?''

: Any API that could weaken a user’s security or compromise their privacy will be examined with extreme scrutiny. It often helps to imagine what nefarious things could be done with the API since, unfortunately, that is likely to happen. It is important to not just consider the proposed API in isolation, but also how the proposed API might be used in conjunction with other API to circumvent security and privacy controls.

:* ''Will the user know if an API has taken control of a browser feature?''

: An API that appeals to a broad audience is always preferred, although certain API that can demonstrate they empower a narrow but important set of extensions will also be considered. In all cases, though, the API needs to bring value to users of the browser.

:* ''For changing/deprecating an API, how many extensions use the API? How many users does that represent?''

: High-level APIs that are not tied to specific implementations or designs are better.  An abstract API can exist independent of any particular user interface or platform. Within a browser this promotes maintainability, since the WebExtension API can remain constant even if the underlying implementation changes. In addition, an API that is defined at a high-level promotes cross-browser adoption.

:* ''Could other browsers potentially adopt this API, if desired?''

: Every new API comes with some cost. What is that cost? Maybe it increases technical complexity, has a steep learning curve, or impacts the user experience in some way. While it is hard to enumerate all the possible ways that an API could have some downside, here are some common areas to think about.

:* ''Does the API impact security or privacy (repeated, because it’s important)''

: Preference will be given to APIs that open up functionality previously unavailable to developers. New APIs that simply make things easier will be considered, but should demonstrate significant savings in other areas such as extension development time or future support.

:* ''Why is the proposed API better than existing alternatives, if any?''

The set of criteria listed above outlines the policy and guidelines regarding what should or should not be a WebExtensions API. Even if an API meets all of the criteria, it does not mean it will end up being implemented and supported by Firefox.