Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Thick Applications: Unifying WebExtensions with the Web platform and moving beyond injections

Paul Frazee edited this page Jun 1, 2017 · 7 revisions

The WebExtensions API is the Web's solution to integrate apps with the browser and OS. It has enabled adblockers, password managers, and productivity plugins. However, WebExtensions have two key downsides:

  1. WebExtensions are not browsable. They must be installed manually or through vendor stores (ie addons.mozilla.org).
  2. WebExtensions rely on page-injection. Most extensions add behaviors to Websites by injecting 'content scripts' into pages.

In Beaker, we want Web applications to work without remote hosts. We call this the "Thick Web Applications" model.

This page will explore a proposal to use a subset of the WebExtensions API in Beaker as the basis of the Thick Web model.

Motivation

To provide useful Thick Web applications which can integrate with the browsing experience, developers need contextual UIs (#484, #485), intent-based action hooks, and advanced APIs (eg a TCP interface for an IRC client). Many of these behaviors are currently covered by the WebExtensions API, making it a good basis for these tasks.

However, the page-injection model of WebExtensions is brittle and high-risk. 'brittle' because the injections operate on the DOM directly, rather than a public interface. 'high-risk' because the injections are given access to the memory-space of the application they're accessing.

We believe that page-injection to modify behaviors is unnecessary when it's possible to fork websites. Therefore, we would remove content scripts.

We also believe that, by hosting ThickApps over a protocol that verifies content integrity, we make it possible for security-reviews to occur on the open Web, making the vendor store unnecessary.

Compared to WebExtensions

Similarities

Differences

Can page-injection be replaced?

We believe that page-injection to modify behaviors is unnecessary when it's possible to fork websites.

The theory here is, if you want to modify the application behavior, you can do so by either A) forking the site and making your own version, or B) providing an extension via a well-defined interface.

However, there are two things that page-injection support obviously: multiple extensions at once (so long as nobody breaks anybody else) and extensions across multiple sites (adblockers, password managers). Our wager is that page-injection is not the long-term solution to a rich Web platform, and that these issues are more solvable without injections.