Skip to content

CONCEPT Cited by 1 source

Plugin marketplace lock-in

Definition

Plugin marketplace lock-in is the structural dynamic where an insecure-by-default plugin architecture forces a centralised marketplace to provide the trust that the platform runtime cannot provide itself. Once the marketplace is the trust layer, participation-to-be-trusted and licensing / distribution constraints become coupled, and plugin authors lose the freedom to publish + monetise independently of the marketplace.

Named in Cloudflare's 2026-04-01 EmDash launch post as the structural problem EmDash's capability-based sandbox is designed to dissolve.

The cycle

  1. Plugin architecture has no isolation. Plugins run with full ambient authority (database, filesystem, network, process). Installing a plugin means trusting it with everything the platform holds.
  2. Trust must come from somewhere. Users can't meaningfully audit plugin code at install time. Ratings + reviews are weak signals. The platform owner steps in with a manually curated marketplace: each plugin is reviewed by the platform before listing.
  3. Marketplace review is the trust bottleneck. At WordPress.org scale: "review queue is over 800 plugins long, and takes at least two weeks to traverse." This is the only practical way for the plugin to be broadly trusted.
  4. Licensing becomes coupled to trust. Because plugins run in the same execution context as the platform and are deeply intertwined with platform code, there are arguments that plugins must inherit the platform's license (the WordPress / GPL example; "some argue they must carry forward WordPress' GPL license").
  5. Commercial constraints follow licensing. GPL + marketplace-as-trust-channel together restrict how plugin authors can charge for their work outside the marketplace. The author can give the code away and charge elsewhere, but cannot hold code private.
  6. Chilling effect. The result is "a chilling effect on developers building plugins, and on platforms hosting WordPress sites." Fewer authors, fewer plugins, less innovation than the ecosystem could otherwise support.

Why the capability sandbox breaks the cycle

A capability sandbox (e.g. a Dynamic Worker running a plugin with a capability manifest) breaks step 1:

  • Plugins run in isolated sandboxes. No ambient authority.
  • The manifest declares capabilities. The user can inspect what's being granted at install time.
  • Capability boundaries are runtime-enforced. The plugin literally cannot exceed the manifest.

Consequences rippling forward:

  • Plugins can have any license. They run independently and share no code with the host; licensing is the plugin author's choice.
  • Trust doesn't have to come from the marketplace. The platform's runtime enforces the boundary; the user's install-time manifest inspection is the audit. Multiple competing marketplaces (or none at all) become viable.
  • Plugin code can be trusted without being seen. "A plugin can be provided to an EmDash site, and trusted, without the EmDash site ever seeing the code." Authors can ship closed-source, paid plugins without compromising the site's security posture.

The restaurant-food-safety analogy

Cloudflare makes the argument with a metaphor worth preserving verbatim:

"Marketplace businesses provide trust when parties otherwise cannot easily trust each other. … If you trust that food safety is enforced in your city, you'll be adventurous and try new places. If you can't trust that there might be a staple in your soup, you'll be consulting Google before every new place you try, and it's harder for everyone to open new restaurants."

The sandbox is the city's food-safety code. Once it's enforced, trust scales without a centralised rating authority.

Contrast with npm / PyPI / Packagist

These registries are distribution channels, not trust channels. They host packages but don't vet them; responsibility for trust (via lockfiles, SCA, SBOMs, reputation) is with the consumer. This works because the execution context of a library is controlled by the consumer's code: import it and use only what you want. Plugins in systems like WordPress don't have that property — the plugin becomes part of the host's execution context.

A capability-sandboxed plugin is structurally closer to an npm library than to a WordPress plugin: the host decides what it exposes; the plugin can only do what it's given. The coupling of license-to-trust collapses.

Not-yet-addressed concerns

Breaking the marketplace-as-trust cycle does not remove all reasons a marketplace might exist:

  • Discovery. Users still need to find plugins.
  • Updates and security bulletins. Coordination on bug fixes, CVE dissemination.
  • Billing and payment infrastructure. Charging for paid plugins.
  • Reputation signalling. Even with capability sandboxing, users want reviews and ratings.

A capability sandbox decouples trust-requiring-GPL from a platform's plugin ecosystem, but it does not eliminate the utility of marketplaces per se. It pushes them back toward their npm-like role (distribution + discovery) and away from their WordPress-like role (centralised trust bottleneck).

Seen in

Last updated · 200 distilled / 1,178 read