final behaviour changes for unload deprecation

[Fergal Daly]

Ian,

there were a couple of edge cases that were remaining for unload deprecation that I've finally gotten a handle on and I'd like to get your take on them. I will have to bring this to blink-dev in the end to move forward on unload deprecation.

Headerless docs

E.g. `<iframe srcdoc="...">`, `<iframe src="about:blank">` etc.

For these I have a draft CL that causes them to be treated differently for default-EnabledForNone features (it's missing some cases still, e.g. data: urls). The effect is that unload is allowed if the parent allows it and if it's listed in the `allow` attribute.

This seems uncontroversial, the headerless doc effectively behaves like it has the same PP header as the parent which created it. My PR against the spec also need to be updated

Frames without allow

E.g. framesets's <frame>, <embed>, <object>.

For these I have a draft CL that adds `unload` to the allowlist under the hood in `ConstructContainerPolicy` (CL only covers frame, I will update it if it's agreed). The effect is to allow unload if the parent allows unload and if the child adds the PP header.

This one is more tricky as it might surprise devs. They can still isolate these elements in an iframe to remove the permission and unless we add an `allow` attribute to these elements, the only alternative is to unconditionally disable `unload` for them.

If another new feature was added with EnabledForNone, I would not expect to make this exception. It's only because this is a deprecation.

F

[Daisuke Enomoto]

Fergal, Ian

This message went to my spam folder. I am replying so it would land in your inbox.

Apologies for a redundant message for those who received it in their inbox.

--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAAozHL%3D68ZHiD936HDQScjdZ53NJkHO%2BKawJYjVQ-03fjaoCKA%40mail.gmail.com.

[Fergal Daly]

replying from my @chromium.org,

F

[Ian Clelland]

On Tue, May 21, 2024 at 1:46 AM Fergal Daly <fer...@chromium.org> wrote:

replying from my @chromium.org,

F

On Fri, 17 May 2024 at 23:02, Daisuke Enomoto <deno...@google.com> wrote:

Fergal, Ian

This message went to my spam folder. I am replying so it would land in your inbox.

Apologies for a redundant message for those who received it in their inbox.

On Wed, May 15, 2024 at 2:06 PM 'Fergal Daly' via bfcache-dev <bfcac...@chromium.org> wrote:

Ian,

there were a couple of edge cases that were remaining for unload deprecation that I've finally gotten a handle on and I'd like to get your take on them. I will have to bring this to blink-dev in the end to move forward on unload deprecation.

Headerless docs

E.g. `<iframe srcdoc="...">`, `<iframe src="about:blank">` etc.

For these I have a draft CL that causes them to be treated differently for default-EnabledForNone features (it's missing some cases still, e.g. data: urls). The effect is that unload is allowed if the parent allows it and if it's listed in the `allow` attribute.

This seems uncontroversial, the headerless doc effectively behaves like it has the same PP header as the parent which created it. My PR against the spec also need to be updated

This makes sense to me, and generally follows the principle that docs with no headers, whose contents are completely within the control of their embedder, should default to the same effective policy as their embedder.

 

Frames without allow

E.g. framesets's <frame>, <embed>, <object>.

For these I have a draft CL that adds `unload` to the allowlist under the hood in `ConstructContainerPolicy` (CL only covers frame, I will update it if it's agreed). The effect is to allow unload if the parent allows unload and if the child adds the PP header.

I suspect that the intersection of sites using these elements, and sites which are willing/able to add a PP header, is vanishingly small. That said, we should consider the effects here.

The change itself makes sense, in the absence of an allow attribute. Ensuring that the parent document also allows unload removes the chance for abuse by embedded documents. This is about the same as pretending that each of these tags has an implicit "allow=unload" attribute, and we could probably explain it that way.

This seems easier than trying to add an actual allow attribute to those elements, and is probably a good short-term solution. If we expect to use the same mechanism for future deprecations, though, then I think we should be open to the idea of adding that attribute, so that we don't have to special-case some features.

 

This one is more tricky as it might surprise devs. They can still isolate these elements in an iframe to remove the permission and unless we add an `allow` attribute to these elements, the only alternative is to unconditionally disable `unload` for them.

If another new feature was added with EnabledForNone, I would not expect to make this exception. It's only because this is a deprecation.

What do you think the odds of adding another EnabledForNone that is *not* a deprecation? If it turns out that it's the only use case for it, would you want to standardize this in the spec?

Ian

[Fergal Daly]

On Wed, 5 Jun 2024 at 22:49, Ian Clelland <icle...@google.com> wrote:

On Tue, May 21, 2024 at 1:46 AM Fergal Daly <fer...@chromium.org> wrote:

replying from my @chromium.org,

F

On Fri, 17 May 2024 at 23:02, Daisuke Enomoto <deno...@google.com> wrote:

Fergal, Ian

This message went to my spam folder. I am replying so it would land in your inbox.

Apologies for a redundant message for those who received it in their inbox.

On Wed, May 15, 2024 at 2:06 PM 'Fergal Daly' via bfcache-dev <bfcac...@chromium.org> wrote:

Ian,

there were a couple of edge cases that were remaining for unload deprecation that I've finally gotten a handle on and I'd like to get your take on them. I will have to bring this to blink-dev in the end to move forward on unload deprecation.

Headerless docs

E.g. `<iframe srcdoc="...">`, `<iframe src="about:blank">` etc.

For these I have a draft CL that causes them to be treated differently for default-EnabledForNone features (it's missing some cases still, e.g. data: urls). The effect is that unload is allowed if the parent allows it and if it's listed in the `allow` attribute.

This seems uncontroversial, the headerless doc effectively behaves like it has the same PP header as the parent which created it. My PR against the spec also need to be updated

This makes sense to me, and generally follows the principle that docs with no headers, whose contents are completely within the control of their embedder, should default to the same effective policy as their embedder.

 

Frames without allow

E.g. framesets's <frame>, <embed>, <object>.

For these I have a draft CL that adds `unload` to the allowlist under the hood in `ConstructContainerPolicy` (CL only covers frame, I will update it if it's agreed). The effect is to allow unload if the parent allows unload and if the child adds the PP header.

I suspect that the intersection of sites using these elements, and sites which are willing/able to add a PP header, is vanishingly small. That said, we should consider the effects here.

The only reason I was aware of it was because someone contacted us to say they were using framesets and unload. So there is at least 1.

 

The change itself makes sense, in the absence of an allow attribute. Ensuring that the parent document also allows unload removes the chance for abuse by embedded documents. This is about the same as pretending that each of these tags has an implicit "allow=unload" attribute, and we could probably explain it that way.

This seems easier than trying to add an actual allow attribute to those elements, and is probably a good short-term solution. If we expect to use the same mechanism for future deprecations, though, then I think we should be open to the idea of adding that attribute, so that we don't have to special-case some features.

 

This one is more tricky as it might surprise devs. They can still isolate these elements in an iframe to remove the permission and unless we add an `allow` attribute to these elements, the only alternative is to unconditionally disable `unload` for them.

If another new feature was added with EnabledForNone, I would not expect to make this exception. It's only because this is a deprecation.

What do you think the odds of adding another EnabledForNone that is *not* a deprecation? If it turns out that it's the only use case for it, would you want to standardize this in the spec?

I have no idea, I think there are some more candidates for deprecation. Perhaps we should think of this as Deprecate rather than EnabledForNone, just in case we do want to make a distinction.

There was no enthusiasm for this specific case and I think no enthusiasm for standardising it without a specific use case. I don't expect anyone to follow us down this path for unload until we are almost done,

F

[Fergal Daly]

On Thu, 6 Jun 2024 at 16:05, Fergal Daly <fer...@google.com> wrote:

On Wed, 5 Jun 2024 at 22:49, Ian Clelland <icle...@google.com> wrote:

On Tue, May 21, 2024 at 1:46 AM Fergal Daly <fer...@chromium.org> wrote:

replying from my @chromium.org,

F

On Fri, 17 May 2024 at 23:02, Daisuke Enomoto <deno...@google.com> wrote:

Fergal, Ian

This message went to my spam folder. I am replying so it would land in your inbox.

Apologies for a redundant message for those who received it in their inbox.

On Wed, May 15, 2024 at 2:06 PM 'Fergal Daly' via bfcache-dev <bfcac...@chromium.org> wrote:

Ian,

there were a couple of edge cases that were remaining for unload deprecation that I've finally gotten a handle on and I'd like to get your take on them. I will have to bring this to blink-dev in the end to move forward on unload deprecation.

Headerless docs

E.g. `<iframe srcdoc="...">`, `<iframe src="about:blank">` etc.

For these I have a draft CL that causes them to be treated differently for default-EnabledForNone features (it's missing some cases still, e.g. data: urls). The effect is that unload is allowed if the parent allows it and if it's listed in the `allow` attribute.

This seems uncontroversial, the headerless doc effectively behaves like it has the same PP header as the parent which created it. My PR against the spec also need to be updated

This makes sense to me, and generally follows the principle that docs with no headers, whose contents are completely within the control of their embedder, should default to the same effective policy as their embedder.

I have created a patch to the PP spec. I do not know how to correctly express "headerless" in the context of the spec. I'd appreciate your advice there. The cases we have are

- iframe srcdoc

- url is "about:blank"

- url is blank and iframe has never navigated

- url is "javascript:..." and iframe has never navigated

- url is "data:" or a blob URL.

- <embed> of HTML

- <object> of HTML

So perhaps I can define an algorithm for "is document headerless" which tests all of these conditions but I'm not really sure how to express some of them.

 

Frames without allow

E.g. framesets's <frame>, <embed>, <object>.

For these I have a draft CL that adds `unload` to the allowlist under the hood in `ConstructContainerPolicy` (CL only covers frame, I will update it if it's agreed). The effect is to allow unload if the parent allows unload and if the child adds the PP header.

I suspect that the intersection of sites using these elements, and sites which are willing/able to add a PP header, is vanishingly small. That said, we should consider the effects here.

The only reason I was aware of it was because someone contacted us to say they were using framesets and unload. So there is at least 1.

 

The change itself makes sense, in the absence of an allow attribute. Ensuring that the parent document also allows unload removes the chance for abuse by embedded documents. This is about the same as pretending that each of these tags has an implicit "allow=unload" attribute, and we could probably explain it that way.

How should we express this in spec? Should it be in the PP spec or HTML?

F