Chromium Docs

No Cross-Origin Full-Page Overlays

Chrome features should not include cross-origin overlays that fully obscure an active web page's content area, even temporarily.

If the active page is partially obscured, we should provide sufficient cues to the user that the active page is still present and active. Partial overlays can be dangerous or confusing as well and should be designed carefully with input from security and Chrome UX.

Why?

Chrome has had multiple features in the past that attempt to show a full page, cross-origin overlay above an active web page. In practice, these have created dangerous situations with a large variety of bugs and security issues that are difficult to address in general, so we have adopted a security UX policy that disallows full page overlays.

Features that have used or proposed full page overlays:

  • Interstitial Pages: Security interstitial pages (e.g., for TLS or Safe Browsing warnings, as listed at chrome://interstitials) used an overlay approach for many years, with dozens of bugs due to the active page underneath. This feature eventually migrated to use committed error pages instead in 448486, as documented here.
    • Example: 392354: Interstitials are weird and do weird things. This lists 68 dependent bugs (!), spanning a wide variety of affected features.
  • Prerendering v1: The original version of prerendering loaded the next page in a hidden active state, and it had many challenges with detecting any observable behavior and discarding the page. This created complexity, maintenance challenges, and posed “a burden requiring constant investment of 1-2 SWEs.” The feature was eventually removed and replaced by Prerendering v2, which uses restricted Mojo interfaces to limit what can occur before it is displayed.
    • Example: 439545 - Desktop notifications
    • Example: 520275 - Voice synthesis audio
    • Example: 247848 - Infobars
  • Google Lens screenshots: Google Lens showed a screenshot overlay above an active page, and encountered security bugs where the page changed underneath the screenshot. This feature changed to semi-transparent masks.
    • Example: 1242424: Lens Screenshot URL spoof. A Google Lens screenshot overlay above the active page was not dismissed for all types of navigations, creating a mismatch between the displayed content's origin and the URL in the omnibox. Due to a full-page overlay concern in comment 4, Lens was changed in 1247917 to use a semitransparent mask to show underlying page content.
  • Cross-Origin Paint Holding: Chrome shows the last paint of the previously committed page after a new page commits for up to 4 seconds, until the new page paints. This reduces the amount of time the user is looking at a blank page, but also creates a discrepancy between the address bar and the content shown in the tab. The stale content is not interactive, but it has been used in many URL spoof reports for which we haven't had a great response. It is also possible for the new active page to show prompts or other disruptive behavior before painting, while the stale paint is still visible (see 1447077). This feature is still enabled, with attempts to mitigate the issues (e.g., disabling input). We may choose whether to continue to mitigate these issues or find a safer way to approach this feature.
    • Discussion of concerns: 721145
    • URL spoofs requiring fixes to the 4 second timer: 497588, 672847, 739621, 844881, 1152894
    • URL spoof reports we choose not to fix: 776402 (comment 14 discusses our desire to find a safer UX), 755058, 784395, 1218366, 1237742, 1304041
      • In several WontFix cases, the bug was exploitable for a year or more before the repro independently stopped working, but we had no means of addressing it, and the underlying issues remain present even if particular repro steps stop working. In other cases, we had to close issues explaining that we can't do any better due to paint holding, which can undermine our credibility with vulnerability reporters.
  • Default Navigation Transitions: Proposed to show a full-page screenshot of a cross-origin page above an active page while a navigation is in progress. Pursuing alternative approaches on most Chrome platforms, though a full screen overlay is currently in use on Chrome for iOS.

Examples of Overlay Problems

There are many things that an active but hidden page can do to pose security or functional issues while the overlay is displayed, including but not limited to:

  • Sensors continue to record
    • Camera and microphone continue to record (sometimes without or with inaccurate attribution)
    • Geolocation
  • Input events may be surprisingly sent to the hidden active page
  • Prompts may appear above the overlay, out of context
  • Popups may appear, if a user activation is available
  • Fullscreen mode may activate, obscuring the overlay
  • Audio continues to play
  • The page may continue to update unexpectedly
    • Videos continue to play past the point the user observed
  • Built-in Chrome features or extensions may not be aware of the overlay and do surprising things
    • Accessibility
    • DevTools
    • Saving or printing pages
  • Many Chrome features use content/ APIs to access the last committed URL or origin for functional or security purposes, being unaware of the cross-origin overlay.

This list is not exhaustive and the capabilities of web pages continue to expand over time, so it is difficult to prevent all observable or dangerous behavior while a user is unaware that a page is still present. This would be a fail-open approach requiring us to diagnose and fix all problematic cases. Attempts to do so in the past (e.g., Prerendering v1) have resulted in an unsustainable maintenance burden.

A hidden active page also affects the user's mental model: they are more likely to think the page has been unloaded, ending up confused if Chrome later reveals it has been active but hidden.

Even temporary cases, such as showing an overlay until a timeout, can pose risks to users, such as a “hot mic” situation if a video call appears to end but is still in progress.

Comparisons to Non-Overlay Cases

There are other situations where active web pages may continue to run while not visible to the user, such as in a background tab. Chrome's UI indicates the change of security context to the user in these cases (e.g., using a different tab and address bar contents), and continues to indicate the previous page exists via the tab strip or tab switcher. In contrast, full-page overlays within a given tab imply to the user that the active page is no longer present, even though it continues to run.

BFcache and Prerendering are two other features that keep pages in a hidden but frozen or restricted state. These pages are not fully active as in the overlay case above. However, not all pages can be put into this frozen or restricted state, depending on which APIs are in use, whether the page opts out, which other pages are in the same process, etc. In such cases, BFcache and Prerendering evict or discard the page. As a result, freezing a page is not a general technique that can be used when showing an overlay above any arbitrary page.