- a given thing to act on their behalf
- a given application to access/control the thing
Follows are examples of (to my mind) 'bad' consent UI.
NB Although these examples are not IoT-specific, I believe the principles of what makes a good consent UI are still applicable.
Anti-Pattern 1 - Optional vs Required permissions
In the IoT context, what permissions are mandatory for the thing to have, and what are merely 'nice to have'? For example, if the thing is merely a sensor, dont ask for 'write' permissions.
Anti-pattern 2 - Unclear consent persistence
Will I be interacting with the thing going forward? or is this a one-night stand, e.g. allowing a bus stop to add the bus schedule to my calendar? Consent should reflect this
Anti-pattern 3 - Confuse The User as to Where They Are
Make sure the user knows to whom they are giving permissions.
Here is another example of confusing UI/UX. The Saga lifestreaming app has sent me to Fibit's site so that I can authorize Saga's access to my step data. But, because this is happening in a browser window embedded within the Saga app (as opposed to the default phone browser), its not clear that I'm actually presenting my Fitbit password to Fitbit.
Of course, just as important as providing the user intuitive mechanisms for granting permissions to things & applications is providing them a mechanism to view & manage (eg revoke) those permissions over time.
Anti-pattern 4 - Non-exhaustive list
Will the Saga app actually be able to see everything else other than my password?
1 comment:
There is a lot of text in these consents. At the busstop, I just want to push a button that says "Add this stop to my map".
What if there were prearranged consents that were part of the system, that I agree to in advance? Heck, what if there were standard consents, with some legal cred? Kind of like Creative Commons for IoT.
Post a Comment