Silencing Google Firebase Permissions, Notifications

A notification interrupts your work. You dismiss it, return to your task, and later another appears, or the same website asks again whether it can send alerts. If the application uses Firebase, it is tempting to look for a single “silence Firebase” switch.

There is no universal switch, because several different systems are involved. Browser notification permission, Firebase Cloud Messaging subscriptions, operating-system notification controls, and Firebase project alerts each have their own settings. Choosing the right one lets you stop interruptions without accidentally breaking authentication or weakening data security.

This guide describes approaches available in 2019; tools, APIs, and interface labels may have changed since then.

What are you actually trying to silence?

Firebase is a platform for building applications. Its database, storage, authentication, and messaging services do not all request access through browser pop-ups.

In particular, Firestore, Realtime Database, and Cloud Storage use authorization mechanisms such as Firebase Security Rules. Those rules determine which requests an application may make; they are not browser notification permissions.

Before changing anything, identify the interruption:

| What you see | Likely source | Appropriate control | | --- | --- | --- | | “This site wants to show notifications” | Browser notification permission | Site permissions or application opt-in code | | A desktop notification from a website | Browser push, possibly delivered through FCM | Website notification settings or browser controls | | A banner inside an application | Application interface | Application preferences or display logic | | A notification from an Android or iOS app | Native application notifications | Device settings and application preferences | | An email about your Firebase project | Project, product, or account alerting | The relevant alert or email settings | | “Permission denied” in a developer console | Authorization or configuration failure | Debugging, not notification settings |

The important distinction is between permission, delivery, and display. Permission allows notifications; an FCM registration token identifies a messaging destination; application and platform behavior determine what becomes visible.

For users: stop website prompts and notifications

You do not need access to a Firebase project to silence notifications from a website that uses it.

1. Identify the website responsible

Look at the website name or origin shown in the notification or permission prompt. Notification permission belongs to that origin, not to Firebase as a whole.

For example, if an application runs at https://app.example.com, start with that site's permissions. Blocking firebase.google.com will not silence unrelated applications simply because they use Firebase behind the scenes.

If you maintain several browser profiles, check the profile that received the notification. Each can have different permissions.

2. Block notifications in the browser

In browsers available in 2019, the relevant controls are generally found here, although exact labels vary by version:

Chrome: Open Settings, expand Advanced if necessary, then find Privacy and security → Site Settings or Content settings → Notifications. Remove the site's existing allowance or set it to Block.
Firefox: Open Options or Preferences → Privacy & Security → Permissions → Notifications → Settings. Change the site's status to Block and save.
Safari on macOS: Open Preferences → Websites → Notifications, then deny the relevant website.

In Chrome, chrome://settings/content/notifications provides a direct route to notification settings. You can also open the affected website and use the site-information control beside its address to inspect permissions.

Where supported, turn off requests from new websites if you never want notification permission prompts. This is broader than blocking one application, so consider whether you still need alerts from other sites.

Safari has its own website notification system in this period; these browser controls do not imply that Safari supports the same Firebase web messaging integration as Chrome or Firefox.

3. Check the application's own preferences

A website may offer controls for mentions, reminders, marketing messages, or other categories. These can be more useful than a blanket block.

Prefer application settings when you want to keep important alerts but remove low-value ones. Prefer browser blocking when you want no system notifications from that origin.

An application's custom “Enable notifications” banner is different from the browser's permission dialog. Blocking browser notifications may not hide that banner if the application is poorly designed.

4. Use operating-system controls when appropriate

For temporary quiet, use the operating system's Do Not Disturb or equivalent mode. This usually suppresses presentation without changing the website's permission.

For native apps, use the app's notification settings on Android or iOS. Android 8.0 and later also support notification channels, allowing users to silence categories when the application exposes them.

These controls affect presentation. They do not necessarily unsubscribe the device from messaging or stop background application activity.

For developers: stop asking at the wrong time

The most effective way to silence unwanted permission prompts is not to trigger them automatically.

A notification request on the first page load asks for trust before the user understands the benefit. Repeating a custom prompt after refusal makes the experience worse, even when the browser prevents another native permission dialog.

1. Make notification enrollment an explicit action

Offer a clearly labeled button in context: “Notify me when this export finishes,” for example. Explain the purpose before invoking the browser permission request.

Use the browser's permission state to decide what to show:

function notificationStatus() {
  if (!("Notification" in window)) {
    return "unsupported";
  }

  return Notification.permission;
  // "default", "granted", or "denied"
}

Treat these states differently:

