When I built Weather & Clock Dashboard for Firefox, I made a decision early on: no analytics, no accounts, no external calls except weather data.

Here's what I learned about building browser extensions with privacy as a design principle — and why I think more extension developers should take this approach.

The Default is Data Collection

Most web development assumes you want to know who your users are. Analytics platforms are one npm install away. A/B testing, session recording, funnel analysis — the infrastructure for surveillance capitalism is baked into the default developer tooling.

Browser extensions are in a privileged position. They run inside the browser, they can see your tabs (with permission), they load on page visits. An extension with analytics has more access to your behavior than a typical website.

What Privacy-First Actually Means

For my extension, I set these constraints:

1. No analytics scripts
2. No external requests except weather API (user-configured, optional)
3. No user accounts
4. No localStorage of personally identifiable information
5. MIT licensed — code is auditable

The localStorage Rule

The extension stores settings: your preferred city, timezone list, theme preference. But these settings live only in your browser, via browser.storage.local.

// 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. It can't. There's no server to send it to.

The Weather API Problem

Weather is a hard case. To show current weather, you need to call an external API — there's no way around it. That external API will see your IP address.

My solution: require users to bring their own API key. Weather & Clock Dashboard uses OpenWeatherMap's free API tier. Users create their own account and enter their own API key.

This means:

• I have zero knowledge of what city any user is in
• OpenWeatherMap has a direct relationship with the user (their own account)
• I have no API key to revoke if I need to shut down a server

The tradeoff: higher setup friction. Some users bounce when they see "enter API key." That's a cost I'm willing to pay.

The AMO Review Benefit

Mozilla's Add-ons review process (for Firefox) actually rewards privacy-respecting extensions. Reviewers check:

• What permissions the extension requests
• What external requests it makes
• Whether the permissions are necessary for the stated functionality

An extension that requests <all_urls> permission but only needs to show weather will get questions. An extension with no permissions beyond storage sails through.

The User Trust Payoff

Privacy-first design communicates trust before users read a single word of your privacy policy. When I see an extension that:

• Requires no account
• Requests minimal permissions
• Is open source
• Has been reviewed by Mozilla

...I trust it immediately. That trust is the product.

For extensions specifically, trust is the moat. Users install things that run inside their browser. The bar for trust should be high.

The Technical Implementation

Here's the manifest for Weather & Clock Dashboard — notice what permissions are and aren't requested:

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

No tabs, no history, no <all_urls>. Just storage to save preferences. That's the entire permission surface.

Analytics Without Surveillance

I do want to know how many people are using the extension. AMO's install count is my only metric, and it's coarse. I can see total installs and a weekly active user count — nothing more granular.

For a lot of developers, this is unacceptable. How do you optimize UX without knowing which features are used? How do you prioritize roadmap?

My answer: user feedback channels (GitHub issues, AMO reviews) and intuition. It's less data-driven. I'm okay with that.

Open Sourcing as a Privacy Signal

MIT licensing and public source code is a form of privacy documentation that no privacy policy can match. Users can verify that the code does what it claims. Researchers can audit it. Security professionals can check for vulnerabilities.

The source code is on GitHub. I'm comfortable with anyone reading it.

Conclusion

Building privacy-first isn't a technical constraint — it's a design decision made before you write the first line of code. The constraint is deciding what you won't collect, not figuring out how to anonymize what you do.

For browser extensions especially, privacy-first design is also good product design. Users are rightfully suspicious of extensions. Being genuinely privacy-respecting — not just claiming to be — is a real differentiator.

Install Weather & Clock Dashboard if you want to see this in practice.