Enterprise deployment: pre-granting notification permission now requires MDM

Administrators who pre-grant notification permissions with Chrome policy must update their configuration for notification attribution: in addition to the Chrome origin-based NotificationsAllowedForUrls policy, they must deploy a macOS MDM configuration profile that pre-grants notification permission to each PWA's specific bundle ID.

Existing pre-grants stop working for PWAs unless both layers are configured With attribution active (Chrome 152+, macOS), the web-origin permission granted by Chrome policy is no longer sufficient on its own: the app shim's operating-system-level permission is also consulted (see the two-layer permission model). A PWA whose OS-level permission was never granted — or was denied at the macOS level — cannot show notifications even when NotificationsAllowedForUrls allows its origin, and its web permission prompt is ignored with the denial recorded as a system-permission denial.

syntax

Two complementary configuration surfaces — neither replaces the other:

# 1. Chrome policy (origin layer) — pre-grants the web permission
NotificationsAllowedForUrls = ["https://app.example.com"]

# 2. macOS MDM configuration profile (OS layer) — pre-grants the
#    bundle-layer notification permission for the PWA's app shim,
#    identified by the shim's bundle identifier.

Source: Chrome Enterprise policy list — NotificationsAllowedForUrls; blink-dev PSA — administrator guidance

inputs

Configuration	Contract
`NotificationsAllowedForUrls`	Existing Chrome enterprise policy: list of origin URL patterns for which the web-level notifications permission is granted without prompting. Continues to govern the Chrome/origin layer
macOS MDM configuration profile	New requirement with attribution: a notifications payload that pre-grants (or otherwise manages) the OS-level notification permission for the PWA app shim's bundle ID. Deployed through the organization's MDM, per managed device
PWA bundle ID	The macOS bundle identifier of the installed PWA's app shim — the value the MDM profile targets. Each installed PWA has its own shim bundle, so each needs its own profile entry

Source: blink-dev PSA; Chrome Enterprise policies

outputs

Both configured: the managed PWA can post attributed notifications without a user prompt — the pre-152 managed behavior is preserved.
Chrome policy only: the web layer grants, but the shim's OS-level permission is unset (or user-denied); the notification flow consults the OS layer and the app cannot rely on prompt-free notifications.
MDM profile only: the OS layer grants for the bundle, but the origin is still subject to the normal web permission prompt unless Chrome policy also allows it.

Source: blink-dev PSA; permission_prompt_notifications_mac.cc

errors and failure modes

Failure mode	Symptom and recovery
MDM profile not deployed	The PWA's web notification prompt may be ignored when the OS layer has already denied; Chrome records `NotificationsWasDeniedBecauseOfSystemPermission`. Recovery: deploy the profile for the shim bundle ID, or have the user enable the PWA in System Settings → Notifications
Profile targets the wrong bundle ID	The OS grant does not apply to the PWA's shim; symptoms identical to “not deployed”. Verify the installed shim's bundle identifier on a managed device
User denied at OS level before MDM	A subsequent MDM grant replaces the user choice per macOS profile semantics; until the profile arrives, web prompts stay ignored
Badging expected without notifications	`setAppBadge()` silently no-ops under the new gate (see app badging); the same MDM + policy pre-grant restores it

Source: permission_prompt_notifications_mac.cc; blink-dev PSA

context and exposure

This contract concerns device administrators, not web developers: it applies only to managed macOS devices running Chrome 152+ with installed PWAs covered by notification attribution. It is independent of the web platform — nothing here is observable from page JavaScript beyond the standard Notification.permission state.

Source: blink-dev PSA — administrator guidance

lifecycle

Pre-152: admin sets NotificationsAllowedForUrls; the PWA's origin is granted at the web layer and notifications appear under Google Chrome.
Chrome 152 rollout: attribution activates for installed PWAs; delivery moves to each PWA's app shim and the OS-level bundle permission is consulted.
Admin action: deploy the macOS MDM configuration profile pre-granting notifications for each managed PWA's shim bundle ID, alongside the existing Chrome policy.
Steady state: managed PWAs notify (and badge) without prompts, attributed to their own name and icon; users retain per-app control in macOS settings unless the MDM profile locks the setting.

Source: blink-dev PSA; ChromeStatus record

examples

# Chrome policy (origin layer) — e.g. via plist or cloud policy:
#   NotificationsAllowedForUrls:
#     - "https://crm.example.com"
#     - "https://mail.example.com"
#
# MDM (OS layer) — deploy a macOS configuration profile whose
# notifications payload pre-approves each PWA app-shim bundle ID,
# e.g. the bundle for "CRM" and the bundle for "Mail".
# (Payload details are MDM-vendor specific; the Chrome requirement
#  is that the *PWA's* bundle ID — not com.google.Chrome — is
#  pre-granted.)

Verifying on a managed device: install the PWA, confirm its entry appears by name in System Settings → Notifications, and confirm Notification.permission reports "granted" inside the PWA without any prompt.

Source: blink-dev PSA; Chrome Enterprise policies

compatibility

Environment	Contract
Chrome 152+ macOS, managed	Both `NotificationsAllowedForUrls` and an MDM profile per PWA bundle ID required for prompt-free pre-grant (listing, PSA)
Chrome ≤ 151 macOS	`NotificationsAllowedForUrls` alone sufficient (notifications attributed to Google Chrome)
Chrome on Windows / ChromeOS / Linux	Unaffected — attribution is macOS-only; Chrome policy pre-grant behaves as before
Android / WebView	Out of scope — the PSA records no Android/WebView milestones for this feature

Source: ChromeStatus record; blink-dev PSA

security and privacy

Two consent domains. A pre-grant now spans Chrome policy (web origin) and macOS MDM (bundle). Auditing only one layer gives an incomplete picture of which apps can interrupt the user.
Per-app granularity cuts both ways. Users (and MDM) can manage a single PWA's notifications without affecting Chrome's other notifications — finer control, but also more entries to govern.
OS denial is sticky. A user-level macOS denial makes web-layer prompts inert until the MDM profile or the user reverses it; helpdesk runbooks should start at System Settings → Notifications, not Chrome settings.