Content-Based Origins for the Web

3.1. Offline-to-Online Transition for Content-Based Origins

For a content-based origin, content is loaded from a bundle. After loading the bundle, the browser treats content in the bundle as existing in an origin unique to the content of the bundle; see Section 4.¶

If the bundle contains a transfer target URL (see Section 5.3), the browser then attempts to load that resource, providing an indication to the target origin that a transfer from the content-based origin is possible. If the origin accepts the transfer of state, state is transferred from the content-based origin to the target origin. This sequence is shown in Figure 1.¶

               +---------------+
               |  Load Bundle  |
               +---------------+
                       |
                       v
               +---------------+       +---------+
 Aborted +-----| Content-Based |=======|  State  |
Transfer +---->|    Origin     |       +---------+
               +---------------+            :
                       |  State Transfer    :
                       | IFF Origin Accepts :
                       v                    v
               +---------------+       +---------+
               |   Online at   |=======|  State  |
               | Target Origin |       +---------+
               +---------------+

Failure to connect to the target origin - such as when the browser has no active Internet connection - causes the redirect to be aborted. The browser continues to display the bundle content.¶

If the origin does not accept the transfer, the browser shows content from the target origin and any state from the bundle is destroyed.¶

3.2. Offline-to-Online Transition for Signed Exchanges

With [LOADING] and [SXG], content is loaded from a signed bundle. After loading the bundle, if the signature is considered valid, the browser stores bundled content in a cache that is specific to the target origin. The browser then redirects to the request (or target) URL from the bundle. The browser uses content from the bundle in place of fetching from the origin. This is illustrated in Figure 2.¶

    +-----------------+
    |   Load Bundle   |
    +-----------------+
            |             ..If signature is trusted...
            v             :                          :
    +-----------------+   :   +-----------------+    :
    | Check Signature +------>| Store Exchanges |    :
    +-----------------+   :   +-----------------+    :
  Redirect  |             :                          :
            v             :                          :
    +-----------------+   :   +-----------------+    :
    |    Online at    |<------|  Use Exchanges  |    :
    |   Request URL   |   :   +-----------------+    :
    +-----------------+   :...........................

Having signed content from the bundle allows use of that content prior to connecting to the origin. Importantly, it allows attribution of any operations to that origin. Optimizations that otherwise might not be possible are enabled because resources from the bundle can be treated as if they were loaded from the target origin, but the browser does not need to make a request to the origin.¶

Critically, if the browser is fully offline, it can decide to operate with the bundle without having to connect to the origin. If the bundled content is signed and trusted, the application to operate offline. Any actions performed act on state for the target origin.¶

Note:

While Service Workers [SERVICE-WORKERS] can offer a similar experience, they require that the browser be online initially to load the service worker script. This design requires no prior interaction with the target origin.¶

Relative to content-based origins, the use of signatures avoids the need to connect to the target origin and confirm knowledge of the content. For cases where the transition to online status is intended to be immediate, signed exchanges allow a redirect to happen without any requests being made. A signed exchange will therefore display content that is attributed to the target origin faster.¶

Failure to validate a signature causes a redirect to an online location. If the client is offline, that origin will be inaccessible. If the client is online, none of the optimizations afforded by the bundle are available and this appears to be a normal redirection.¶

[[Note that it is unclear whether a browser might be able to fall back to treating a signed bundle as unsigned if the signature is bad.]]¶

3.3. Comparison with Signed Exchanges

Signed exchanges attempt to address the problem of attributing content to an origin. In effect, they add an object-based security model to the existing channel-based model used on the web. Signatures over bundles (or parts thereof) are used by an origin to attest to the contents of a bundle.¶

Having two security models operate in the same space potentially creates an exposure to the worst properties of each model. To reduce the chances that the drawbacks of the newly-added object-based model affect existing channel-based usages, signed exchanges include a number of hardening measures. In addition to signatures, there are required modifications to certificates, constraints on validity periods, and a range of limitations on the types of content that can be signed.¶

In comparison, content-based origins do not require signatures. Questions of validity only apply at the point that a state transfer is attempted. However, this has drawbacks also. Content is not attributed to origins and state is not available to an online origin until a transfer is complete. This avoids the complexity inherent to merging two different security models, but the process of state transfer could be quite complicated in practice.¶

