Passive revenue from a Chrome extension’s idle bandwidth

Chrome extensions are simultaneously high-leverage and hard to monetize. A single popular extension can have hundreds of thousands of users, but the Web Store has no IAP, ads inside extensions are restricted, and paid extensions barely sell. This guide describes a different revenue layer: an opt-in background bandwidth integration that runs alongside a Manifest V3 service worker and earns based on idle browser time, not impressions.

The model fits Chrome, Edge, Brave (Chromium-based), and ports to Firefox with small adjustments. It survives Web Store review when implemented as described.

Why most extension monetization is broken

Extension developers have a small menu of revenue options:

• Paid extension. Almost no one buys a paid extension; the Chrome Web Store closed paid distribution in 2020 anyway.
• Affiliate links. Works for shopping-adjacent extensions, useless for the rest.
• Sponsored entries / partner placements. Possible for some categories, hostile to user trust in others.
• Donations. Sustains a small minority of extensions with a passionate user base; not a model for most.

That leaves ads (restricted by the Web Store and damaging to UX inside an extension), or finding a revenue layer that does not depend on user impressions at all. Background bandwidth revenue, with explicit consent, is one of the only models that fits cleanly here.

How the Manifest V3 architecture fits

MV3 deliberately makes long-running background pages impossible. The service worker spins down when idle, which means a JS-only background bandwidth implementation inside an MV3 extension would constantly be evicted by the browser. The standard solution is to combine the service worker (for consent lifecycle and UI events) with a native messaging host (for the actual network work) that runs as a small process on the user’s machine.

The service worker handles:

• Onboarding flow at first install.
• Consent state persisted in chrome.storage.
• Options-page toggle for revocation.
• Lifecycle messages to the native host (start, stop, status).

The native messaging host handles:

• The actual background work, on its own native thread.
• Reporting up to the developer console.
• Yielding under sustained CPU load.
• Hard stop when the service worker says stop.

The native host is a small signed binary installed during onboarding via the standard native messaging protocol. The user explicitly accepts the host’s presence as part of the install flow.

Manifest excerpt

A minimal MV3 manifest entry for the integration:

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0.0",
  "background": {
    "service_worker": "background.js"
  },
  "permissions": [
    "storage",
    "nativeMessaging"
  ],
  "options_ui": {
    "page": "options.html",
    "open_in_tab": false
  }
}

The single-purpose declaration in the Web Store listing covers your extension’s primary purpose. The background revenue layer is disclosed in the listing description and Terms and Conditions as a secondary, opt-in feature.

Service worker bootstrap

A simplified background.js for the lifecycle:

// background.js
import { GetPassiveHost } from './getpassive-host.js';

chrome.runtime.onInstalled.addListener(() => {
  chrome.tabs.create({ url: 'onboarding.html' });
});

chrome.storage.onChanged.addListener(async (changes) => {
  if (changes.termsAccepted) {
    if (changes.termsAccepted.newValue === true) {
      await GetPassiveHost.start();
    } else {
      await GetPassiveHost.stop();
    }
  }
});

(async () => {
  const { termsAccepted } = await chrome.storage.local.get('termsAccepted');
  if (termsAccepted === true) {
    await GetPassiveHost.start();
  }
})();

The GetPassiveHost module is a thin wrapper over chrome.runtime.connectNative() that opens a connection to the native messaging host and forwards lifecycle messages.

Cross-browser portability

Edge and Brave use the same Chromium extension model. The same MV3 manifest and service worker port without changes. The native messaging host registration paths differ slightly per browser (different registry locations on Windows, different system paths on macOS), but the protocol and JS-side API are identical.

Firefox uses the WebExtensions API with some differences in MV3 timing. The lifecycle pattern translates with small adjustments. The consent UX is the same.

Consent UX inside an extension

The pattern that works in extensions:

1. On first install, the service worker opens an onboarding tab.
2. The onboarding page shows the extension’s primary value proposition, then the Terms and Conditions with the bandwidth disclosure block, then an accept button.
3. Acceptance writes termsAccepted: true to chrome.storage.
4. The service worker listens for the storage change and starts the native host.
5. The options page has a clear toggle for revocation, which writes termsAccepted: false and stops the native host.

The onboarding page is the only UI the SDK’s presence adds to your extension. No banner, no badge, no popup, no notification. The user sees the disclosure once at first install and the toggle in options.

Realistic earnings for a Chrome extension

Earnings depend on active installs and the regional mix. The browser is online when the user’s machine is online, so the per-device productive time is high for desktop users.

• 1,000 active installs, mixed regions: roughly $20–$80 per month.
• 10,000 active installs, mixed regions: roughly $200–$800 per month.
• 50,000 active installs, with healthy regional skew: roughly $800–$4,000 per month.
• 100,000+ active installs, US/UK/EU concentration: sit at the top of the range, scaling with active hours.

These ranges assume a desktop browser; extensions on mobile (Edge Android, Kiwi) earn less per device because the phone is offline more often.

Web Store review considerations

The Web Store policies you have to satisfy:

• Single purpose. Declare your extension’s primary purpose; the revenue layer is a secondary opt-in feature.
• Clear disclosure. The Web Store listing description must mention the bandwidth revenue layer in plain English.
• No deceptive behaviour. The onboarding consent is explicit; the toggle is visible; the host can be uninstalled.
• Permissions justification. The nativeMessaging permission needs a one-line justification in the Web Store form.
• Privacy policy. Link to a privacy policy that names the data categories the integration uses (IP, approximate region, pseudonymous device identifier, traffic metadata).

Extensions that hit rejection usually do so because the disclosure was buried or the native host was installed without explicit consent. Done properly, the model passes review.

The takeaway

Chrome extensions have very few viable monetization models, but a consent-bound opt-in background bandwidth layer is one of the cleanest. It works with MV3 through the service-worker-plus-native-host pattern, fits Web Store policy when properly disclosed, and earns based on idle browser time across a global install base. For extension developers with active users and limited monetization options, it is one of the few revenue layers worth integrating.

For related reading, see our ethical consent guide and our ad-free monetization guide. For the desktop integration details, see our desktop SDK page.

FAQ

Can a Chrome extension legitimately participate in a background bandwidth model?

Yes, with explicit user consent, clear Web Store disclosure, and a single purpose declared in the manifest. The Web Store does not ban background bandwidth participation; it bans hidden, undisclosed, or misleading background activity. A consent-first model with a visible settings toggle satisfies the relevant policies.

Does this work under Manifest V3?

Yes. The integration runs out of a service worker plus a companion native messaging host on the user’s machine for the actual network capacity. The service worker handles consent state and lifecycle; the native host performs the work without keeping the service worker permanently alive.

What about Firefox, Edge, and Brave?

Edge and Brave use the same Chromium extension model and the integration ports directly. Firefox uses a different background script model but the consent and native messaging patterns translate. The earnings per device differ slightly because of usage patterns; the integration approach is similar.

How is consent surfaced in an extension?

At first run, the extension shows an onboarding page that includes the Terms and Conditions with the disclosure block. The user accepts there. Consent state is persisted in chrome.storage.sync or chrome.storage.local; the SDK only starts when the persisted state is granted. A visible options-page toggle lets the user revoke at any time.

How much can a Chrome extension earn?

It depends on active install count and the regional mix of users. A 5,000 install extension with a global audience earns roughly $100 to $400 per month from the background layer. A 50,000 install extension earns roughly $800 to $4,000. Earnings scale with active browser time, not impressions or clicks.