Potentially trustworthy URL algo should explicitly treat authenticated schemes as non-opaque

@mikewest

Step 3 of [1] refers to [2] which treats URL’s origin as opaque if the scheme is not one of "blob", "ftp", "http", "https", "ws", "wss", "file". This means that when [2] is called, it will returned immediately because of step 1.

Unless we want to modify the HTML5 spec, [1] should probably say the origin is non-opaque if "scheme component is one which the user agent considers to be authenticated", so that the algo can continue until step 7 of [2].

For example Chrome adds (at least) "filesystem:" and "quicktransport:": https://source.chromium.org/chromium/chromium/src/+/master:url/url_util.cc;l=34;drc=9d93b04dae6a8f145c266f680b14fa52c99c5b76

(incidentally, the mention of filesystem: in the note of [1] is weird since it's not mentioned in https://url.spec.whatwg.org/#concept-url-origin)

[1] https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy
[2] https://url.spec.whatwg.org/#concept-url-origin
[3] https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

I am not sure if we need to tweak which origins are considered opaque. Maybe we can just extend https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy to insert an extra step between current steps 2 and 3 (between steps to ask to consider the "data" scheme and ~execute https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy):

Extra step (between steps 2 and 3):
    If url's scheme component is one which the user agent considers to be authenticated,
    return "Potentially Trustworthy"

FWIW, such step has been recently inserted in a Chromium CL here. This extra step is more-or-less equivalent to step 7 from https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy:

Step 7:
    If origin’s scheme component is one which the user agent considers to be authenticated,
    return "Potentially Trustworthy".

PS. I think that "filesystem" is special, because (similarly to "blob") it's trustworthiness is calculated based on the "inner" URL/origin. OTOH, I agree that "quic-transport" and "chrome-native" and "chrome-error" are good motivations for tweaking the spec (see also https://crbug.com/734581 for why "chrome-native" needs to be treated as trustworthy).

I don't think we should make changes here for schemes that are not web-exposed. If they are web-exposed, they should be standardized and be accounted for, of course.

@anforowicz

Just to be clear, my original report is that strictly following the two specs "is origin trustworthy" returns "trustworthy" for the "urls with a scheme component the user agent considers to be authenticated" ; while "is url trustworthy" returns "NOT trustworthy". This does not seem to be intentional.

Chromium has actually been deviating from the HTML5 spec and treating url with such authenticated schemes as non-opaque, which is what I was proposing.

@anforowicz"s proposal is also fine to address that inconsistency between "is origin trustworthy" and "is url trustworthy", without modifying which URL is treated as opaque, so I'm fine with that too.

To be clear, I don't think the origin algorithm should have such a large implementation-defined section.

AFAIK, the following Chromium-specific schemes are not web-exposed: chrome-native://, chrome-error://, chrome://, chrome-untrusted://, chrome-search://. chrome-extension://foo/, devtools://foo/, but it still seems beneficial to cover such schemes in https://www.w3.org/TR/secure-contexts/#algorithms (the benefit is the ability to have a single source of truth for whether a given URL/origin should display a secure/not-secure address bar chip, be able to use geolocation and other similar permissions, etc.). Existence of the schemes above justifies in my opinion having implementation/browser-specific sections like step 6 of https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy:

6. If origin’s scheme component is
    one which the user agent considers to be authenticated,
    return "Potentially Trustworthy".

Some of the schemes from the previous paragraph are working just fine with the current, origin-only coverage. OTOH, schemes that translate into an "opaque" origin (e.g. chrome-native://, chrome-error://) loose the scheme information after translating a URL into an origin - such schemes and are (incorrectly from the perspective of https://crbug.com/734581) classified as untrustworthy by the current wording of the spec.

PS. I guess one other way to address this problem is through a notion of a "precursor" of an "origin" (e.g. see Chromium's url::Origin::GetTupleOrPrecursorTupleIfOpaque). Remembering where an opaque origin came from might be helpful for the trustworthiness spec (potentially no need to special data: URLs) and for Site Isolation considerations (ability to define process boundaries based on the origin+precursor).

PPS. If there is a desire to remove some/all of the implementation-specific details from https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy (steps 6-7?), then maybe this can be discussed as a separate issue? I guess that one can argue that the spec shouldn't cover the behavior for implementation-specific/non-web-visible schemes. This should also work fine for chrome-native://, chrome-error:// (i.e. this seems like a fine alternative to the proposal in my comment above), but if we keep implementation-specific details in https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy then for consistency we should cover them wherever necessary in other parts of https://www.w3.org/TR/secure-contexts/#algorithms).

Yeah, I think algorithms in specifications should only cover what web content can observe. We don't detail all the potential hooks for extensions or non-default configurations that implementations might have, for instance.

Maybe another approach here is to mark steps 6 & 7 in https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy as non-normative (somehow)?

On one hand, it does feel weird to have the spec cover things that cannot be tested via WPT. OTOH, it feels that browser-specific-schemes and client-side-configuration are not just a Chromium thing (and therefore having some consistency across browsers would still be nice, even if the behavior is technically outside the scope of the spec and/or WPT).

I'd be okay with a note after the algorithm, but I would find it a little odd as we typically don't call out non-web-exposed extension points.

(incidentally, the mention of filesystem: in the note of [1] is weird since it's not mentioned in https://url.spec.whatwg.org/#concept-url-origin)

I opened #89 for that one.

Navigation Menu

Repository navigation

Potentially trustworthy URL algo should explicitly treat authenticated schemes as non-opaque #85

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Potentially trustworthy URL algo should explicitly treat authenticated schemes as non-opaque #85

Description

Activity

anforowicz commented on Jan 14, 2021

annevk commented on Jan 14, 2021

fred-wang commented on Jan 14, 2021

annevk commented on Jan 14, 2021

anforowicz commented on Jan 15, 2021

annevk commented on Jan 15, 2021

anforowicz commented on Jan 15, 2021

annevk commented on Jan 18, 2021

fred-wang commented on Apr 30, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions