Isolated Origins Navigation Manager Concept

A Collection of Interesting Ideas,

Issue Tracking:
David Ross
Emily Stark


This document describes the concept of a navigation manager for use as part of Isolated Origins.

1. Introduction

The Chrome Isolated Origins specification enables apps to opt-in to an environment that is isolated from other web applications in the same desktop session. The isolation is intended to prevent cross-site scripting (XSS) and other web-based attacks.

This document aims to identify and define the best possible solution to the following open question from an early version of the Isolated Origins specification:

How should navigations be limited? Limiting navigations breaks linkability and hinders functionality, but improves defense against reflected XSS and CSRF. Striking the right balance here will be tricky. We could only allow navigations to the root URL on the isolated origin, or we could transform navigations into a navigation to the root URL with some sort of message to allow the site to decide whether the navigation should go through. Or foreign fetch could be modified to allow the isolated origin’s Service Worker to intercept the navigation and decide whether it should be allowed.

2. Potential solutions considered

  1. Entry Point Regulation (EPR)

  2. Only allow navigations to the top-level page.

  3. Allow navigations to the top-level page, also allowing navigations to arbitrary paths sans query params / fragments.

  4. Flexible navigation manager implemented by the isolated application

3. Factors being considered in the selection of a preferred solution

  1. Any solution should leverage existing web technologies to the maximum extent possible so as to avoid reinventing the wheel.

  2. XSS in paths (without querystring data).
    A problem with solution 3.

  3. Allowing navigation only to a top level page is arbitrarily restrictive.
    A problem with solution 2.

  4. Generally speaking, input to an isolated web app should go through a formal API that can be appropriately regulated based on data about the input. (Consider the benefit of postMessage vs. legacy message passing mechanisms.)
    A problem with solution 3.

  5. Should avoid TOCTOU problems and list maintenance issues.
    A problem with solution 1.

  6. Should avoid hampering deep linking.
    A problem with solutions 1, 2, and 3, but likely not 4.

  7. With any approach, it’s fair to say that the goal is to centrally regulate data coming into the application via navigations at the client, in a way that is "secure by default."
    Not a problem with any approach being discussed.

  8. The mailing list unsubscription scenario needs to work. That is, the case where a link in e-mail takes the user to the isolated app and passes some data to the app.
    A problem with solutions 2 and 3.

  9. CSRF via cross-origin POST.
    Out of scope as this is addressed more generally by Isolated Origins.

  10. Secure by default.
    A drawback of solution 3.

  11. Flexible enough to allow for the development of full-featured isolated web applications.

4. Preferred solution

The navigation manager approach appears to be most preferable when considering the list of factors above. The biggest drawback of the navigation manager approach is that it relies on the isolated app not to implement a navigation manager carelessly. But navigation managers should be easy to audit, and secure sample implementations may be provided. It would be nice to see popular open-source navigation managers emerge.

5. Proposed navigation manager mechanism

Without an implemented navigation manager, only basic HTTP GET based navigations to the root path of an isolated app would be allowed. This would let malicious sites spawn an instance of the malicious app in a new window, but nothing more. (Framing will be prohibited by Isolated Origins.)

To avoid re-inventing the wheel, the navigation manager mechanism would leverage the existing browser support for Service Workers and Fetch Events. To implement a navigation manager, an isolated origin would first install a third-party service worker. Next it would call registerNavigationManager(). (This concept is based upon registerForeignFetch().)

Example call to registerNavigationManager():

self.addEventListener('install', event => {

It should not be possible to register a navigation manager outside of the isolated environment. Otherwise it may be possible for a non-isolated site to register a navigation manager that is then enforced once the origin becomes isolated.

The isolated origin should generally fail to navigate unless a registered navigation manager is consulted. The only exception would be for HTTP GET-based navigations that do not include path or querystring data. This restriction helps ensure that the system overall fails secure by default.

Subsequent to navigation manager registration, the service worker would set up a navigationsafetycheck event handler. The navigationsafetycheck event as detailed below does not need to fetch the resource itself. It has access to the request and can make a decision that the browser will then consider as it fetches the resource in question.

Example navigationsafetycheck event handler:

self.addEventListener('navigationsafetycheck', event => {
  var result = { method: event.methods.BLOCK, withCredentials: false};
  if (event.request.method == 'GET') {
    var url = new URL(event.request.url);
    if (url.protocol == 'https:') {
      if ((url.pathname == '/') && ( == '?') && (url.hash == '#')) {
        result.method = event.methods.ALLOW;
      } else {
        result.redirectUrl = "https://" + url.hostname + "/";
        result.method = event.methods.REDIRECT;

The navigationsafetycheck event handler will be called for any resource request that is in scope for navigaiton management. This means the following conditions are satisfied:

Navigations initiated from outside of an isolated origin can not target a frame within the isolated origin.


Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.


Terms defined by reference


Normative References

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL:
Alex Russell; et al. Service Workers 1. URL: