Locara

Chrome Web Store

What it is: Marketplace for browser extensions, themes, and Chrome apps. Manifest-based capability declarations, automated + human review, periodic policy purges. Status: Mature, dominant for browser extension distribution. Recently went through painful Manifest V2 → V3 transition. Most relevant to Locara: The closest analog to a manifest-driven, capability-declared, sandboxed app store. Steal the manifest pattern; learn from the V2→V3 trauma.

Background

The Chrome Web Store launched in 2010. Extensions are essentially small web apps loaded into the browser with elevated capabilities (read pages, modify DOM, intercept network, etc.). Each extension ships with a manifest.json declaring permissions and host access; Chrome enforces those permissions.

The 2018-onward transition from Manifest V2 → V3 was forced by security and performance concerns (notably blocking arbitrary remote code execution from extensions and tightening the webRequest API used by ad blockers). It’s been controversial because it broke a lot of legitimate use cases (especially uBlock Origin’s classic deep-blocking ability) while solving real problems.

Key design decisions

  • manifest.json as the central spec. Declares name, version, permissions, host permissions, scripts, content scripts, action UI, etc.
  • Permissions categories: runtime permissions (storage, alarms, etc.), API permissions (tabs, history, bookmarks), and host permissions (which sites the extension can read/modify).
  • Granular host permissions — <all_urls> triggers stronger review and a scary install prompt; *.example.com is more limited.
  • Single purpose policy. An extension should do one thing. Multi-purpose extensions are rejected.
  • Automated review for most submissions + human review for high-risk (broad permissions, financial features, Hot Word).
  • Manifest V3 mandates service-worker background scripts instead of persistent background pages. Killed entire classes of extensions; forced architectural rewrites.
  • Periodic policy purges. Mass-deletes of low-quality, abandoned, or clone extensions every few years.
  • Verified developer badge for established/known authors.

What worked

  • Manifest pattern is industry-defining. Chrome’s manifest.json model has been adopted by Firefox/Edge/Safari extensions, npm packages (in shape), and many other ecosystems.
  • Host permissions force extensions to declare which sites they touch — visible to users at install.
  • Single purpose policy keeps extensions reasonable in scope.
  • Manifest V3 (eventually) reduced legitimate malware vectors — banning remote code execution closed a major class of supply-chain attacks.
  • Periodic purges keep store quality from collapsing under accumulated abandonware.

What failed / criticisms

  • MV3 transition was an extended trauma. Years of dev confusion, broken extensions, hostile communication from Google. Damaged trust significantly.
  • MV3 motivations seen as anti-ad-blocker by community. Real or not, the perception persists.
  • Inconsistent enforcement of single purpose policy.
  • Permission UX is poor — install-time permission lists scare users without clearly explaining tradeoffs.
  • Clones and copycats evade automated review by varying just enough.
  • Compromised-extension supply chain. Major incidents where popular extensions were sold to bad actors who pushed malicious updates. Users had no warning.
  • Extension-as-malware vector for credential theft, ad injection, browser hijacking — recurrent problem.

Specific learnings for Locara

  1. manifest.json pattern is correct. Locara’s manifest should look like Chrome’s: declarative, JSON, includes name/version/permissions/scripts. Already the plan.
  2. Granular capability declarations matter. Don’t just have filesystem: true. Have filesystem.read: ["~/Documents/receipts"] and enforce paths. Like Chrome’s host permissions.
  3. Single purpose policy = a great fit for Locara. The “narrow, opinionated apps” thesis aligns. An app that’s “transcribe + photo edit + game” gets rejected.
  4. Compromised extension story is the cautionary tale. Once an app becomes popular, it becomes valuable to attackers. Locara needs:
    • Multi-factor publisher auth required for app updates.
    • Mandatory cool-down period before significant capability expansions take effect (e.g., new network access requires 7-day notice + user re-consent).
    • Immutable signing — every release signed, signatures verifiable, history visible.
    • Transferring app ownership is a high-trust event that requires Locara review.
  5. Avoid Chrome’s manifest churn. Plan the manifest schema for evolution from day one. Use semver, support multiple schema versions concurrently. Don’t ever do an MV3-style hard cutover.
  6. Automated review can scale; human review for risk. Same pattern Chrome uses. Locara should auto-approve low-risk capability sets, escalate high-risk to human review (initially you).
  7. Periodic store hygiene — abandoned apps, zero-install apps, broken-on-current-OS apps should be culled or marked. Don’t let the catalog rot.
  8. Communicate changes early and clearly. Chrome’s MV3 communication was a disaster; learn from it. Any breaking change to Locara’s manifest spec should ship with months of lead time, migration tooling, and clear rationale.

References