nstrates the operational trade-offs between traditional analytics-heavy extensions and the privacy-first approach:

Approach	AMO Review Cycle Time	Data Exposure Surface	User Trust/Retention	Setup Friction	Long-term Maintenance
Traditional Analytics-Heavy	7-14 days (frequent permission queries)	High (IP, UA, usage patterns, PII risk)	Low-Medium (policy-dependent)	Low (zero-config)	High (server costs, key rotation, compliance)
Privacy-First (This Approach)	1-3 days (minimal permissions)	Near-Zero (on-device only, BYO keys)	High (auditable, zero-trust architecture)	Medium (API key entry required)	Low (no backend, static assets only)

Key Findings:

• Sweet Spot: The privacy-first model optimizes for developer sustainability and user trust at the cost of initial onboarding friction. The "enter your own API key" step filters for engaged users while eliminating backend infrastructure costs and liability.
• Trust as a Moat: Extensions that request only storage and provide MIT-licensed source code achieve higher install-to-activation ratios because the permission surface aligns perfectly with the stated utility.
• Feedback Loop Replacement: Coarse AMO metrics (total installs, weekly active users) combined with GitHub issues and AMO reviews replace granular telemetry. Roadmap prioritization shifts from data-driven feature tracking to direct user signal aggregation.

Core Solution

The architecture is built around three non-negotiable constraints: on-device state management, user-provided external dependencies, and minimal permission surface.

1. The localStorage Rule & On-Device State

All user preferences (city, timezone list, theme) are persisted exclusively via the WebExtensions browser.storage.local API. This storage is sandboxed to the browser profile and cannot be exfiltrated without explicit user action or malicious code injection.

// Storing user preference — this stays on-device
await browser.storage.local.set({
  city: userInput,
  theme: 'dark',
  clocks: [{ zone: 'America/New_York', label: 'NYC' }]
});

This data never leaves the browser. There is no backend endpoint, no telemetry pipeline, and no server to compromise.

2. The Weather API Problem & BYO Key Pattern

Weather data requires external HTTP requests. To avoid routing user requests through a developer-controlled proxy (which would expose IPs and create a single point of failure), the extension implements a Bring-Your-Own-API-Key (BYO) pattern. Users register directly with OpenWeatherMap, obtain a free-tier key, and input it into the extension settings.

Architectural Benefits:

• Zero knowledge of user location or query patterns
• Direct user-to-provider relationship (compliance & rate limiting handled by the user)
• No server infrastructure to maintain or shut down
• Immediate revocation capability by the user without developer intervention

3. Manifest V3 Minimal Permission Surface

The extension requests only the storage permission. No tabs, history, activeTab, or <all_urls> permissions are declared. This aligns perfectly with AMO review criteria and signals strict functional scoping.

{
  "manifest_version": 3,
  "permissions": [
    "storage"
  ],
  "chrome_url_overrides": {
    "newtab": "dashboard.html"
  }
}

4. Open Sourcing as a Privacy Signal

MIT licensing and public source code function as executable privacy documentation. Users, security researchers, and AMO reviewers can verify network requests, storage patterns, and permission usage directly. The absence of obfuscation or proprietary binaries eliminates trust assumptions.

Pitfall Guide

1. Over-Requesting Permissions: Declaring <all_urls> or tabs "just in case" triggers AMO rejection and user distrust. Only request permissions that are strictly necessary for core functionality. Use optional permissions or host permissions only when dynamically required.
2. Hardcoding Third-Party API Keys: Embedding API keys in extension code creates a centralized failure point and violates user privacy by routing requests through your infrastructure. Implement a BYO key pattern or use user-configurable endpoints.
3. Assuming "Anonymized" Analytics is Safe: Stripping PII from telemetry does not eliminate fingerprinting risks or GDPR/CCPA compliance overhead. If you don't need the data to ship the product, don't collect it. Privacy-first means designing constraints before implementation.
4. Ignoring AMO Review Criteria: Mozilla reviewers validate permission necessity, network request destinations, and code transparency. Submitting extensions with vague privacy policies or unexplained external calls guarantees review delays. Document every network request and permission in the submission notes.
5. Neglecting Alternative Feedback Channels: Removing analytics eliminates granular usage data. Compensate by building explicit feedback mechanisms: GitHub issue templates, AMO review monitoring, and in-extension "report a bug" links. Prioritize roadmap items based on direct user signals, not inferred behavior.
6. Treating Privacy as a Post-Development Feature: Privacy cannot be retrofitted. If your architecture assumes server-side data collection, stripping it out later requires rewriting state management, API routing, and authentication flows. Define privacy constraints during the initial architecture phase.

Deliverables

• Privacy-First Extension Architecture Blueprint: A step-by-step architectural guide covering on-device state management, BYO API key implementation, Manifest V3 permission scoping, and AMO submission preparation. Includes threat modeling templates for extension security boundaries.
• AMO Compliance & Privacy Audit Checklist: A pre-submission validation checklist covering permission justification, network request documentation, storage schema verification, open-source licensing requirements, and reviewer communication templates.
• Configuration Templates: Ready-to-use manifest.json scaffolds for minimal-permission extensions, browser.storage.local schema definitions with TypeScript interfaces, and environment configuration templates for user-provided API key validation and error handling.