Some means to signal that a method requires user action to be called

[marcoscaceres]

Certain things in the platform require that they be initiated by user action to have an effect. For example, in PaymentRequest, a developer shouldn't be allow to call the .show() method unless the user clicked on something (within a reasonable amount of time).

Could we add an extended attribute to WebIDL that indicates "a call to this method requires user action"?

Like:

interface PaymentRequest {
  [UserGated] Promise<PaymentResponse> show();
};

And then we could work out a common security model for what "UserGated" (please bikeshed) means in the platform based on existing APIs that rely on this behavior.

(Apologies, I'm sure I've asked for this before but couldn't find the issue... it's come up again, so wanted to have another go at it as I think it could be universally beneficial).

[cyberphone]

Having battled with this mechanism in Android using URL methods for calling native "Apps", I wonder if it could be possible adding a gesture service returning a gesture/UserGated object tied to the platform and domain which could be transferred as text to another Web application for consumption.

[annevk]

https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation is the hook we already have for this. Though see whatwg/html#1903 for issues with it and whatwg/html#3123 on aligning usage across specifications. It's not immediately clear to me an IDL hook works everywhere. E.g., it would not work for the Fullscreen API.

[tobie]

Yeah, just needs to be mapped on how [SecureContext] is defined.

Are we sure it's a good enough mitigation strategy that we want to promote it (as that's sort of what adding it as an extended attribute will do)?

[annevk]

I think we should first work through the issues I referenced above. And if at some point we decide it's worth formalizing it would probably end up in the same standard that defined the concept, i.e., HTML.

[tobie]

And if at some point we decide it's worth formalizing it would probably end up in the same standard that defined the concept, i.e., HTML.

That's not what we did for secure context fwiw. I don't have an opinion as to what's best (yet), but we should go for consistency.

[annevk]

Well, given [CEReactions] we don't have that today, but I also think that [SecureContext] is rather special as its implications are a bit more broad than just adding a few steps to an operation's algorithm.

[tobie]

Oh, wrongly assumed from whatwg/html#3238 that the plan was to move those back to WebIDL.

[marcoscaceres]

I think we should first work through the issues I referenced above. And if at some point we decide it's worth formalizing it would probably end up in the same standard that defined the concept, i.e., HTML.

That seems fine. Thanks also for the pointers - they were very helpful. It also makes sense to keep it in HTML, as potentially "triggered by user activation" might need to survive a navigation... thus all seems very tightly coupled with HTML concepts and events.