Difference between revisions of "User Activation"
From MgmtWiki
(→Problems) |
(→Problems) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
==Problems== | ==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. | * It will always be possible for the app on the mobile device to mislead the user into acceptance of a condition which is mislabeled. | ||
| + | * It will also be possible for the app to be misled into accepting a credential where the user is not the subject (or a delegate of the Subject) of the [[Credential]].In the case the [[User Activation]] is not valid. | ||
| + | * It will also be possible for the app to be mislead into accepting a credential where the user is not the subject (or a delegate of the Subject) of the [[Credential]].In the case the [[User Activation]] is not valid. | ||
* For a [[User Activation]] to have the intended meaning it will be necessary for the app to be validated as to its [[User Experience]]. | * 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<ref>W3C Payments Working Group Minutes (2023-06-22) https://www.w3.org/2023/06/22-wpwg-minutes</ref> | * Discussions about [[User Activation]] continue on various browser mailing lists. Consider this one from the W3C Payments Working Group<ref>W3C Payments Working Group Minutes (2023-06-22) https://www.w3.org/2023/06/22-wpwg-minutes</ref> | ||
| − | <pre>smcgruer_[EST]: Recall that Payment request requires a "user activation … the user needs to have interacted with the page recently | + | <pre>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 | … we've heard that this restriction can be problematic, notably in redirect flows | ||
… imagine a site that aggregates merchants | … imagine a site that aggregates merchants | ||
| Line 26: | Line 29: | ||
(1) spam - for example, we saw good results from making popups subject to user activation | (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 | … 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 | |
| − | … 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? | 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? | ||
| Line 41: | Line 43: | ||
* In general a trusted [[User Activation]] would eventually result in a signed attestation from the app as to the user's intent. | * In general a trusted [[User Activation]] would eventually result in a signed attestation from the app as to the user's intent. | ||
* See the [https://kantarainitiative.org/download/kantara-mobile-assurance-statement/ Kantara Mobile Authentication Assurance Statement (MAAS)] for an example. | * See the [https://kantarainitiative.org/download/kantara-mobile-assurance-statement/ Kantara Mobile Authentication Assurance Statement (MAAS)] for an example. | ||
| + | |||
| + | Some common user gestures on smartphones include: | ||
| + | #Tap: Touch surface briefly | ||
| + | #Double tap: Touch surface with two quick motions (often to zoom) | ||
| + | #Drag: Move along surface without breaking contact | ||
| + | #Pinch/spread: Touch surface with two fingers to move in (pinch) or out (spread) | ||
| + | #Press: Touch surface and hold | ||
| + | #Flick: Scrolls quickly | ||
| + | #swiping | ||
| + | #shaking | ||
| + | #tilting | ||
| + | #moving | ||
| + | #rotating | ||
==References== | ==References== | ||
Latest revision as of 11:45, 17 September 2024
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.
- It will also be possible for the app to be misled into accepting a credential where the user is not the subject (or a delegate of the Subject) of the Credential.In the case the User Activation is not valid.
- It will also be possible for the app to be mislead into accepting a credential where the user is not the subject (or a delegate of the Subject) of the Credential.In the case the User Activation is not valid.
- 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.
Some common user gestures on smartphones include:
- Tap: Touch surface briefly
- Double tap: Touch surface with two quick motions (often to zoom)
- Drag: Move along surface without breaking contact
- Pinch/spread: Touch surface with two fingers to move in (pinch) or out (spread)
- Press: Touch surface and hold
- Flick: Scrolls quickly
- swiping
- shaking
- tilting
- moving
- rotating
References
- ↑ W3C Payments Working Group Minutes (2023-06-22) https://www.w3.org/2023/06/22-wpwg-minutes