default: The user has not granted permission. Offer an optional enrollment action.
granted: Permission exists, but the user may still have disabled notifications inside your application.
denied: Do not keep requesting permission. Explain how to change browser settings only if the user asks to enable notifications.
unsupported: Hide or disable the feature gracefully.

Permission is not the same as a preference. Store an application-level choice as well, especially when users can opt out without revoking browser permission.

2. Request permission only from the opt-in flow

The following example uses the namespaced Firebase JavaScript SDK style available in 2019. It assumes Firebase is initialized, Messaging is supported, and the messaging service worker and web push configuration are already in place.

const messaging = firebase.messaging();
const enableButton = document.querySelector("#enable-notifications");
const status = document.querySelector("#notification-status");

enableButton.addEventListener("click", async () => {
  if (!("Notification" in window)) {
    status.textContent = "Notifications are not supported here.";
    return;
  }

  if (Notification.permission === "denied") {
    status.textContent =
      "Notifications are blocked in your browser's site settings.";
    return;
  }

  try {
    const permission = Notification.permission === "granted"
      ? "granted"
      : await Notification.requestPermission();

    if (permission !== "granted") {
      status.textContent = "Notifications remain off.";
      return;
    }

    const token = await messaging.getToken();
    if (!token) {
      status.textContent = "Could not enable notifications.";
      return;
    }

    // Application-defined function: securely register this token
    // with your backend and record the user's opt-in preference.
    await saveNotificationToken(token);
    status.textContent = "Notifications enabled.";
  } catch (error) {
    console.error("Notification enrollment failed:", error);
    status.textContent = "Could not enable notifications.";
  }
});

saveNotificationToken is not a Firebase API. Your backend must authenticate the request and associate the token with the correct user or installation. Handle token changes too, rather than assuming the first token lasts forever.

Web push requires a secure context, normally HTTPS, with localhost available for development in supported browsers. Under the standard Firebase setup, provide firebase-messaging-sw.js at the expected location, or explicitly configure the supported service-worker registration for your SDK version.

3. Make opting out durable

An off switch should change delivery behavior, not merely hide a settings panel.

Mark the relevant user, installation, or notification category as disabled on your backend.
Exclude disabled destinations when preparing messages.
Remove server-managed topic subscriptions where applicable.
If disabling messaging for this browser installation, delete its registration token using the SDK.
Ensure startup code does not immediately register it again.

With the 2019 namespaced SDK, token deletion takes the token as an argument:

// existingToken is the registration token for this installation.
await messaging.deleteToken(existingToken);

Deleting a token does not reset Notification.permission. Conversely, a user blocking notifications does not automatically clean up your backend's token records. Handle invalid-token responses from FCM and remove stale destinations.

Decide whether “off” means this browser, this device, or every device on the account, and label the setting accordingly.

Control notification display, not just delivery

FCM message handling depends on the payload and whether the application is in the foreground or background.

Foreground messages

For a foreground web application, handle incoming messages with messaging.onMessage. Your interface decides whether to update a counter, show an in-app banner, or do nothing visible.

messaging.onMessage((payload) => {
  // Update application state without creating a system notification.
  // Avoid logging message contents if they contain sensitive data.
  refreshUnreadIndicator();
});

refreshUnreadIndicator is application-defined. Omitting a foreground banner does not disable background notifications.

Background messages

Background notification payloads can be displayed automatically by the Firebase messaging integration. Removing a foreground handler will not silence them.

Review both the sending backend and the service worker. Look for notification payloads and explicit calls to self.registration.showNotification().

Do not send an automatically displayed notification and also display the same event manually; that can produce duplicates. And do not assume data-only messages are a portable way to perform invisible background work: browser push policies and native platform restrictions differ. If an opted-out user should not receive an alert, suppress the send at its source.

Firebase console alerts and permission errors

There is no universal notification preference in a project's General settings that silences every Firebase service, application push message, and browser prompt.

For project emails or operational alerts, identify the product generating them and inspect its available alerting or subscription settings. Billing-related notifications may belong to Google Cloud billing rather than Firebase application messaging. Preserve important security, billing, and availability alerts unless you have another reliable way to monitor them.

Finally, never “silence permissions” by opening database or storage rules to everyone. A permission-denied error requires investigation of authentication, authorization, rules, or configuration. Hiding it, or allowing unrestricted access, does not fix the underlying problem.

Takeaway

Silence the layer responsible for the interruption. Users can block a website's notifications without changing Firebase itself. Developers should request permission only after an explicit opt-in, honor durable preferences, and stop unwanted messages before sending them. Keep browser permissions, FCM delivery, and data security separate, and a quieter application does not have to become a less secure one.