• UI Issues In Mobile Browsing

UI Issues In Mobile Browsing

Previous studies reveal that the 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 (see "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 applications and technologies demanding more resources. This fundamental gap keeps phones away from the rich mobile browsing experience.

While mobile browsing usability has recently got more attention in academia and 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 to 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 a limitation. Favicons are not displayed either.

Mind that 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 to display. In between, upcoming 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. Some phone browsers fail to disable the T9/iTap and capital features during logon. As a result, authentication takes longer time and becomes error prone creating extra barriers 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 about to take place missing password management activation.

We didn’t find any master password to open the password management feature. One possible reason is that such a feature is not needed in mobile phones since such devices are mostly personal and not multi-user. Thus, threats such as when a user loses an unlocked phone or when a user leaves an unattended phone, can be exploited by an attacker who impersonate the user by accessing sites requiring authentication.

Modified Look and Feel

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, e.g. brand logo, colors, page layout, interaction. Any change to the site’s layout may create suspicion, unless organizations themselves design mobile-adapted pages that users are aware of.

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 saved

We found that downloaded browsers need user consent to access the internet each time the browser is started, which is not the case for the embedded browser that accesses the Internet without asking for consent. One possible reason is that a downloaded browser is not a trusted application and an attempt to access the Internet could be associated with a payment. Thus, 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 proxies a secure end-to-end connection security by replacing it with hop-by-hop security. As a result, 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.