This section is not normative.
Currently, web applications are almost always compartmentalized by using separate host names to establish separate web origins. This is useful for helping to prevent XSS and other cross-origin attacks, but has many unintended consequences. For example, it causes latency due to additional DNS lookups, removes the ability to use single-origin features (such as the history.pushState API), and creates cryptic host name changes in the user experience. Perhaps most importantly, it results in an extremely inflexible architecture that, once rolled out, cannot be easily and transparently changed later on.
There are several mechanisms for reducing the attack surface for XSS without creating separate host-name based origins, but each pose their own problems. Per-page Suborigins is an attempt to fill some of those gaps. Two of the most notable mechanisms are Sandboxed IFrames [IFrameSandbox] and Content Security Policy (CSP) [CSP2]. Both are powerful but have shortcomings and there are external developers building legacy applications that find they cannot use those tools.
Application developers can use sandboxed frames to completely isolate untrusted content, but there are a number of problems with such an approach. Since user agents assign sandboxed frames a random, unpredictable origin, it is very difficult, by design, for them to communicate with other frames or use modern, origin-bound mechanisms like postMessage and CORS. Further, there is no easy way to persist client-side state (e.g., using localStorage or sessionStorage) in random, unpredictable origins. Finally, sandboxed frames not only sandbox the application but also any other frames loaded by the appplication. This makes this technique infeasible for any page relying on third-party integrations. Moreover, because they are by definition unique origins, with no relationship to the original origin, designing permissions for them to access resources of the original origin would be difficult.
Content Security Policy is also promising but is generally incompatible with current website design. Developers and security teams have found it impractical to retrofit legacy applications with it. On top of this, until all applications hosted within a single origin are simultaneously put behind CSP, the mechanism offers limited incremental benefits, which is especially problematic for companies with large portfolios of disparate products all under the same domain.
Provide a way for different applications hosted on a single physical origin to isolate these into separate logical origins. For example,
https://foobar.com/widget, today, are, by definition, in the same origin, even if they are different applications. Thus an XSS at
https://foobar.com/applicationmeans an XSS at
https://foobar.com/widget, even if
https://foobar.com/widgetis "protected" by a strong Content Security Policy. Suborigins should allow isolating /application and /widget.
Similarly, provide a way for content authors to split their applications into logical modules with origin level separation without using different physical origins. Content authors should not have to choose between putting all of their content in the same origin, on different physical origins, or putting content in anonymous unique origins (sandboxes).
Provide safe defaults but also make it as simple as possible to retrofit legacy applications on the same physical origin with minimal programmatic changes. This includes providing security-model opt-outs where necessary.
1.2. Use Cases/Examples
We see effectively three different use cases for Per-page Suborigins:
Separating distinct applications served from the same domain due to deployment issues but do not need to extensively interact with other content. Examples include marketing campaigns, simple search UIs, and so on.
Enable secure isolation at modular boundaries within a larger web application by splitting the functional components into different suborigins. For example, a blogging application might isolate the main blog viewership module, the admin module, and the authoring module via separate suborigins.
Similar to (2), applications with many users can split information relating to different users into their own suborigin. For example, a social network might put each user profile into a unique suborigin so that an XSS within one profile cannot be used to immediately infect other users or read their personal messages stored within the account.
https://example.com/runs two applications, Chat and Shopping, used, respectively, for instant messaging and Internet shopping. The site adminstrator runs the former at
https://example.com/chat/, and the latter at
The Shopping application has been very well tested and generally does not
contain much untrusted content. In fact, it only takes simple text from
advertisers, and that text only ever appears in HTML contexts, so the
application is able to entity encode the text and stop nearly all cross-site
scripting attacks on the application. Further, the developers have also
enabled a strong Content Security Policy to mitigate potential XSS concerns
on all pages under
https://example.com/shopping/. The CSP policy only allows scripts
https://example.com/chat/ has been riddled with cross-site
scripting attacks. The application takes untrusted content from a wider
variety of sources and for added complexity, that content ends up in many more
contexts, such as HTML tag attributes. On top of that, the developers never
bothered creating a CSP for the application.
This is bad enough, but, unfortunately, it has led to the extremely bad consequence of attackers using the low hanging fruit of Chat to attack Shopping, the more desirable target. Cross-site scripting Shopping allows an attacker to buy goods with the user’s account, so this is really the juicy target.
Since the applications share the same physical origin, these attacks have not
traditionally been that difficult. Once an attacker has executed code on Chat
with an XSS, they open a new window or iframe at
Since this is at the same origin as Chat, this allows the attacker to inject
code through the
document object of the window or iframe into the Shopping
context, allowing the attacker to buy whatever they’d like.
Historical and branding reasons require hosting both applications on the
example.com origin. Thus, while these two applications are completely separate, the
company cannot split the products into two different origins (e.g.
exampleshopping.com) or different suborigins (e.g.
To address this, the developers decide to serve both applications on two
separate suborigins. For all HTTP requests to any subpath of
/shopping, example.com includes a header
suborigin: chat or
suborigin: shopping, respectively.
This does not remove any of the XSS attacks on Chat. However, when an attacker
injects code into Chat and opens a window or iframe to
example.com/shopping/, they can no longer inject content through the
document as it will fail the same origin check. Of course, the application can
postMessage to communicate with the document,
but that will only be through well defined APIs. In short, the CSP of the
Shopping application is now actually effective as the permissive Chat
application is no longer a bypass of it.
TODO: We probably should add additional examples, or perhaps match an example to each bullet above.
2. Key Concepts and Terminology
TODO(jww) This needs to be filled in once we have a pretty good handle on the basic structure of this document. At that point, we should extract the terms defined throughout the spec and place them here.
This section defines several terms used throughout the document.
CORS, or Cross-Origin Resource Sharing, are defined by the CORS specification. [CORS]
XMLHttpRequest, or XHR, is defined by the XMLHttpRequest specification. [XHR]
The term cross-site scripting, or XSS for short, refers to a content injection attack where an attacker is able to execute malicious code in a victim origin. See the OWASP page on Cross-site Scripting for more information.
2.1. Grammatical ConceptsThe Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC5234. [RFC5234]
Lowercase characters, the
a-z portion of ALPHA, are defined by the grammar:
LOWERALPHA = %x61-7A ; a-z
3. Defining a Suborigin
Origins are a mechanism for user agents to group URIs into protection domains. Two URIs are in the same-origin if they share the same scheme, host, and port. If URIs are same-origin, then they share the same authority and can access all of each others resources.
Compared to per-user isolation in traditional operating systems, the same-origin policy isolates distinct applications identified by their origins. This has been a successful isolation mechanism on the Web. However, it does limit the flexibility of a page to separate itself into a new protection domain as it automatically shares authority with all other identical origins. These origins are defined by physical, rather than programmatic, properties. While it is possible to setup unique domains and ports for different parts of the same application (scheme is more difficult to separate out), there are a diverse set of practical problems in doing so.
Suborigins provide a mechanism for creating this type of separation programatically. Any resources may provide, in a manner detailed below, a string value suborigin namespace. If either of two URIs provide a suborigin namespace, then the two URIs are in the same-origin if and only if they share the same scheme, host, port, and suborigin namespace.
3.1. Difficulties using subdomains
This section is not normative.
At first glance, subdomains provide an ability to setup multiple origins and isolate applications. Unfortunately, a number of practical difficulties make relying on subdomains infeasible.
3.1.1. Separate applications, same originGoogle runs Search and Maps on the same domain, respectively
https://www.google.com/maps. While these two applications are fundamentally separate, there are many reasons for hosting them on the same origin, including historical links, branding, and performance. However, from security perspective, this means that a compromise of one application is a compromise of the other since the only security boundary in the browser is the origin, and both applications run in the same origin. Thus, even if Google Search were to successful implement a strong Content Security Policy [CSP2], if Google Maps were to have an XSS vulnerability, it would be equivalent to having an XSS on Google Search as well, negating Google Search’s security measures.
3.1.2. Separation within a single applicationSeparation is sometimes desirable within a single application because of the presence of untrusted data. Take, for example, a social networking site with many different user profiles. Each profile contains lots of untrusted content created by a single user but it’s all hosted on a single origin. In order to separate untrusted content, the application might want a way to put all profile information into separate logical origins while all being hosted at the same physical origin. Furthermore, all content within a profile should be able to access all other content within the same origin, even if displayed in unique frames.
This type of privilege separation within an application has been shown to be
valuable and reasonable for applications to do by work such as
Privilege Separation in HTML5 Applications by Akhawe et al [PRIVILEGESEPARATION]. However, these systems rely on cross frame messaging
postMessage even for content in the same trust boundary since
sandbox. This provides much of the motivation for the
named container nature of suborigins.
3.2. Threat Model
Origins and the Same-Origin Policy have provided a strong defense against malicious applications. Instead of giving the application the power of the user, applications on the Web are limited to a unique space that is defined by their host. However, by tying the origin to the physical host, this has limited the power of developers.
Suborigins attempt to provide developers with tool to contain two different principles that are on the same host. Suborigins allow two or more applications or modules to be hosted at the same origin but use the same origin policy to separate them from each other.
3.2.1. Cross-Document Attacker
An attacker that is able to compromise one document should not be able to
control another document that is on the same host but delivered in a different
suborigin namespace. If an attacker is able to XSS, for example, a
example.com delivered in the suborigin namespace
the attacker should not be able to control any document on
example.com not in the
TODO(devd): Should we also assert that attacker on main/parent origin cannot compromise the app in sub-origin?
"Should not control" is a stronger statement than I think we want to make. The browser can only isolate per origin isolation. If the app has a bug (due to postmessage or server-side) the browser can’t do anything. We should stick to saying "are isolated like physical origins."
3.2.2. Out of Scope Attacker
This tool is purely for modularity and meant to be an application security tool. It is not meant to help users differentiate between two different applications at the same host, as reflected by the fact that user agents may not put the suborigin in user-visible UI. Additionally, suborigins cannot protect against colluding malicious or compromised applications.
3.3. Relationship of Suborigins to Origins
Suborigins, in fact, do not provide any new authority to resources. Suborigins simply provide an additional way to construct Origins. That is, Suborigins do not supercede Origins or provide any additional authority above Origins. From the user agent’s perspective, two resources in different Suborigins are simply in different Origins, and the relationship between the two resources should be the same as any other two differing origins as described in HTML Standard §origin and [RFC6454]. However, given the impracticalities this may impart on some applications who might want to adopt Suborigins, a few security-model opt-outs to ease the use of Suborigins in legacy applications are also presented. See §6.3 Security Model Opt-Outs for more information.
3.4. Opting into a Suborigin
sandbox attribute, suborigin namespaces are predictable and
controllable. Because of this, potentially untrusted content cannot opt into
suborigins, unlike iframe sandboxes. If they could, then an XSS on a site could
enter a specific suborigin and access all of its resources, thus violating the
isolation suborigins intend to provide. To prevent this, the
server (rather than a resource itself) is the only authoritative
source of the suborigin namespace of a resource. The server communicates the
suborigin of a resource to the user agent through a new
which takes a string value that is the namespace. For example, to put a
resource in the
testing suborigin namespace, the server would specify the
following HTTP header in the response:
Suborigins are defined by a suborigin HTTP response header. The syntax for the name and value of the header are described by the following ABNF grammar [RFC5234]:
suborigin-name = LOWERALPHA *( LOWERALPHA / DIGIT ) suborigin-policy-option = "'unsafe-postmessage-send'" / "'unsafe-postmessage-receive'" / "'unsafe-cookies'" / "'unsafe-credentials'" suborigin-policy-list = 1*(RWS suborigin-policy-option OWS) suborigin-header = suborigin-name [ suborigin-policy-list ]
User agents MUST ignore multiple suborigin headers and only apply the first.
A resource’s suborigin namespace is the value of the suborigin-name in the
A resource’s suborigin policy is the list of individual suborigin-policy-option values in the
suborigin header’s suborigin-policy-list.
Note: A suborigin name must start with a lowercase character, but after the first character, the name may contain lowercase characters or numerals. This is to avoid potential confusion when the origin is serialized if the serialization started with a number.
3.6. Representation of Suborigins
At an abstract level, a suborigin consists of the physical origin, which is a scheme, host, and port, plus a suborigin namespace. However, as mentioned above, suborigins are intended to fit within the framework of HTML Standard §origin and [RFC6454]. Therefore, this specification provides a way of serializing a Suborigin bound resource into a physical origin. This is done by inserting the suborigin namespace into the host of the Origin, thus creating a new host but maintaining all of the information about both the original scheme, host, port, and the suborigin namespace. The serialization format appends the string "-so" to the scheme and prepends the host name with the suborigin namespace followed by a "." character.
For example, a resource hosted at
the suborigin namespace
profile would be serialized as
Similarly, a resource hosted at
the suborigin namespace
separate would be serialized as
Internally, the user agent just tracks the suborigin namespace of the resource. When the origin needs to be serialized, the user agent should follow the algorithm in §6.1.6 Serializing Suborigins.
TODO: Determine how the serialization should relate to the URL spec: https://url.spec.whatwg.org/#host-parsing
suborigin property is added to the document object which reflects the value of the suborigin namespace for the current execution
context. If there is no suborigin namespace, the value should be undefined.
origin property of the document object should reflect
the serialized value of the origin as returned by §6.1.6 Serializing Suborigins.
TODO(jww): Need to write the formal IDL for this.
4. Access Control
Cross-origin (including cross-suborigin) communication is tricky when suborigins
are involved because they need to be backwards compatible with user agents that
do not support suborigins while providing origin-separation for user agents that
do support suborigins. The following discussions discuss the three major
cross-origin mechanisms that are relevant: CORS,
and workers [WORKERS].
TODO(devd): Making things specific to XHR or CORS is weird. We should just make all fetches inside a suborigin CORS fetches and be done with it.
For pages in a suborigin namespace, all
fetch requests to any URL should be treated as cross-origin, thus
triggering a cross-origin request with preflight for all non-simple
cross-origin requests. Additionally, all requests from a suborigin
namespace must include a
Suborigin header whose value is the context’s
suborigin name. Finally, the
Origin header [FETCH] value must use
the serialized suborigin value instead of the serialized origin, as described
in §6.1.6 Serializing Suborigins.
Similar changes are needed for responses from the server with the addition of an
Access-Control-Allow-Suborigin response header. Its value must match the
context’s suborigin namespace value, or
* to allow all suborigin namespaces.
At the same time, the
Access-Control-Allow-Origin response header value must
be modified to use the serialized suborigin value instead of the serializied
origin, as described in §6.1.6 Serializing Suborigins.
Note: Since the suborigin of a server resource is unknown until fetched, all requests, even to resources in the same suborigin are cross-origin. Concretely, imagine putting https://example.com/widget/ in the 'widget' suborigin. An XmlHttpRequest from /widget/index.html to /widget/data.json will be treatd as a cross origin request. A simple XmlHttpRequest will need an Access-Control-Allow-Suborigin header allowing the page to read the response. An XmlHttpRequest of content-type text/json will be preflighted.
TODO(jww): Formal definition of the headers and responses w/grammars.
Also need to be explicit about
* having same limitations as
Access-Control-Allow-Origin * fails with credentialed requests. Does Access-Control-Allow-Suborigin have the same behavior? We should detail that in more detail.
Browsers have a really low cache time (15mins) for preflight responses which makes CORS a big pain for websites. This will become even more salient with suborigins. Should the spec ask browsers to increase cache times?
Serializing the suborigin value into the origin header seems like it will break things. Whats the risk with serializing the physical origin in the origin header? The browser won’t let you read the responses (or succeed preflight) if neither of them have the right allow-suborigin behavior. This seems more compatible with no security risk.
Cross-origin messaging via
postMessage requires that the recipient be
able to see the suborigin namespace of the message sender so it can make an
appropriate access control decision. When a message is sent from a suborigin
namespace, the receiver has the
event.origin value set to the serialized
suborigin value instead of the serializied origin, as described in §6.1.6 Serializing Suborigins. Additionally, a new
suborigin property must be added to
MessageEvent given to the receiver which contains the suborigin
TODO(jww): Formalize by updating the postMessage algorithm
User agents MUST refuse to create or execute any workers in a page executing in a sub-origin.
TODO: Formalize. Not sure what this will look like yet. Chrome and Opera don’t allow creation of workers from sandbox’d iframes/the 'null' origin, but not sure if this formalized in a spec. If it is, should probably just update whatever disallows creation from sandbox.
Note: This may change in the future, and suborigins may eventually be allowed to register service workers, but, for now, allowing the creation of any workers, including service workers and shared workers, from suborigins adds too many complications. Applications can still create workers by creating an iframe of a page not in a suborigin.
5. Impact on Web Platform
Content inside a suborigin namespace is restricted in the same way that other origins are restricted. There are some additional restrictions as well, in order to simplify some complicated cases.
The storage APIs, such as
accessible from within suborigins. By nature of their APIs, they are bound to
the origin of the
Document, which has the practical effect of
giving a separate
Storage object to each suborigin namespace. Per
the definitions in
sessionStorage, the user agent
MUST provide separate
Storage objects per origin, and thus per suborigin namespace.
User agents MUST ignore modifications to the document.domain property of the
WebSocket() constructor algrithm [WebSockets] is modified as follows:
After the current step 1, perform the following step:
If the origin property of the client’s relevant settings object has a suborigin, throw a SecurityError exception.
Note: Suborigins are likely to allow WebSockets in the future, but are disabled until it can be decided how they should be protected.
Note: These sections are tricky because, unlike physical origins, we can’t define suborigins in terms of URIs. Since the suborigin namespace is defined in a header, not in the URI, we need to define them in terms of resources.
6.1. Updates to Origin
Suborigins extends the origin concept. The following sections define how this extension works.
6.1.1. Suborigin of a Response
TODO: This needs update Fetch to change the origin of response. Maybe just need to make sure that response’s URL has the suborigin serialized?a https://fetch.spec.whatwg.org/#responses
6.1.2. Origin Tuple
Update the definition of tuple origin in the origin section of [HTML] to read:
A tuple consists of:
A scheme (a scheme).
A host (a host).
A port (a port).
A domain (null or a domain). Null unless stated otherwise.
A suborigin (a suborigin namespace). The empty string unless stated otherwise.
6.1.3. Physical OriginThe physical origin of an origin is an origin tuple where the components are:
The scheme is the scheme component of the origin
The host is the host component of the origin
The port is the port component of the origin
The domain is the domain component of the origin
The suborigin is the empty string
6.1.4. Comparing Origins
Update the same origin algorithm in [HTML] such that step 2 reads:
If A and B are both tuple origins and their schemes, hosts, ports, and suborigins are identical, then return true.
6.1.5. Comparing Physical Origins
Two origins, A and B, are said to be same physical origin if the following algorithm returns true:
Let AP be the physical origin of A. Let BP be the physical origin of B.
If AP and BP are the same origin, return true.
6.1.6. Serializing Suborigins
This section defines how to serialize an origin to a Unicode [Unicode6] string and to an ASCII [RFC0020] string.
18.104.22.168. Unicode Serialization of a Suborigin
Update the Unicode serialization of an origin in [HTML] by modifying step 4 to read:
Let unicodeOrigin be a new tuple origin consisting origin’s scheme, unicodeHost, origin’s port, and origin’s suborigin.
22.214.171.124. ASCII Serialization of a Suborigin
Update the steps of ASCII serialization of an origin in [HTML] to read:
If origin is an opaque origin, then return "null".
Otherwise, let result be origin’s scheme.
schemeSuffixbe "-so://" if the suborigin component of origin is not the empty string, and "://" otherwise.
hostPrefixbe the suborigin component of origin with "." appended to it if the suborigin component of origin is not the empty string, and "" otherwise.
Append origin’s host, serialized, to result.
If origin’s port is non-null, append a U+003A COLON character (:), and origin’s port, serialized, to result.
Document object’s origin
TODO: Need to assign how Document gets a suborigin. Need to patch the "For Document objects" subsection of https://html.spec.whatwg.org/#origin. Will also probably need to update https://fetch.spec.whatwg.org/#concept-response to have a suborigin property, which uses that response to assign a suborigin to the origin tuple for Object, similar to https://w3c.github.io/webappsec-csp/#sandbox-init.
6.2. Interactions with the DOM
Append the following to the list of conditions of
Document objects that are cookie-averse in Section 3.1.2 of HTML5’s resource metadata
Modify the paragraph following this list to read "scheme/host/port/suborigin tuple" instead of "scheme/host/port tuple".
Additionally, modify step 1 of Cookie setter to read:
If the meta element has no content attribute, or if that attribute’s value is the empty string, or if the
Documentis cookie-averse then abort these steps.
Note: A cookie-averse
Document object has the property that direct
document.cookie returns the empty string, and assigning to
document.cookie has no effect whatsoever. However, that network cookies are
not affected and documents with different suborigin namespaces on the
same physical origin share the same cookies on the network.
Note: For practical purposes, this means that a developer cannot use
document.cookie directly because assignment and reading of the object are both
no-ops. However, a cookie-averse
still use getters and setters on the
cookie property of the
and, in that way, may still simulate cookie access.
Currently, some browsers do not let applications redefine getters and setters on cookie averse documents. Should the spec enforce that this is allowed?
6.3. Security Model Opt-Outs
For backwards compatibility, Suborigins provide several opt-opts from the standard security model. A developer can choose to use these opt-outs by specifying a suborigin policy in the suborigin header
Since these opt-outs weaken the security model of suborigins, developers SHOULD NOT use these options unless they are required to make their application work.
The values of suborigin-policy-option that may be present in a suborigin policy have the following effects:
When a message is sent to a
frame with a
targetof a serialized physical origin, but not a serialized suborigin, if the frame has an execution context with a suborigin where the scheme, host, and port match the
target, but it also has a suborigin namespace, if
'unsafe-postmessage-receive'is set, it will still receive the message.
https://example.comruns a map API at
https://example.com/mapswhich is embedded by other websites. It provides a
postMessage()API to place markers on the map at locations the embedder chooses.
The developer would like to run
https://example.com/maps in a suborigin
namespace "maps". However, when embedders send messages to the embedded
frame, because they are legacy uses from before the use of suborigins, they
send essages with a
https-so://maps.example.com. Since the developer would still like this
frame to be able to provide the API to these legacy embedders, it can serve
the frame with the
'unsafe-postmessage-receive' directive, which will
allow the frame to receive messages on behalf of
though it is at
Should both postMessage opt-outs clarify that explicitly setting to the serialized suborigin representation will still work? I.e., applications that are aware of suborigins can use that if they want.
When a message is sent from a
suborigin namespace with
event.originvalue of the receiver should be set to the serialized physical origin, not the serialized suborigin value. However, the
event.suboriginfield should still be set to the name of the suborigin namespace.
https://example.com/mapsis a mapping application that is commonly embedded in other sites. It provides a
postMessage()based API to place locations of the embedder’s choosing on the map.
httsp://example.comwould like to run the application in a suborigin named "maps".
In response to queries to the API,
https://example.com/maps may send
messages back to the embedder if, for example, a user clicks on one of the
locations. However, since the embedder may be legacy and not be aware of
suborigins, when it checks the
event.origin protery of the
MesseageEvent, if it sees
https-so://maps.example.com as the origin, it
will reject the message as a potential attack. Thus,
https://example.com may use the
'unsafe-postmessage-send' directive to allow its messages
to appear with the origin of the physical origin, in this case
Documentwith a non-empty suborigin namespace is cookie-averse, which means that cookies cannot be read or written. However, if the suborigin policy contains the
Documentis not made cookie-averse, which leaves cookies readable and writable by the execution context. See §6.2.1 Cookies for the precise definition of how this is defined.
Practically speaking, this means that code executing in this suborigin can access and set cookies for any other suborigin at that physical origin, including the empty suborigin. Thus, this option SHOULD NOT be used if cookies are security-sensitive in your application.
All cross-origin requests to the physical origin for the execution
context will include credentials if the
'unsafe-credentials' suborigin policy option for the execution context is set.
Specifically, update the step 2 of HTTP-network-or-cache fetch in the Fetch spec [FETCH] to read:
Let credentials flag be set if one of
request's credentials mode is "include"
request's credentials mode is "same-origin" and request’s response tainting is "basic"
request's credentials mode is "same-origin" and
request's environment settings object has the
suborigin unsafe credentialsflag set and the request’s current url is same physical origin with request origin.
Note: This has several important, practical effects. If the credentials
mode of a
fetch() is set to "same-origin", and if it is to the same
physical origin as the current execution context, credentials will be
included. This means that if the
crossorigin attribute on elements such
<img> are set to
anonymous, credentials will be sent if the origin
of the URL is the same physical origin. Similarly, if making an XMLHttpRequest, setting this flag is equivalent to setting
true for requests to the same physical
origin. This means that it credentials will be sent even for requests to
another suborigin at the same physical origin.
TODO(jww,aaj): Provide an example of why this might be needed.
TODO: These opt-out descriptions should probably be moved to the individual sections where the behaviors are discussed (i.e. postMessage and cookies). These just need to be fleshed out anyway, and examples and reasons need to be given. Also, they need to update the processing model, such as adding appropriate flags to the environment settings object.
7. Practical Considerations in Using Suborigins
Using suborigins with a Web application should be relatively simple. At the most
basic level, if you have an application hosted on
and all of its resources are hosted at subpaths of
/app, it requires that the
server set a Content Security Policy on all HTTP requests to subpaths of
/app that contain the header
suborigin: namespace, where
namespace is of the
application’s choosing. This will ensure that the user agent loads all of these
resources into the suborigin
namespace and will enforce this boundary
Additionally, if your application allows cross-origin requests, instead of
adding the usual
Access-Control-Allow-Origin header for cross-origin requests,
Access-Control-Allow-Suborigin headers, as defined in §4.1 CORS.
In the client-side portion of the application, if
postMessage is used, the
application must be modified so it does not check the
Instead, it the
event.suborigin fields, as they are defined in §4.2 postMessage.
TODO(devd): Flesh out the above and make sure it covers all it needs to cover.
8. Security Considerations
8.1. Presentation of Suborigins to Users
A complication of suborigins is that while they provide a meaningful security for an application, that boundary makes much less sense to a user. That is, physical origins provide a security boundary at a physical level: separate scheme, hosts, and ports map to real boundaries external of a given application. However, suborigins as a boundary only makes sense within the context of the program logic itself, and there is no meaningful way for users to make decisions based on suborigins a priori.
Therefore, suborigins should be used only internally in a user agent and MUST NOT be presented to users at all. For example, user agents must never present suborigins in link text or a URL bar.
Is history.pushState allowed in a suborigin? I suggest no to reduce complexity and inherit from sandbox behavior. On the other hand, this impacts compatibility.
8.2. Not Overthrowing Same-Origin Policy
Suborigins do not fundamentally change how the same-origin policy works. An application without suborigins should work identically to how it always has, and even in an application with suborigins, the same-origin policy still applies as always. In fact, this document defines suborigins within the context of the same-origin policy so that, in theory, serialized suborigins can be thought of as a just a special case of the traditional same-origin policy.
8.3. Problems with Serialized Representation
TODO: Need to list concerns with serialization, e.g. apps that don’t recognize the suborigin serialization, esp. if they blocklist origins.
9. Privacy Considerations
TODO: Do we have privacy issues?