Status of the notions of "secure context" in Chromium

55 views
Skip to first unread message

Frédéric Wang

unread,
Apr 30, 2021, 6:26:12 AM4/30/21
to blink-dev, Mike West

Hello everybody,

This is an update on my attempt to unify the various notions of "secure context" in Chromium and make it consistent with specifications and other browsers [1].

Code duplication and differences with the spec have been significantly reduced but there are still a few issues to address. Additionally, several historical usages of "secure context" functions are not really documented in Chromium or in a corresponding specifications.

Feedback about this is welcome !

I/ What are the notions of "secure context" in specifications?

Perhaps the most common use is via the [SecureContext] IDL attribute [2] which indicates whether the construct must be exposed to a "secure context" as defined by the HTML specification [3]. This in turn relies on the concept of "potentially trustworthy URL" [4] which finally relies on the notion of "potentially trustworthy origin" [5]. One very important use case for [4] is the mixed content spec [6].

Note that there are subtle aspects, for example the origin of "blob:" URL is parsed specially [7] and there is room for browser-specific implementations such as chrome-extension: [8] or enterprise policy allowlist [9]. But in general these various concepts are quite similar and well-defined.

It's possible that some standards are currently a bit vague about what they mean by "secure". If you are involved in the design of one of these standards, I invite you to try and rely on the above definitions [2-5] as much as possible (possibly with extra restrictions) so that corner cases like the ones mentioned above are properly handled and things remain consistent.

II/ What are the (remaining) implementations of "secure context" in Chromium?

After the work on [1], the status is:

- network::IsOriginPotentiallyTrustworthy() implements [5].

- SecurityOrigin::IsPotentiallyTrustworthy() implements [5] too, but essentially calls network::IsOriginPotentiallyTrustworthy().

- network::IsURLPotentiallyTrustworthy() implements [4] and relies on network::IsOriginPotentiallyTrustworthy().

Additionally, we also have duplicate logic to deal with URLs and origins (KURL vs GURL and blink::SecurityOrigin vs url::Origin). This may potentially lead to inconcistencies when these are URLs/origins are parsed or converted. The class AbstractTrustworthinessTest tries to share various tests between these two implementations.

III/ What are the differences with the specifications?

These are big ones I can see:

- When parsing origins [7], we treat filesystem: specially (similar to blob:) and support a few extra schemes (quic-transport:, content:, externalfile:, any non standard schemes for android webview...).

- network::IsURLPotentiallyTrustworthy() treats some URLs generating an opaque origins as trustworthy, if they are considered authenticated [8]. See also [10] for a spec discussion.

- SecurityOrigin::IsPotentiallyTrustworthy() has a special flag to treat opaque origins as trustworthy. This flag is set in DocumentLoader::CalculateOrigin for two cases: sandboxed origins inheriting from a trustworthy owner and opaque that would be trustworthy if their corresponding url is reparsed. For several callers, this flag is actually irrelevant since SecurityOrigin::IsPotentiallyTrustworthy is called immediately after the instance is created, see [11].

At this point, I'm not sure if we can simplify our implementations further and align more it with the specifications, without breaking intentional non-standard behaviors...

Finally, as said above it's possible that we implement features without relying on these canonical definitions of "secure context" or that we use one of the Chromium implementations even if there is no corresponding text in the standard. I started a bit to analyze callers in [12] but help would be appreciated.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1153336
[2] https://heycam.github.io/webidl/#SecureContext
[3] https://html.spec.whatwg.org/multipage/webappapis.html#secure-context
[4] https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url
[5] https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-origin
[6] https://w3c.github.io/webappsec-mixed-content/
[7] https://url.spec.whatwg.org/#concept-url-origin
[8] https://w3c.github.io/webappsec-secure-contexts/#packaged-applications
[9] https://w3c.github.io/webappsec-secure-contexts/#development-environments
[10] https://github.com/w3c/webappsec-secure-contexts/issues/85
[11] https://chromium-review.googlesource.com/c/chromium/src/+/2835097
[12] https://bugs.chromium.org/p/chromium/issues/detail?id=1158302

-- 
Frédéric Wang
Reply all
Reply to author
Forward
0 new messages