Secure Contexts integration

[annevk]

With the change in data: URLs I think whether a document-based environment is a secure context can be a function of the top-level creation URL. Basically, if an environment's top-level creation URL is a secure context, environment is a secure context.

If that's the case we could maybe change #5491 to store the top-level creation URL rather than its origin. And chose between the top-level creation URL and the top-level origin as appropriate.

@mikewest @shivanigithub @domenic thoughts?

For workers we'd still have to explicitly inherit, but we should do that anyway to fix w3c/webappsec-secure-contexts#56 and w3c/webappsec-secure-contexts#74. (I was thinking that the "is secure context" operation either returns an explicit secure context value or assumes the environment is for a document and runs that function on a creation URL.)

There's also the smaller issue of defining windowOrWorker.isSecureContext in HTML. We should probably do that after we figure out how to define it for settings objects.

[annevk]

@shivanigithub it would be really great to have your input on this idea as it impacts what we do in #5491.

Looking at whatwg/fetch#943 it seems that top-level creation URL is a concept that could work for that to the same extent that target top-level origin can. Provided we're okay with having to obtain an origin from that URL at that point which seems fine.

And defining secure contexts cannot be done without the top-level creation URL.

@mikewest note that the assumption here is that if the top-level document is a secure contexts, all its descendants will be too, which I think is valid.

[annevk]

And to be extra clear, the end result is that HTML will take over "Is an environment settings object contextually secure?" from the secure contexts specification and fix a number of issues in doing so in the process.

[shivanigithub]

Some questions to understand this:

With the change in data: URLs I think whether a document-based environment is a secure context can be a function of the top-level creation URL. Basically, if an environment's top-level creation URL is a secure context, environment is a secure context.

What is the change in data: URLs?

If that's the case we could maybe change #5491 to store the top-level creation URL rather than its origin. And chose between the top-level creation URL and the top-level origin as appropriate.

In #5491 the target top-level orgin is only defined for a navigation request. It takes the top-level creation URL for the top-level navigation request but the top-level origin for a nested frame's navigation request. How will the latter be impacted by this change?

@mikewest @shivanigithub @domenic thoughts?

For workers we'd still have to explicitly inherit, but we should do that anyway to fix w3c/webappsec-secure-contexts#56 and w3c/webappsec-secure-contexts#74. (I was thinking that the "is secure context" operation either returns an explicit secure context value or assumes the environment is for a document and runs that function on a creation URL.)

There's also the smaller issue of defining windowOrWorker.isSecureContext in HTML. We should probably do that after we figure out how to define it for settings objects.

[annevk]

@shivanigithub data: URLs now "inherit" the secure context state of their parent rather than be always insecure.

In #5491 the target top-level orgin is only defined for a navigation request. It takes the top-level creation URL for the top-level navigation request but the top-level origin for a nested frame's navigation request. How will the latter be impacted by this change?

That's a great point. It would end up being wrong for embedded documents. I was wrongly assuming we would get this from elsewhere for them, but there's no such concept.

I guess that means we need both:

• Top-level creation URL.
• Top-level origin.

But if we have top-level creation URL we could make top-level origin return null (and only have a single concept rather than top-level origin and target top-level origin). It would only return null during the request for a top-level navigation and if during that time you need something to key on you would resort to the top-level creation URL, which we'll also use for the secure context decision and other things that might need a URL.

[shivanigithub]

From the comment here we will still need the target top-level origin for a nested frame's navigation request.

[annevk]

Yes, at that point top-level origin would not return null. The idea is to take top-level origin from the environment settings object and move it to environment. Have it return null initially and once we have a response origin from the top-level start using that.

[annevk]

@shivanigithub to be clear, if this seems reasonable to you I'm happy to help do the work of updating the HTML and Fetch PRs to match this, which should give identical observable results for the HTTP cache. All that would be asked from you is review.

[shivanigithub]

Yes, at that point top-level origin would not return null. The idea is to take top-level origin from the environment settings object and move it to environment. Have it return null initially and once we have a response origin from the top-level start using that.

That makes sense

[shivanigithub]

@shivanigithub to be clear, if this seems reasonable to you I'm happy to help do the work of updating the HTML and Fetch PRs to match this, which should give identical observable results for the HTTP cache. All that would be asked from you is review.

Are the changes you have in mind going to replace both or one of #5491 and whatwg/fetch#943 or would they be in addition to these?
Looks like #5491 is probably going to be largely affected by your changes and then whatwg/fetch#943 can then be updated based on those changes. Thanks!
Just want to make sure we are on the same page with regards to who is doing which changes.

[annevk]

@shivanigithub I was thinking I would push the necessary changes to those PRs as new commits. For defining top-level origin and top-level creation URL directly on environment. And then later on a separate PR to define secure contexts largely in terms of top-level creation URL with separate logic for workers.

[shivanigithub]

@annevk that plan sounds good to me.