Re: [w3ctag/design-reviews] User Activation Delegation through postMessages (#347)

#### Capability-delegation is an orthogonal concept

@plinss: we already agreed above that user activation is an input not a capability.  Now let’s look at why capability delegation is not a solution for your problem:

> Rather than delegate the gesture, delegate what the gesture enables, this way we're not tying the specific feature that's being enabled to a gesture or any other mechanism, just the fact that the feature has been enabled.

From privacy/abusability perspective, a capability-delegation-mechanism should _not_ enable the capability unconditionally.  Let’s look at popup: if the user's current settings allow popups from origin A and disallow them from origin B, a capability delegation from A to B shouldn’t suddenly allow popups from B, right?  A more compelling example is Geolocation: a site that has the user’s permission to silently use Geolocation (because the user chose “always allow” in the past) shouldn’t be able to transfer the silent access to any third-party (say ad) subframes.

Therefore, if we want developers to know if they can open a popup, we would need a separate (popup-specific or generic) API for that.  Delegation is not a solution for that.

From a different perspective, each capability has a context, and the whole context can’t be transferred through a capability-delegation-mechanism.  This confuses developers even with the “permanent” delegation we have today: does `<iframe allow=fullscreen>` mean
- the subframe gets unconditional access to fullscreen (say, w/o user activation), or
- it gets just the permission to try fullscreen, subject to all regular checks (including user activation)?

Any capability that needs delegation would have its own corner cases, and should address this question from its own perspective IMHO.

#### Temporary delegation is not activation expiry

@ojanvafai: If we tie the notion of “time” in “_temporary_ delegation of capabilities” with the expiry time in user activation, this becomes problematic because different activation-gated APIs rely on user activation state differently.

If we transfer one capability (say popup) to a target frame, would we retain other capabilities (say, fullscreen) in the sender frame?  I think we meant "yes" here, right?  Then every activation-gated API would need to be tracked in every frame.  This is like a user activation state for every gated API, with complicated logic to sync states during trigger, expiry and consumption.  This doesn’t fit our philosophy of [UAv2](https://mustaqahmed.github.io/user-activation-v2/): simplicity of the underlying model for sake of interop.  Separating input (user activation) from capability looks like a good tradeoff that maintains simplicity while providing reasonable control...


#### Fine-grained control on API availability is already there

> It also gives the author more fine-grained control about what can be done in the delegated iframe.

I will clarify my last post: we can achieve this through existing means (iframe allow or feature-policy).  Using user activation transfer on top of this allows temporary access during “unowned” user interaction (i.e. user activation on a different frame).


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/347#issuecomment-479600623