In terms of usability, the identity attributed to content from a content-based origin is opaque and not particularly relatable. Though state might eventually be adopted by some origin, communicating the true status of content could be challenging. Finally, content-based origins aren't prevented from interacting with HTTP origins, which could lead to surprising outcomes if existing code is poorly unprepared for this possibility.¶

3.4. Comparison with Unsigned Bundles

Unsigned bundles [UNSIGNED] proposes a model whereby bundles served by a given origin could be declared to be part of that origin and trusted. Unsigned bundles would otherwise be considered untrusted and would be isolated in some fashion. This is similar to the way in which a content-based origin might be transferred to a target origin.¶

That proposal divides bundles into trusted and untrusted bundles. Trusted bundles would be able to access state from the origin that served them.¶

In comparison, content-based origins would always be used for bundles and the distinction between trusted and untrusted is unnecessary. Content from the bundle would be usable to a target origin that accepts a state transfer.¶

4.1. Content Type Malleability

The hash used to generate this origin does not include any indication of content type or the source of information. If it were possible for the same content to be interpreted as valid instances of multiple different content types, that might be exploited by an attacker.¶

A user agent SHOULD enact a policy of only attributing a content-based origin to content that is unambiguously interpreted in a single form. If it were possible for content to be interpreted as valid for multiple content types and those could be attributed to the same content-based origin, that might be exploited by an attacker. A sample policy might only allow web bundles and HTML files to be assigned a content-based origin; as the first bytes of these formats are unambiguously different, this ensures that the same content to be interpreted as valid for both content types.¶

4.2. Hash Agility

This design depends to some extent on the hash algorithm remaining constant during the time that the content-based origin is used. A change in hash algorithm changes the identity of the resource.¶

It is possible to transfer state from a content-based origin derived using one hash algorithm to another without affecting the content of the origin itself. It is not often that content depends on knowing its own identity. However, the identity of the origin might be made visible to other origins. For instance, the window.postMessage API [HTML] allows content to target a specific origin for sending messages and to identify the source origin of incoming messages.¶

For the purposes of determining equality, user agents might consider hashes of the same content with different hash algorithms to be equal. For instance, a user agent might consider sha-256:ypeBEsobvcr6wjGzmiPcTaeG7_gUfE5yuYB3ha_uSLs to be equal to sha-384;VKWbnyKwuAiA2EJ-VIt8I6vYc0huHwNdzpzWl-hRdQM8qojm1XvDXvrgta_TFF8x. This requires that this equivalence is known to the user agent.¶

Of the hash algorithms defined in [NI], only "sha-256" is permitted for use with content-based origins. This usage has no need for a truncated hash as the value does not usually need to be manually entered. Furthermore, the use of multiple hash algorithms introduces complexity.¶

5.1. Successful Transfer

If the transfer is successful, state associated with the content-based origin will be transferred to the target origin. The user agent MAY either remember the identity of the content-based origin and consider any content-based origin to be equal to the transferred origin.¶

For example, assuming that a single 'a' character is valid content, then the client would include the following in a request (line breaks are added to examples for formatting reasons):¶

Sec-Content-Origin:
  sha-256=:v106/7c+/S7Gw2rTES3ZM+/tY8Thy//PqI4nWcFE8tg=:

A successful state transfer would occur if the response from the server included:¶

Sec-Content-Origin:
  sha-256=:ypeBEsobvcr6wjGzmiPcTaeG7/gUfE5yuYB3ha/uSLs=:

A user agent that automatically follows redirections (3xx status codes) MUST allow the server to redirect to a resource that provides the response. Redirection can change the origin that ultimately accepts the transfer. Any redirection to an origin that is not strongly authenticated MUST cause the transfer to fail.¶

After a successful transfer, the user agent MAY treat the content-based origin as an alias for the origin to which state was transferred. This aliasing might be particularly useful in addressing hash agility; see Section 4.2.¶

5.2. Unsuccessful Transfer

