Surprising secure context inheritance behavior for opened windows

[letitz]

Context: w3c/webappsec-secure-contexts#82 (comment)

Now that w3c/webappsec-secure-contexts#84 has landed and the HTML spec speaks only in terms of creation URLs, I think the spec is incorrect in the following case:

• frame A is a non-secure context, e.g. http://example.org
• frame A opens a new window (frame B) to about:blank
• frame B is a secure context, because its creation URL is potentially trustworthy

This holds even though frame B inherits frame A's origin, which is not potentially trustworthy.

Note that in Chrome 88, frame B is a non-secure context. This behavior is also asserted by web platform tests.

All that to say, I do not think we can rely only on the creation URL of the document to make decisions in the face of local schemes that inherit their origin from another document.

[annevk]

There's an interesting corner case where we have an environment, but it's not associated with a global and such yet (i.e., it's not an environment settings object and therefore there's no origin to speak of). This is when we need to make checks for COOP/COEP and potentially other features that are relevant when instantiating something new.

It seems that about:blank is the corner case that could be trustworthy before, but should not be trustworthy after... However, when we navigate to about:blank we already have all the information so it shouldn't have to be a corner case that flips state.

That is to say that perhaps we should aim to remove the need for step 1 and 2 of https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy and handle these as part of environment creation instead. (There might be other callers of that algorithm that need vetting of their own, I'm not sure.)

cc @fred-wang

[letitz]

It seems that about:blank is the corner case that could be trustworthy before, but should not be trustworthy after...

I don't follow - before and after what?

That is to say that perhaps we should aim to remove the need for step 1 and 2 of https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy and handle these as part of environment creation instead.

That sounds reasonable.

[annevk]

In that before the construction of the global and origin we'd only have about:blank to go on, which would be considered secure, but after construction of those things the origin should be authoritative (it isn't currently, mostly do to missing this issue) which would flip it to insecure. However, rather than fixing it by looking at the origin and accepting this flipping state I'd rather we address the root cause of flipping.

[fred-wang]

Just removing part 1/2 will definitely be a breaking change in Chrome (it's covered by internal and wpt tests), I would need more time to read more carefully and understand the proposal (and what you mean by moving these somewhere else). cc'ing @mikewest

[annevk]

@fred-wang it would be great if you could enumerate all the other callers of that algorithm.

[fred-wang]

@fred-wang it would be great if you could enumerate all the other callers of that algorithm.

Work on https://bugs.chromium.org/p/chromium/issues/detail?id=1153336 is not complete yet but basically:

• There are 3 places that are currently a bit unclear spec-wise : https://groups.google.com/a/chromium.org/g/blink-dev/c/qtMVkfpd3_U

• There are about 63 uses which would need further analysis ; to display them click the keyword on https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/cpp/is_potentially_trustworthy.h;l=39;bpv=1;bpt=1?q=network::IsURLPotentiallyTrustworthy

Note that call sites may add more restrictions to "is url potentially trustworthy" (e.g. restriction to a specific scheme which make data: and about: irrelevant in that case).

[fred-wang]

@fred-wang it would be great if you could enumerate all the other callers of that algorithm.

I started to do that in https://bugs.chromium.org/p/chromium/issues/detail?id=1158302 but sometimes it's not clear why Chromium relies on it and to which spec statement it corresponds. This is going to be huge effort...