Difference between revisions of "User Activation"

Revision as of 15:28, 22 June 2023

Full Title or Meme

For the purposes of this wiki a User Activation is any positive, physical user action at the mobile device that can be interpreted as acceptance.

Context

User activation and user gesture are two different ways of interacting with a smartphone. User activation is when the user interacts with the device by tapping on the screen or pressing a button. User gesture is when the user interacts with the device by using gestures such as swiping, pinching, or zooming. User gestures are often used for navigation and can be more intuitive than user activation. For example, on some Android devices, you can use a gesture to go back to the previous screen instead of pressing the back button. On Samsung Galaxy phones, you can use finger sensor gestures to open or close the notification panel by swiping up or down on the fingerprint sensor.

Problems

• It will always be possible for the app on the mobile device to mislead the user into acceptance of a condition which is mislabeled.
• For a User Activation to have the intended meaning it will be necessary for the app to be validated as to its User Experience.
• Discussions about User Activation continue on various browser mailing lists. Consider this one from the W3C Payments Working Group^[1]

smcgruer_[EST]: Recall that Payment request requires a "user activation … the user needs to have interacted with the page recently
… we've heard that this restriction can be problematic, notably in redirect flows
… imagine a site that aggregates merchants
… the aggregator might redirect the user to a specific merchant, and the merchant doesn't want to force the user to interact with the site again
… we spoke a lot with our security/privacy team internally and our conclusion in Chrome is that the use cases are worth the (small) risk
… pull request 1009 changes PR API to not require user activation (though user agent MAY require a user activation)

Ian: How will SPC change?

smcgruer_[EST]: We eventually will change the spec, but no behavioral change

nicktr: Can you speak a bit to the risks?

smcgruer_[EST]: We have, in general, been looking at what user activation protects against. My understanding is that it doesn't protect against much, in part because it's trivial to get a user to interact with your page in some capacity.
… but user activation protects against two things
(1) spam - for example, we saw good results from making popups subject to user activation
… we have mitigations around Payment Request to not allow repeated calls to the API. You get "one for free" and afterwards require user activation
(2) the second big risk is phishing … we have a standard anti-clickjacking mechanism to prevent against this

nickTR: From a user activation perspective...the user activation in PR API is in the modal. Is user activation within the modal, or anywhere on the site?

smcgruer_[EST]: The user activation is pre-modal

Ian: Can you do user activation through Web Driver?

smcgruer_[EST]: Web driver not active for users. And it cannot be activated within a page; it is triggered externally.

Solutions

• In general a trusted User Activation would eventually result in a signed attestation from the app as to the user's intent.
• See the Kantara Mobile Authentication Assurance Statement (MAAS) for an example.

References

1. ↑ W3C Payments Working Group Minutes (2023-06-22) https://www.w3.org/2023/06/22-wpwg-minutes