A transfer can be unsuccessful in two ways. If the target origin cannot be contacted successfully, the content-based origin continues to exist. Any API might indicate that the attempt failed. Failure to transfer state is expected when the user agent is offline. After failing to contact the target origin, a transfer can be attempted at a later time. This causes navigation to fail and the user agent MAY display a URL from the content-based origin.¶

[[TODO: Again, this requires that we define a means of identification for content inside bundles.]]¶

A valid, final HTTP response that indicates anything other than a server error (that is, 5xx status codes) or lack of authority (the 421 status code [HTTP2]) without including the hash pre-image in the response MUST be treated as a failed migration. After a failed migration, information about the target origin SHOULD be removed from interfaces related to the content-based origin, except for diagnostic purposes. The content-based origin MAY continue to exist but further attempts to transfer state MUST immediately fail.¶

After a valid HTTP response, the user agent navigates to the transfer target URL or any resource that was included in any redirections.¶

Any valid HTTP response, successful or not, MUST cause data associated with the content-based origin to be cleared as though clear-site-data were invoked [CLEAR-DATA].¶

5.3. Transfer Target

To enable transfer, content MUST include an attribute that indicates the transfer target URL. If a bundle could contain multiple potential entry points, each entry point for the bundle would separately specify a different transfer target URL.¶

[[Intuitively, it seems prudent to limit transfer target URLs in the same bundle to the same origin, but I don't have a concrete reason for doing so right now.]]¶

A transfer target URL does not need to be specified if the intent is to never support the ability to transfer to an online state.¶

The origin of the transfer target URL is the target origin. Only the target origin can be the target of a state transfer. After a successful transfer, the user agent loads the transfer target URL.¶

Note:

Including the transfer target URL in content means that the content hash is dependent on its value. This ensures that different content-based origins are produced if different transfer target URLs are used. Two different origins cannot share state.¶

A commitment in this form could allow user agents to present the target origin in interfaces. While no strong assurances can be made about the attribution of content to this origin, this might make it easier to generate user interfaces.¶

Different content types might provide a way of encoding the transfer target URL. The URL could be provided external to the content, but this requires some unspecified means of ensuring that the content-based origin depends on the value of the URL; this document only supports content that can encode the transfer target URL.¶

5.4. State Transfer

Only limited state information can be transferred between origins. This is limited to those items that are identified here, or those that are added in later extensions. This document describes how content (Section 5.4.1), stored data Section 5.4.2), and permissions Section 5.4.3 are transferred.¶

Upon successful completion of transfer, if loading the transfer target resource produces an HTML document, an event is delivered to content of that resource that describes what information was transferred.¶

A user agent MAY request user permission to transfer some state. This might be conditioned on what state is being transferred. For instance, a user agent might prompt before transferring permissions [PERMISSIONS]; see Section 5.4.3.¶

5.5. Navigation Transfers

Initiating transfer on navigation enables pre-loading of content from bundles.¶

To address this use case, the user agent navigates to a bundle. That bundle might be served from the site providing the link to ensure that information about the linking page is not revealed to the target origin prior to navigation.¶

Navigating to the bundle causes an immediate load of the content of the bundle. This assumes that there is either a URL component that specifies a single entry point for the bundle or that the bundle itself identifies the entrypoint.¶

If a transfer target URL is specified for the target resource, the user agent navigates to that URL. The user agent MUST fetch the transfer target URL and include a Sec-Content-Origin header field in the request as described in Section 5. This request MAY also include the ETag header field from the bundled content.¶

Using If-None-Digest [IF-DIGEST] allows the resource at the transfer target URL to return a 304 (Not Modified) status code in response to a request if the content provided in the bundle known to the server to be sufficient.¶

The result is that the state from the bundle is transferred to the target origin. As the navigation is immediate, no state will have been created within the bundle so the transfer of state can be skipped by the browser if navigation from a previously unused content-based origin is successful. It is possible that the content-based origin might have previously used, in which case state transferrance might occur.¶

5.6. Communication Between Origins

Without knowledge of the content of a resource, or bundle of resources, a content-based origin will be impossible to guess. This means that communication is only possible if the frame in which the content is loaded by the origin attempting communication, or the content is known to that origin.¶