[Bug 24260] New: Enable scenario for establishing isolated [auxillery] browsing context

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24260

            Bug ID: 24260
           Summary: Enable scenario for establishing isolated [auxillery]
                    browsing context
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: travil@microsoft.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

As part of IE [1] and Chrome's [2] multi-process architecture, it is
advantageous from a reliability perspective (among other reasons) to separate
what this spec calls top-level browsing contexts from each other. As an
implementation detail, this separation becomes problematic when the two
browsing contexts are allowed to have synchronous communications, as this
requires [at least] synchronization and often blocking between the two
processes.

window.open() is an API that can create a two-way communication link between
the opener browsing context and the "openee" (auxiliary) browsing context. The
communication is provided between the WindowProxy returned from window.open to
the caller, and the WindowProxy obtained via the opener property of the callee.
To avoid the implementation problems that arise if a browser tries to
process-isolate the caller from the callee in this scenario, browsers will
"leash" (my term) the one browsing context to the other such that both belong
to the same process. Naturally this defeats the benefits provided by process
separation, but is necessary to meet our compatibility, performance, and
functionality goals. 

I realize that this is an implementation detail and not applicable to all user
agents. However, web developers may want to knowingly exploit the reliability
and other benefits of process isolation in their pages, especially when there
is a compelling scenario to do so. For example, when the web application
curates lists of untrusted links, or uses another service such as an ad
framework for which it doesn't intent to communicate with. Process isolation
really only makes sense when communication opportunities between the processes
are at a minimum (especially synchronous communication).

Today process isolation typically happens at the top level browsing context
(e.g., "tab"), but in theory its benefits could be extended in the future to
any browsing context, such as those established by iframes.

HTML5 should describe a way for web developers to signal the intent to isolate
(at least) at the window.open level. Specifically, when the auxiliary browsing
context being established by window.open (when no existing named target can be
found) should be isolated. Isolation in this sense should not provide a
WindowProxy for synchronous or asynchronous communication to either the opener
or openee.

The "noreferrer" link type is an existing [3] signal that allows web developers
to describe that the openee should not be allowed to refer back to the opener.
The spec currently requires that, under these conditions, the "openee" will be
unable to obtain a WindowProxy to the opener via the property of the same
name(this is implemented in at least Chrome 32). Today, "noreferrer" does not
provide complete isolation because a WindowProxy to the "openee" is still
provided to the opener, thus leaving open the option to communicate with the
openee. Consequently, browsers do not setup process isolation in this scenario.
I suspect it may be web-incompatible to change this behavior by extending
"noreferrer" to also not return a WindowProxy from window.open().

I'd propose introducing a similar link type, perhaps "isolate" or "unrelated"
to trigger this new behavior: window.open() will not return a WindowProxy in
addition to the behavior of "noreferrer". Alternatively, some flag to the
window.open call itself, such as a target string "_new" or "_isolate". Or to be
more generic, the use of a sandboxing directive or CSP directive [4] similar to
"popup-src" but with isolation semantics.

[1]
http://blogs.msdn.com/b/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx
[2] http://blog.chromium.org/2008/09/multi-process-architecture.html
[3]
http://www.w3.org/html/wg/drafts/html/master/single-page.html#link-type-noreferrer
[4]
http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#popup-src

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 9 January 2014 20:06:48 UTC