Apple, Mozilla, Google and Microsoft join forces to standardize web extensions within the WebExtensions Community Group (WECG)

Like Microsoft Edge before the switch to the Blink rendering engine (used by Google Chrome among others), one of Safari’s weak points (both on macOS and Windows) was the small number of extensions available to users. The reason is simple: given the popularity of the Google Chrome browser, many developers prefer to create extensions for Chrome (and which in turn are compatible with all browsers relying on the Blink rendering engine like Opera, Vivaldi and many others). ).

Also, Apple reminded developers in August 2020 that they can create web extensions in Safari 14 using the same WebExtensions API used in other browsers, such as Chrome, Firefox, and Edge. The editor took the opportunity to tell them that a porting tool in Xcode 12 bta is made available to them; the new converter tool in Xcode 12 bta also allows developers to port existing extensions from other browsers to Safari and make them available on the Mac App Store later this year.

In the documentation, Apple explains that a Safari web extension adds custom Safari functionality using JavaScript APIs and file formats commonly used in extensions for Google Chrome, Mozilla Firefox, and Microsoft Edge browsers. While Safari app extensions are useful for sharing code between your native macOS app and Safari, Safari web extensions are mostly built on JavaScript, HTML, and CSS, and can be repackaged to work in other browsers.

By opening WebExtensions, Safari was therefore able to use the extensions developed for Chrome and Firefox! Apple provided a conversion tool, but unfortunately this new feature in Safari 14 for Mac, launched with Big Sur, was not as successful as expected. This time around, the company has taken a different approach by choosing the alliance with other technology companies.

Creation of the WebExtensions community group

The new WebExtensions community group will attempt to forge a common architecture for future web extensions and invites developers to join this initiative. Safari has adopted a new Web Extension API with macOS Big Sur that allows extensions designed for other browsers to work with it. This opened the door for new extensions, but a standardized method of developing extensions had not been defined.

The new group, abbreviated as WECG, is made up of members from each of the major browser developers. At the head of this new group, we find Timothy Hatcher from Apple and Simeon Vincent from Google. Current participants include employees from Apple, Mozilla and Microsoft.

The World Wide Web Consortium, the body responsible for promoting the compatibility of technologies of the World Wide Web, has how this action in these terms:

We are excited to announce the launch of the WebExtensions Community Group (WECG). With several browsers adopting a widely compatible model for extensions over the past few years, WECG is excited to explore how browser vendors and other interested parties can work together to advance a common browser extension platform. Apple, Google, Microsoft and Mozilla are launching this community group, and we invite other browser editors, extension developers and interested parties to join this initiative *!

5e705cde1f.jpg

The WebExtensions community group has two objectives *:

  • Make it easier for developers to build extensions by specifying a consistent model and a common core of features, APIs, and permissions.
  • Describe an architecture that improves performance and is even more secure and resistant to abuse.

Our work will be guided by a common set of HTML and W3C TAG * design principles: user-centric, compatibility, performance, security, privacy, portability, maintainability, and well-defined behavior.

Using the existing extensions model and APIs supported by Chrome, Microsoft Edge, Firefox, and Safari as a basis, we’ll start by working on a specification. We aim to identify common ground, bring implementations closer together and chart a course for future evolution.

On the work charter, the following design principles are mentioned:

  • User-centric: Browser extensions allow users to customize their web browsing experience according to their preferences and needs. [Les gens devraient pouvoir restituer le contenu Web comme ils le souhaitent] [Internet est pour les utilisateurs finaux]. We will specify extension APIs that allow developers to write a variety of useful browser extensions. In the event of a conflict, we will prioritize the needs of end users over the needs of developers and implementers.
  • Compatibilit : We strive to maintain and improve compatibility with existing extensions and popular extension APIs. [Prise en charge du contenu existant] This will prevent developers from having to completely rewrite their extensions to work in different browsers, which can be prone to errors. [Ne pas rinventer la roue]
  • Performance : We need to allow developers to write extensions that don’t have a negative impact on the performance or power consumption of web pages or the browser. [Le web doit tre une plateforme cologiquement durable]
  • Security: When choosing which extensions to use, users should not have to compromise between functionality and security. We will specify new extension APIs, make model changes, and improve permissions to promote good security practices and reduce the damage that compromised or malicious browser extensions can cause. [La scurit et la confidentialit sont essentielles]
  • Private life : Likewise, users should not have to compromise between functionality and privacy. We will allow browser extensions to enhance the user experience while requiring the minimum necessary access to user browsing data in order to reduce or eliminate the tradeoff end users have to make between functionality. and confidentiality. [La scurit et la confidentialit sont essentielles]
  • Portability: It should be relatively straightforward for developers to port extensions from one browser to another, and for browsers to support extensions on a variety of devices and operating systems. [Le Web est multi-navigateur, multi-OS et multi-appareils] [Indpendance des mdias]. We will keep the number of UI entry points to a minimum to avoid locking implementers into overly limited UI models. This helps ensure that extensions work across browsers, devices, and UI paradigms. Our specifications should not refer to or rely on specific browser engine implementation details.
  • Maintainability: We will strive to simplify our APIs, allow the widest group of developers to create extensions, and make it easier for them to maintain the extensions they create. We will keep the number of API extensions adopted to a minimum and only review these APIs infrequently, in order to keep the maintenance cost of the extensions as low as possible. [Le Web doit amliorer le contrle et le pouvoir des individus] [viter la complexit inutile]
  • Well-defined behavior: We will rigorously define the behavior of extension APIs to allow browser developers to achieve interoperability as much as possible. [Comportement bien dfini]
  • Autonomy: We recognize that browser vendors must provide functionality specific to their browser and must also have the ability to experiment with new functionality. Our process embraces this and seeks to provide mechanisms for specifying inconsistencies and working towards possible unification, where appropriate. In view of this, we expect browser vendors to offer APIs and capabilities beyond what is specified. Of course, the need for autonomy must be balanced against the need to provide developers with a coherent and interoperable platform. To this end, we seek to specify a common platform that includes the base extension model, the permissions model, and a common API core for web extensions that all browsers can rely on.

The group does not want to specify all aspects of the web extensions platform or stifle innovation. Each browser vendor will continue to operate independently with their own policies. Developers and browser vendors interested in contributing to the group can register through the W3C website. The WECG has a dedicated GitHub repository with a work charter and the achievements of the community.

We will have to see if Apple wants to alleviate some of the constraints imposed on developers for Safari. Developers must register for the annual program (99 per year), use a Mac, use Xcode, and manage signature and packaging processes which are not particularly fluid.

Follow the progress of the project

Sources: W3C announcement, work charter

And you ?

How do you read it? User-friendly progress in standardization, or the creation of a powerful new commercial cartel?

 
For Latest Updates Follow us on Google News
 

PREV China confirms launch of three astronauts to space station
NEXT already 134,000 apps and 4 million developers according to Huawei