User Interface Issues for
Constrained / Mobile Devices
Overview
Previous studies reveal that mobile browsing user experience is affected by several factors such as: user’s state (predispositions, expectations, needs, motivation, mood, etc.), the mobile context (physical-, social-, temporal-, task-), mobile device, browser application, network infrastructure, and web sites [Phone Web Browsing]. Although modern mobile phones come with better processors, more RAM, higher connectivity and increased resolution screens, the gap with their desktop-LAN counterpart is likely to remain due to continuous advances in web technologies demanding more resources. This fundamental gap keeps phones far away from the rich mobile browsing experience.
While mobile browsing usability has recently got more attention in academia an industry, to our knowledge, there are no previous studies on security usability in mobile phones. The large browser fragmentation in the market (built-in phone browsers and downloadable ones) makes this task more difficult. Our findings below are a first attempt to the collect the main issues and are mainly comparative with respect to desktop security usability, but there are also some mobile-specific issues. Further investigation is encouraged.
Indistinguishable/Non-Existing Chrome
In desktops, the chrome becomes blurred when reducing the window to a small size. This issue is permanent in phone browsers due to limitations in screen size. Phone browser designers have chosen to give more space to content presentation, keeping the chrome indistinguishable at best.
Some phone browsers still allow menu interactions to control the browser or get additional security information, but for security usability purposes, the level of information varies from low to medium. In some cases, it is very cumbersome to obtain such information, requiring too many button clicks.
Fewer Security Indicators
Due to the small screen limitations, current phone browsers have prioritized to only present the security padlock when applicable. The URL bar is commonly not displayed or partially displayed. Users who are familiar with the https://prefix may become deceived by such limitation. Favicons are not displayed either.
Such design decisions should not be interpreted as a good security usability design choices according to recommendations from this group. The reason is that browser designers have made this decision due to screen size and not for risk mitigation. The day DNS becomes secure or favicons can be made cryptographically secure, such missing information would be useful. Also, future phones with larger displays may display such non-secure indicators before the fundamental security issues have been solved.
Longer time and more clicks for better security
A common web security operation is authentication with username and password. We notice that typing username and password when entering sites is more cumbersome with numeric keypads than with desktops keyboards. Predictive text technologies for mobile phones, such as T9 (Text-on-9 keys) or iTap, are not useful since usernames and passwords are normally not part of the built-in phone dictionary. As a result, authentication takes longer time and error prone. Some phone browsers fail to disable the T9/iTap feature during logon authentication creating an extra barrier for users to overcome.
Password Management
Phone browsers have started offering password management associated to sites requiring authentication so that the user skips entering username and password in phones, which provides a better experience. But password management creates confusion with some sites that use cookies instead for the same purpose. Also, some phone browsers fail to capture the fact that an authentication is taking place and thus miss to activate password management.
We didn’t find any master password to open the password management feature. On possible reason is that such a feature is not needed in mobile phones since such devices are mostly personal and not multi-user. The only possible threat is when a user looses an unlocked phone and someone else who finds the phone may abuse the sites that can be accessed via saved passwords.
As reported in many studies, users do not use the phone browser in the same extent as the desktop, and when using the phone browser they access sites previously accessed in a PC. Thus, users are become familiar with a site’s and look and feel (brand logo, colors, page layout, interaction). Any change to the site’s layout may create suspicion, unless organizations themselves design mobile-adapted pages.
We have found that browsers make a trade-off between usability and preserving look-and-feel. Some browsers keep the look and feel so that the phone browser is actually a “magnifying glass” that the user has to move to find the correct spot. Other browsers choose to modify the look and feel for usability, which may confuse users, especially when accessing sensitive sites such as banking or e-shopping.
Anti-Phishing support
Modern browsers provide users with the ability to report phishing sites and block access to them. For this purpose, browsers download lists of known phishing sites. Such features are not supported in phone browsers, probably due to traffic limitations and costs.
User policy decisions not recorded
Trusting applications and web sites requires user consent every time. One possible reason is that that in mobile phones, consent can be associated with payments and permanent delegation of such decision to the phone can lead to unwanted bills.
Proxied Security vs. e2e Security
A large amount of legacy phones are WAP-based so they reside behind a proxy that sometimes attempts to proxy an end-to-end connection by replacing with hop-by-hop. Browsing secure web sites end-to-end is not thus possible. End users may experience difficulties in understanding the security implications for proxied-security where the network side of the secure connection doesn’t terminate where expected.
[Web
Phone Browsing]
WEB BROWSING ON
MOBILE PHONES - CHARACTERISTICS OF USER EXPERIENCE.
Doctoral Dissertation, Helsinki University of Technology, Department of
Computer Science and Engineering, Virpi Roto, December 2006.