Architecture thoughts

[annevk]

Looking at https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-payment-req it seems that the current setup is quite involved for participating specifications.

It seems to me the contract could be simpler. Whereby a participating specification provides an identifier and a global and a shared algorithm then returns whether it can proceed (previously known as "has transient activation").

(Perhaps a bit more is needed to address the variety of use cases, I haven't looked at this in detail, but in general we should strive for making adoption easy and put the bulk of the logic in the base specification.)

[mustaqahmed]

Sounds like a promising idea, thanks. Need to understand a bit more, let's pick one specific capability (say fullscreen or payment-request) for ease of discussion:

• What did you mean by a "shared algorithm"?
• "Whether it can proceed" and "previously known as...": did you mean the fullscreen spec will replace "has transient activation" text with a function-call "has-capability(fullscreen)" which would be defined in this delegation spec?

[annevk]

Yeah, essentially you have an "has user activation" algorithm that you pass the global and the capability name and it returns true/false. So specifications such as Fullscreen can write

1. If has user activation with global and "fullscreen" returns true.

and do not need multiple steps that require intricate knowledge of data structures defined elsewhere.

(I was thinking that maybe consumption can also be part of this as at least in some examples it always follows this, but it seems that Fullscreen doesn't consume at the moment.)

The delegation specification would define that algorithm (aka the shared algorithm). (And perhaps eventually it would live in HTML alongside the user activation infrastructure as this would end up replacing part of that.)

[mustaqahmed]

So it would become like "slicing of user activation", instead of "dropping user activation to spawn a capability access" as in the current proposal. Is my interpretation right?

... it seems that Fullscreen doesn't consume at the moment.

No longer in Chrome! Chrome fullscreen started consuming few years ago to suppress a security problem, so we don't allow both fullscreen and popup with a single user activation!! From that perspective, consumption in our new design would need a "across-the-slice effect".

FYI @jyasskin in case he has more ideas.

[annevk]

I'm not sure I follow. I wanted to suggest a different way of organizing the feature, but this should be an editorial change in the end.

[annevk]

We had a good discussion about this today.

The high-level idea is that we add a parameter to https://html.spec.whatwg.org/#allowed-to-use so it can also check for user activation or capability-delegated user activation. And potentially another parameter so it can consume that user activation if desired.

Allowed to use takes a Permissions Policy name. We'd define a set of names tentatively called user activation capabilities that are a subset of Permissions Policy names. If allowed to use is used with a user activation parameter but with a name that is not in that subset you'd hit a spec-level https://infra.spec.whatwg.org/#assertions.

If you pass a string to the new postMessage() parameter that is not a user activation capability it'll throw. (It should do this check before invoking allowed to use as otherwise that would hit the spec-level assert.)

The thinking here is that whatever we might want capability-delegated user activation for should also be a permission. This has been the case so far and hopefully remains true going forward. And "allowed to use" is our current minimal interface for permissions that would be nice to keep using going forward.

(We also had a discussion about whether the Permissions Policy delegation check could be bypassed if the delegating frame has the appropriate permission and does delegate the user activation. This was not deemed desirable from a web developer perspective as it could be somewhat confusing. It might also make browser sandboxing efforts harder.)

[annevk]

@domenic pointed to whatwg/html#6163 which suggests that perhaps this all ought to go into the Permissions Policy document eventually. Though as discussed the current focus is making sure this WICG document reflects the model accurately.