Gökhan Bal
email: goekhan.bal@m-chair.de

Kai Rannenberg
email: kai.rannenberg@m-chair.de

Jason Hong
email: jhong@cs.cmu.edu

Styx: Design and Evaluation of a New Privacy Risk Communication Method for Smartphones

Modern smartphone platforms are highly privacy-affecting but not effective in properly communicating their privacy impacts to its users. Particularly, actual data-access behavior of apps is not considered in current privacy risk communication approaches. We argue that factors such as frequency of access to sensitive information is significantly affecting the privacy-invasiveness of applications. We introduce Styx, a novel privacy risk communication system that provides the user with more meaningful privacy information based on the actual behavior of apps. In a proof-of-concept study we evaluate the effectiveness of Styx. Our results show that more meaningful privacy warnings can increase user trust into smartphone platforms and also reduce privacy concerns.

Introduction

Technological innovations in the area of consumer electronics developed by far faster than our ability to assess their implications on our social lives. Information privacy is one of the facets in consumer life that experiences the most substantial change. For the sake of innovation and utility, consumers have unconcernedly (or unknowingly) given away the control over their personal data. Most designers of privacy-affecting systems3 don't define the protection of consumer privacy as a primary goal and thus, privacy-awareness or privacy-protection mechanisms usually are not a prominent feature in most technologies.

Modern smartphone platforms have unique properties that make them highly privacy-affecting, i.e. they are always on, they are connected to the Internet, they follow their users in space and time, they are open to third-party applications, and they provide those applications with access to a multiplicity of sensitive resources such as the GPS module, the user's contacts, call log, or browsing history. The dynamics and the quantity of sensitive information flows on smartphone platforms require sophisticated approaches for giving back the consumers the control over their data. According to the Privacy Space Framework, information privacy protection is a process that starts with awareness and detection of privacy issues [START_REF] Brunk | A User-Centric Privacy Space Framework[END_REF]. Consequently, solutions have also to improve these two mechanisms.

The use of personal data by third-party applications affects the users' privacy in varying extent. Factors influencing the extent are e.g. the type of data that is processed, the frequency of access, or the destination of sensitive information flows. Ideally, privacy-awareness solutions reflect those dependencies in their underlying mechanisms. In practice, the users are too often not even aware that sensitive resources have been accessed by applications. Privacy-related notices are in most cases not successful in informing the users appropriately about the actual privacy risks of the services. One major explanation for this is that in most cases the underlying model for privacy risks is limited to access-control information such as granting an application access to some resources. Other commonly known explanations are the extensive length of privacy policies, the frequent use of technical or legal terminology, or the inappropriate timing of privacy notices. We argue that privacy-awareness measures should move from access-control level to privacy-impact level. In other words, privacy-awareness systems should not (solely) inform users about single information flows. Instead, the mechanisms should reason about multiple information flows that happen over time and look at the actual privacy-impacting behavior of an app. The (user-facing) outcome of those mechanisms should be concrete privacy-impact information that relate to the individual behavior of apps. In this paper we propose Styx4 , which is such a privacy-awareness system for smartphone platforms. We use privacy-impacting behavioral patterns (PIBP) [START_REF] Bal | Revealing Privacy-Impacting Behavior Patterns of Smartphone Applications (Short Paper)[END_REF] as the conceptual basis for our system. PIBPs are a model for privacy impacts that bridge the gap between multiple information flows and their impact on user privacy.

The contributions of this paper are as follows: 1. we present the design principles and a proof-of-concept implementation of Styx, a novel privacy-awareness system for the Android smartphone platform, 2. we present results from an experimental evaluation of Styx to demonstrate its utility, focusing on human factors. We contribute to the knowledge base of information privacy technology design, especially regarding privacy risk communication methods.

The paper is structured as follows. Section 2 summarizes and integrates relevant concepts and theories from the knowledge base. Section 3 provides some key definitions and subsequently presents design principles for Styx that we have identified from information privacy literature. Section 4 then introduces and elaborates in more detail the conceptual basis for Styx, namely the privacyimpacting behavioral patterns. Following on that, Section 5 proposes an architectural design for Styx. The components of Styx that we have developed as proof-of-concept are introduced in Section 6. Details about the evaluation are presented in Section 7. We conclude this paper with a discussion on the results (Section 8).

Related Work

This section provides an overview of the relevant literature in smartphone privacy research, which will help to understand how our research on Styx was informed by the body of knowledge. Due to space restrictions, we do not describe single research results in detail.

The Nature of Privacy Risks of Smartphone Usage. On the very basic level, the privacy risks of smartphone app usage are about the leakage of sensitive information from the user's device [START_REF] Thampi | Path uploads your entire iPhone address book to its servers[END_REF]. With TaintDroid, Enck et al. [START_REF] Enck | TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones[END_REF] revealed that privacy-breach incidents are not rare, many apps are sending sensitive data to their servers without informing the user. On a more semantic level, privacy risks result due to the long-term usage of apps. Data mining-based approaches demonstrate the potentials of inferring user identity-related information based on data that is available on the devices or collected by apps over time. Kwapisz et al. show how collected accelerometer data can be used to uniquely identify the user [START_REF] Kwapisz | Cell phone-based biometric identification[END_REF]. Weiss et al. [START_REF] Weiss | Identifying user traits by mining smart phone accelerometer data[END_REF] show how the same source of information can even be used to identify user traits such as sex, height, and weight of the user. Similar results can be found in [START_REF] Chittaranjan | Mining large-scale smartphone data for personality studies[END_REF], [START_REF] Min | Mining Smartphone Data to Classify Life-Facets of Social Relationships[END_REF], [START_REF] Eagle | Inferring Social Network Structure using Mobile Phone Data[END_REF], [START_REF] Phithakkitnukoon | Activity-Aware Map: Identifying Human Daily Activity Pattern Using Mobile Phone Data[END_REF], and [START_REF] González | Understanding individual human mobility patterns[END_REF].

Smartphone Users' Perception of Privacy Risks. Privacy indicators or warnings should both motivate users to respond, and help them understand the risk of the used services [START_REF] Bravo-Lillo | Improving Computer Security Dialogs[END_REF]. Besides privacy policies that exist for some apps, Android's permission request screen, which shows up each time the user wants to install an application, can be regarded as Android's main indicator for the potential impacts on user privacy. However, researchers have demonstrated that permission screens are not effective privacy indicators. Often users don't notice this screen or they have difficulties in understanding the risk signals [START_REF] Kelley | A Conundrum of Permissions: Installing Applications on an Android Smartphone[END_REF]. Chia et al. showed that none of the existing risk signals in the smartphone app ecosystem are effective as indicators for the privacy risks [START_REF] Chia | Is this App Safe ? A Large Scale Study on Application Permissions and Risk Signals[END_REF].

Alternative Privacy Indicators. Kelley et al. [START_REF] Kelley | A "nutrition label" for privacy[END_REF] used the nutrition-label approach to represent privacy information taken from privacy policies of online services. Another approach to improve privacy information on the Android platform is to use attribution mechanisms which is a method to indicate which source (i.e. app) was responsible for a security or privacy-related action on the device, e.g. which app last changed the wallpaper of the device [START_REF] Thompson | When it's better to ask forgiveness than get permission[END_REF]. The approach taken by Lin et al. [START_REF] Lin | Expectation and Purpose: Understanding Users Mental Models of Mobile App Privacy through Crowdsourcing[END_REF] to increase the usefulness of Android permissions is to add empirical information about how other users feel about the respective request, e.g. "95% of users were surprised this app sent their approximate location to mobile ads providers". [START_REF] Egelman | Timing is everything?: the effects of timing and placement of online privacy indicators[END_REF] could show that the timing had a significant impact on the behavior of users in the context of online shopping [START_REF] Egelman | Timing is everything?: the effects of timing and placement of online privacy indicators[END_REF]. Alternative designs for privacy indicators have an effect on the user's behavior, but yet so far there is no approach that considers the multiplicity of potential sensitive information flows and their very dynamic nature on smartphone platforms when modeling privacy risks.

Technologies for Enhanced Privacy Control. Many tools have been developed in recent years that aim to analyze or enhance the privacy level of smartphone platforms. One category of such tools are information flow analyzers that analyze smartphone applications regarding potential privacy breaches before they are installed on users' devices. Some of the more prominent examples are Kirin [START_REF] Enck | On Lightweight Mobile Phone Application Certification[END_REF], AppInspector [START_REF] Gilbert | Vision: automated security validation of mobile apps at app markets[END_REF], Stowaway [START_REF] Felt | Android permissions demystified[END_REF], SCanDroid [START_REF] Fuchs | SCanDroid: Automated Security Certification of Android Applications[END_REF], PiOS [START_REF] Egele | PiOS : Detecting Privacy Leaks in iOS Applications[END_REF], TaintDroid [START_REF] Enck | TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones[END_REF], and XManDroid [START_REF] Bugiel | XManDroid: A New Android Evolution to Mitigate Privilege Escalation Attacks[END_REF]. Except for Kirin, the mentioned approaches have a limited model for the actual privacy risk.

Enhanced Information Flow Control. Some privacy tools provide the users a more fine-grained or context-sensitive control over their data. Examples are TISSA [START_REF] Zhou | Taming information-stealing smartphone applications (on Android)[END_REF], Apex [START_REF] Nauman | Apex : Extending Android Permission Model and Enforcement with User-defined Runtime Constraints[END_REF], CRePE [START_REF] Conti | CRePE: Context-related Policy Enforcement for Android[END_REF], and ConUCON [START_REF] Bai | Context-Aware Usage Control for Android[END_REF]. Another form of enhanced information flow control for smartphone users is replacing real data with mocked data when apps want to access sensitive resources [START_REF] Hornyack | These aren't the droids you're looking for: retrofitting android to protect data from imperious applications[END_REF] and [START_REF] Beresford | MockDroid: trading privacy for application functionality on smartphones[END_REF]. The concepts listed here are useful approaches for the prevention and response phases of information privacy control. Our focus is on the awareness and detection phases of the privacy space framework.

Design Principles and Guidelines

Existing literature on privacy theories and tools provide valuable guidelines for the design of privacy mechanisms. Our requirements analysis for Styx resulted in a set of principles and guidelines that we present in the following. Also, we introduce some key terms that will help the reader in integrating our contributions into the bigger picture of privacy research.

Working Definitions and Relevant Concepts

We see information privacy rather as a process as defined in the Privacy Space Framework [START_REF] Brunk | A User-Centric Privacy Space Framework[END_REF]. The proposed phases of information privacy management are awareness, detection, prevention, response, and recovery. With Styx we target the phases awareness and detection. Another important concept that informed our research was the concept of Exoinformation. Generally speaking, exoinformation is new information that is gathered by putting together and analyzing available information [START_REF] Brunk | A User-Centric Privacy Space Framework[END_REF]. The PIBP approach introduced in Section 4 can be regarded as a specific implementation of the exoinformation concept.

Design Principles

From the usable privacy literature we have identified a set of design guidelines that inform the design of Styx:

avoid the use of privacy jargons (DP1), communicate the existence of a threat (DP2) [START_REF] Lederer | A Conceptual Model and a Metaphor of Everyday Privacy in Ubiquitous Computing Environments[END_REF], filter information and alert users only to potentially important or new concerns and threats (DP3), minimal distraction (DP4), do not obscure actual and potential information flow (DP5) [START_REF] Hong | An Architecture for Privacy-Sensitive Ubiquitous Computing[END_REF], provide educational opportunities to users (DP6) [START_REF] Cranor | Security and Usability -Designing Secure Systems that People Can Use[END_REF], provide meaningful summaries of privacy information (DP7), consider exoinformation (DP8).

Privacy-impacting Behavioral Patterns

As the conceptual basis for Styx we use privacy-impacting behavioral patterns [START_REF] Bal | Revealing Privacy-Impacting Behavior Patterns of Smartphone Applications (Short Paper)[END_REF]. The basic idea behind the PIBP concept draws on the concept of exoinformation. The most common approach for privacy notices is to inform users about single, potentially privacy-impacting, information flows. In this case, privacy risks are modeled as a single data leakage 5 . The assumption here is that consumers are able to map that specific information flow instance to the impact it will have on their privacy. The information-flow level approach does not consider long-term aspects such as frequency of access or combinations with information flows of other type. Location information for example is dynamic, thus it is a function of time. A one-time access to the resource will not exploit the full potentials of knowledge extraction. Rather, the more often an application accesses the user's current location, the more information can be extracted about the user. An app that accesses the user's location every 30 minutes could infer where the user lives, where he works or goes to school, which locations he visits in his leisure time, and so on. In this case, the specific PIBP would be "accessing geo-location every 30 minutes or more often". One could think of much more complex examples where for example different sensitive resources are combined.

Styx

In this section we present the conceptual architecture of Styx, a PIBP-implementing, privacy-awareness system for the Android platform. We will further present a proof-of-concept implementation of Styx and demonstrate how the requirements of Section 3 are met.

Styx Architecture

Figure 1 shows the proposed components for a PIBP-implementing system. These components are introduced in the following.

Styx Monitoring. This component is responsible for dynamically monitoring sensitive information flows between the device and applications. TaintDroid [START_REF] Enck | TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones[END_REF] could be used as the implementation of this component. Styx Notification. This component is responsible for notifying the user about matches that have been identified by the pattern detection. Ultimately, this is the user-facing component of the system and therefore its design is of key importance. It uses the notification mechanisms of the smartphone platform to show the Styx UI to the user. The UI will present information about privacyimpacting behavior of the respective app.

Proof-of-Concept

We have implemented a proof-of-concept of Styx for the purpose of evaluating its effectiveness. As stated in the beginning of this paper, Styx targets the awareness and detection phases of the information privacy process. Consequently, we focused our implementation on the user-facing part of the architecture, namely the notification component and its respective user interfaces. The Styx monitoring, logging, and pattern detection mechanisms are simulated in the proof-of-concept. The Styx UI is composed of six different screens that represent different types 1. Styx Notification. The first screen that the user sees is the notification and the respective entry in the notification menu (a. in Figure 2). 2. Styx Inference Screen. This is the landing page of Styx after the user clicks on a notification entry. The purpose is to visually communicate what identity-related inference the currently used app could make about the user (in the simple example it's the user's gender; b. in Figure 2). 3. Styx Rating. The purpose is to help users understand whether the applications behavior is unusual or rather something expected. Factors that influence this rating are the functionality of the app and also a comparison with apps of the same category (e.g., "Are similar apps also able to determine the user's gender?"). 4. Styx Basis Screen. We want to make the underlying mechanisms of Styx transparent to the user by also informing him about the privacy-impacting behavior of the app (i.e., which resources did it access in what manner?). At the same time, this is an educational part of Styx (DP6). The users will be able to better understand the relation between concrete privacy impacts and access to sensitive information (c. in Figure 2). In the example, the app has accessed the list of installed applications and is able to see the high number of sports-related apps on the device. 5. Styx Detailed Pattern Information. In its approach to provide ondemand access to more detailed information, Styx shows the user more detailed information when he clicks on the "Learn more..." part of the inference screen. 6. Styx Dashboard. This screen is essential to communicate the overall privacyinvasiveness of an application. It summarizes what other identity-related information the current app has already inferred in the past (DP7). Each information item can be clicked on to open the detailed information screens.

The goal was to make this screen very concise, intuitive, and visually attractive. The Styx Dashboard plays an important role in enabling the comparison of privacy-related properties of different apps (d. in Figure 2).

Meeting the Requirements

Styx is an implementation of the PIBP concept. As such, actual and potential information flows are considered when assessing the privacy impacts of app behavior (DP5). Furthermore, the PIBP concept can be regarded as an instantiation of the exoinformation concept, thus exoinformation are considered by design (DP8). The ultimate goal of Styx is communicating the existence of privacy threats. It does so by analyzing what potential identity-related inferences an app can make about the user, based on what is has accessed so far and then inform the user about these specific threats (DP2). Another advantage of the PIBP approach is that it does not notify the user on information-flow level. Rather, multiple information flows are observed, aggregated and analyzed (DP3). Only when a certain privacy-impacting behavior has been detected, the user gets notified, so the number of distractions from the user's primary task is reduced (DP4). In the Styx UI, we avoid technical terms (DP1), educational opportunities are provided by the Styx Basis Screen and the Styx Detailed Information Screen (DP6). A privacy summary of an app is provided by the Styx Dashboard (DP7).

User Study

We evaluated the Styx proof-of-concept in a user study in spring of 2013. We set up an in-lab experiment at Carnegie Mellon University. We recruited participants through the CBDR Participant Portal6 of the university. We invited people to "A User Study about Smartphone apps". Participants were compensated with a $10 gift card for their time.

Participants

In total, 77 participants registered for the user study. 50 of those showed up during the two-week experiment phase. 18 of the participants were female (36%), 32 were male (64%). M age =25.56 (SD=7.18). 27 of the participants had permanent residence in the U.S. (54%), 23 had permanent residence in another country (46%). 2% of the participants owned a smartphone for less than 1 month, 6% for 1-3 months, 20% for 3-12 months, 14% for 1-2 years, 26% for 2-3 years, 8% for 3-4 years, and 24% for more than 4 years. The participants had installed M =25.54 apps (SD=25.32) on their devices and used M =9.12 apps regularly (at least once a week; SD=7.13).

Experimental Design

The experiments have been conducted in the Human-Computer Interaction Institute at Carnegie Mellon University. We invited one participant at a time to do the experiment, which took approximately one hour per participant. We used a between-subjects design for the experiment, since we wanted to test Styx against an alternative approach that is based on current risk communication schemes. Before starting the experiment, participants were randomly assigned to one of the two conditions. We handed the participants a smartphone7 on which the respective tool was running in the background. After introducing them to the key UI concepts of the device, we handed them an instruction sheet containing a step-by-step description of what they should do with the device. The tasks were mainly about starting specific apps8 and using some of their core features.

In pre-defined points in time, the device showed notifications in the notification bar and played a sound while showing up. Participants in the experimental condition have been shown the Styx privacy user interfaces, participants in the control condition have been faced with an alternative run-time privacy UI that will provide the user with a chronologically ordered information flow history. By introducing a run-time component to the control condition, we made the comparison fair 9 . The participants were free to examine the notifications. Only in the case of the weather and the running app we explicitly instructed them to examine the notification and the respective user interfaces.

Collected Data

During the experiments, we collected a variety of data that would allow us to evaluate the effectiveness of Styx according to our evaluation targets.

Questionnaire The main goal of the user study was evaluating the new privacy risk communication method regarding comprehension of the communicated privacy information. However, it is also important to look at the impact of the new approach on user trust and privacy concern. We believe that effective transparency mechanisms can increase trust into the smartphone platform and reduce privacy concern. Therefore, we added these two variables as dependent variables to the questionnaire. We proposed Styx as an innovative approach to communicate privacy risks of smartphone apps. To assess novelty, we used the respective scale from the User Experience Questionnaire (UEQ) (Laugwitz et al. [START_REF] Laugwitz | Construction and Evaluation of a User Experience Questionnaire[END_REF]). Participants had to complete the questionnaire after the experiment on a computer in the lab. All items were rated on a 6-point Likert scale ranging from "strongly disagree" to "strongly agree". Example items: "The privacy information was self-explanatory" (comprehension), "I trust this smartphone to protect the user's data against harmful apps" (trust), "I'm concerned that the apps have accessed personal data without informing me" (concern), "The presented privacy user interfaces were innovative" (novelty).

Qualitative Data As part of the evaluation, we also asked the participants in the questionnaire what they particularly liked and did not like about the new privacy user interface. Participants could enter up to five aspects per question.

Data Analysis

Questionnaire Figure 3 shows the mean scores for the concern, trust, comprehension, and novelty scales for the two conditions. The experimental group scores better in all four scales, while the differences in the concern (M exp =4. ). Eight responses on the other hand were about how annoying the notifications were during the experiment (example answer: "I disliked the constant notification") 10 . Three responses were about the usability of the UI (example answer: "I also did not like the graphical interface").

Nine responses were about some functionality that participants would additionally expect (example answers: "I would have loved if the app could suggest me another app with same functionality but lesser data access", "It should pop up before the app starts sending data"). Looking at the responses to the question "what did you like about the privacy user interface?", there were noticeably more responses that refer to the comprehensibility and usability of the UI. In total, 13 responses can be classified as such (example answers: "The notifications were self-explanatory", "The notifications covered all the information regarding the app using personal info in brief sentences"). Nine responses can be classified as relating to the usefulness or the perceived purpose of the privacy user interfaces (example answers: "I liked that I could see a list of these icons and use that list to compare one app to another", "I liked the icons categorizing the types of data that Styx detected"). In sum, the analysis of the qualitative data revealed some existing issues with Styx (e.g. people expect additional information or instructions on what to do next), some of them being caused by the experimental design, however, regarding the comprehension and usefulness of the privacy user interfaces, Styx was quite successful in achieving its goals.

Discussion and Conclusion

Styx is our proposed approach to provide smartphone users with more intuitive and semantic privacy information about their apps. Our aim was to increase the comprehensibility of privacy risks, and at the same time increase trust and reduce concern towards the smartphone. Our data shows that Styx scores very well regarding these aspects. Compared to traditional privacy risk-communication approaches, the Styx privacy user interfaces were more comprehensible and participants also appreciated it being an innovative approach for privacy warnings. The qualitative data further revealed that Styx is easy to understand and use. At the same time, the data clearly shows that such an privacy-awareness system should only be deployed in combination with privacy control mechanisms. This is in-line with the Privacy Space Framework, where the phases prevention, response, and recovery immediately follow the phases of awareness and detection. Our results further show that more effective transparency mechanisms can increase user trust towards the smartphone and significantly reduce privacy concerns when interacting with the device. We believe that smartphone vendors could use such trust mechanisms as competitive advantage in future when even more operating systems and apps will be available in the smartphone ecosystem. We also want to note that run-time privacy warnings should not be the ultimate way to communicate privacy information to the user. Privacy risk communication should happen as early as possible (e.g. in the app discovery phase). However, the basic principle behind the PIBP approach is monitoring application behavior during run-time and thus, run-time notifications are a suitable method to detect and communicate privacy-impacting application behavior. We further propose that gathered privacy information about apps should be fed back into the privacy risk communication in the app discovery phase, e.g. they could be integrated into the app markets. This will further help users in making safer decisions at the right time. With Styx we contribute to the knowledge base of human factors in privacy by developing and testing a new method to model and communicate the privacy-related impacts of smartphone usage. We also contribute to the design knowledge for more intuitive privacy-awareness mechanisms.

Fig. 1 .

 1 Fig. 1. Conceptual architecture of Styx

Fig. 2 .

 2 Fig. 2. Styx screenshots

Fig. 3 .

 3 Fig. 3. Mean values of the questionnaire scales

  62, M ctrl =5.46) and novelty (M exp =4.33, M ctrl =3.58) scales are statistically significant (p<.05). There are strong tendencies in the mean values of the trust (M exp =3.66, M ctrl =2.97) and comprehension (M exp =4.26, M ctrl =3.86) scales. Qualitative Data When looking at the responses to the question "what did you not like about the privacy user interface?", four responses were related to the comprehensibility of the information (example answer: "It just took some time to figure out what Styx was about"

Based onLederer et al. (2005) [START_REF] Lederer | A Conceptual Model and a Metaphor of Everyday Privacy in Ubiquitous Computing Environments[END_REF], we define privacy-affecting systems as any interactive system whose use has personal privacy implications.

Inspired by the river "Styx" from Greek mythology, which formed a boundary between the world of the living and the Underworld. We use this as a metaphor for sensitive information flows between the user's "realm" and the hidden, "dark side" of the smartphone device.

Simple example: "Application A wants to access your location"

The CBDR Participant portal is an online system that help researchers in organizing their user studies.

Samsung Galaxy S3 LTE.

We used five types of apps during the experiment: flashlight, weather, dice, running tracker, and a kids memory game

Otherwise, the pure existence of privacy information in the experimental group would lead to biased data.

The issue with the notifications is due to the experimental design where multiple notifications were simulated in a short time frame. In a real setting, these notifications would occur less frequently.

Acknowledgments. This research was partially funded by the Vereinigung von Freunden und Förderern der Johann Wolfgang Goethe-Universität and the Faculty of Economics and Business Administration at Goethe University Frankfurt. We further thank Tahmine Tozman for her advice concerning the experimental design and Ralf Strobel for his support in implementing the prototype.


Bastian Braun

Martin Johns
email: martin.johns@sap.com

Johannes Koestler
email: koestler@fim.uni-passau.de

Joachim Posegga

A Trusted UI for the Mobile Web

Modern mobile devices come with first class web browsers that rival their desktop counterparts in power and popularity. However, recent publications point out that mobile browsers are particularly susceptible to attacks on web authentication, such as phishing or clickjacking. We analyze those attacks and find that existing countermeasures from desktop computers can not be easily transfered to the mobile world. The attacks' root cause is a missing trusted UI for security critical requests. Based on this result, we provide our approach, the MobileAuthenticator, that establishes a trusted path to the web application and reliably prohibits the described attacks. With this approach, the user only needs one tool to protect any number of mobile web application accounts. Based on the implementation as an app for iOS and Android respectively, we evaluate the approach and show that the underlying interaction scheme easily integrates into legacy web applications.

Introduction

Since the introduction of the original iPhone in 2008, mobile devices are first class citizens in the world of computing. Due to the impressive advances in energy consumption, mobile processor power, and display quality, the majority of the common computing tasks can nowadays be done as easily on a mobile device as on a "real" computer on the desktop.

However, while the computational power of the mobile devices is almost comparable to their desktop counterparts, other key differences, in areas such as screen estate, UI paradigms, or operating system induced limitations, remain for the foreseeable future. These differences have a significant impact on the device's security characteristics: Reduced screen estate results in significant less space for visual security indicators that could help combating phishing attacks [START_REF] Amrutkar | Measuring SSL Indicators on Mobile Browsers: Extended Life, or End of the Road?[END_REF][START_REF] Felt | Phishing on Mobile Devices[END_REF]. Changed user interaction paradigms allow for different clickjacking variants [START_REF] Luo | Touchjacking attacks on web in android, ios, and windows phone[END_REF]. Virtual keyboards on mobile devices lead to choosing insecure passwords, due to necessary, uncomfortable context switches between letters, numbers, and special characters [START_REF] Felt | Phishing on Mobile Devices[END_REF]. And finally, the current restrictions in mobile operating systems and the lack of an extension model for iOS' mobile browser render most of the currently proposed attack mitigation tools impossible on mobile devices.

As we will explore in Section 2, these limitations especially amplify security threats against mobile web authentication. For this reason, we propose a novel authorization delegation scheme using a native application, the MobileAuthenticator, that functions as a companion application to the mobile web browser. In this paper, we make the following contributions:

-We analyze how common web authentication attacks, such as phishing or clickjacking, manifest themselves in mobile scenarios and identify a common root cause -the lack of a trusted UI of the browser. -We propose a novel authorization delegation scheme for mobile web applications that leverages a native companion application. It serves as a trust anchor for the mobile web application's client side through providing the missing trusted UI capabilities. -We report on a practical implementation of our system as an app for the two currently dominating mobile operating systems, iOS and Android. In this context, we show how the concept can be realized through leveraging the platform-specific facilities for inter-app cooperation.

In the remainder of this paper, we first cover relevant attack classes that target web authentication mechanisms and discuss their specific characteristics in mobile web scenarios (Sec. 2). Then, we present our solution in Sec. 3. In Sec. 4, we document our practical implementations for iOS, Android, and Wordpress. The security and usability properties of our scheme are evaluated in Sec. 5. After revisiting related work in Sec. 6, we conclude the paper in Sec. 7.

Security Threats

In the last decade, numerous security problems in the field of web applications have been discovered and documented, among them phishing, cross-site scripting (XSS), cross-site request forgery (CSRF), session fixation, or clickjacking. In this section, we discuss the listed security threats in respect to how they apply to mobile web applications. Furthermore, we explore if previously proposed solutions can be adopted in a mobile environment.

Threat Classes

In general, mobile web applications are susceptible to the same class of threats as their desktop counterparts. However, it has been shown that several attack types, such as phishing or clickjacking, are harder to solve in the mobile scenario, due to their direct interplay with the available screen estate and web browser chrome [START_REF] Felt | Phishing on Mobile Devices[END_REF][START_REF] Rydstedt | Framing Attacks on Smart Phones and Dumb Routers: Tap-jacking and Geo-localization Attacks[END_REF][START_REF] Amrutkar | Measuring SSL Indicators on Mobile Browsers: Extended Life, or End of the Road?[END_REF]. In this section, we list applicable security issues and briefly discuss special aspects of the mobile case. Phishing: The term phishing subsumes all attacks that aim to obtain the user's password via tricking the user to interact with a web resource that claims to be a legitimate part of the targeted web application but in fact is under the control of the attacker. It has been shown [START_REF] Niu | iPhish: Phishing Vulnerabilities on Consumer Electronics[END_REF][START_REF] Felt | Phishing on Mobile Devices[END_REF][START_REF] Amrutkar | Measuring SSL Indicators on Mobile Browsers: Extended Life, or End of the Road?[END_REF] that mobile web applications expose a higher level of susceptibility to such attacks, mainly due to the significantly reduced availability of optical indicators, such as browser chrome or SSL indicators.

Clickjacking: A clickjacking attacker deludes the user concerning the context and target of her actions to make her click in the attacker's interest. For the mobile case, Rydstedt et al. [START_REF] Rydstedt | Framing Attacks on Smart Phones and Dumb Routers: Tap-jacking and Geo-localization Attacks[END_REF] coin the term tapjacking for this attack vector as users do not click but tap on their mobile devices. One of their techniques is zooming elements of the target web page. They found that the hosting (i.e., attacking) page can set a zoom factor overriding the iframe's own scaling. This way, an attacker can include a transparent "Like" or "Tweet" button fitting the entire width of the screen. CSRF: A CSRF attacker inserts a crafted link into some website that makes the browser send a request to the target web application, seemingly on behalf of the user. The mobile case is similar to the desktop scenario with a slight exception: Client-side protection approaches like CsFire [START_REF] Ryck | CsFire: Transparent Client-Side Mitigation of Malicious Cross-Domain Requests[END_REF] do not work because mobile browsers have no or not sufficient extension support. XSS: The XSS attacker is able to inject malicious script code into benign web pages. The code runs in the context of the benign domain and can impersonate the user. There is actually no difference between XSS attacks on mobile browsers and desktop browsers. Session fixation: During a session fixation attack, the attacker sets a session identifier before the user logs in. The attack is successful if the SID is not changed during the login. The attacker's window of opportunity lasts until the user logs out. The mobile case is very similar to the desktop case. However, sessions in some mobile web applications expire later [START_REF] Rydstedt | Framing Attacks on Smart Phones and Dumb Routers: Tap-jacking and Geo-localization Attacks[END_REF], or do not expire at all but only delete the client-side session cookie upon logout [START_REF] Bursztein | SessionJuggler: Secure Web Login from an Untrusted Terminal Using Session Hijacking[END_REF]. This extends the attacker's control over the user's account.

On the Infeasibility of Existing Mitigation Approaches in Mobile Web Scenarios

In this section, we discuss several potential solutions to the outlined security problems and show their insufficiency in the realm of mobile web applications.

Client-side SSL authentication: The current generation of -at least Android -smart phones is missing proper tools support for certificate management. Furthermore, the usage of this authentication method only solves a subset of the identified security implications, i.e., all issues that exist in connection with the potential stealing of passwords (i.e., mainly phishing). However, security problems that concern attacker-initiated state changes (e.g. caused by XSS, CSRF, or clickjacking) remain unprotected.

Browser extensions or plugins: A potential approach to overcome shortcomings of web browser-based applications is to include the security mechanism directly into the browser using a browser extension or plugins, such as Silverlight or Flash. However, the web browsers in current smart phones do not support plugins 3 , and the only browser offering support for extensions is Firefox Mobile for Android with only a limited number of APIs4 .

Dedicated modified browsers: It is possible to deploy dedicated web browsers to mobile devices, which incorporate enhanced security mechanisms. However, they can not be used within applications that offer an integrated web-view, nor can they be set to serve as the default browser on iOS platforms, thus, excluding roughly half of all users. Finally, developing and maintaining a special browser variant is of high effort and cost, which is also a major roadblock for this potential approach.

Local network-layer helpers: Finally, there are several approaches that rely on local network-layer utilities, such as HTTP proxies. Such tools cannot be deployed to the current generation of mobile devices.

Root Cause Analysis

Generally speaking, a web application is a reactive system. The web server receives incoming HTTP requests and reacts according to the implemented business logic of the application. A subset of the incoming requests lead to changes in the server-side state while others only retrieve data stored on the server. If received as part of an authenticated session, the first case may represent security sensitive actions on the application data. The handling of such requests requires special attention. Within this paper, we will repeatedly utilize the term authorized action.

Definition 1. Authorized Action An authorized action is a security sensitive event on the server that is triggered by an incoming authenticated request, meaning that the user authorized the web application to perform the requested action on her behalf.

Which events have to be considered security sensitive highly depends on the internal logic of the application. Hence, the applicable set of authorized actions has to be determined on a per-application basis. Frequently encountered examples include the login into the application, changing the user's data record, and ordering and purchasing of services or goods. For all such actions, the underlying assumption is that the owner of the credential (password or authenticated SID) is the originator of the triggering event and that the details of the action have not been tampered with by unauthorized third parties. All discussed security issues have in common, that the application's back-end component (i.e., the web server) cannot distinguish authorized actions, which have been conducted intentionally by the user, from authorized actions, that have either been conducted directly by the attacker (e.g., through credentials that have been stolen via phishing or XSS) or have been initiated by the attacker via tricking the user (through clickjacking or CSRF). What web applications are missing is a trusted path between the user and the back-end system. The back-end system needs reliable evidence, that the initiated security sensitive actions have indeed been deliberately conducted by the user:

Definition 2. Trusted Path An application provides a trusted path, if it can be verified on the server-side that all incoming authorized actions are caused with the user's explicit consent and that their integrity is ensured. The general idea of our approach is to establish a trusted path between the user and the web application in order to protect the user against the attacks given in Sec. 2.1. We implement the approach as an app but we envisage it as an integral feature of mobile operating systems. The mobile application enables the user to communicate securely with the web application's server side using authorized actions that (1) have been explicitly initiated by the user, (2) thus are fully intended by the user, instead of being created without her consent (i.e., through clickjacking or XSS), and (3) have not been tampered with. This way, the security functionality is strongly separated from the web application's browser-based front-end, and hence, the web-specific weaknesses and limitations do not apply anymore. The actual application logic can still be implemented as a cross-platform web application which can be accessed on any web-enabled mobile device. The only part that needs to be implemented as a native application for each mobile platform is the MobileAuthenticator. The MobileAuthenticator itself provides generic security functionality. As a consequence, it can serve as a trusted interface for more than one mobile web application.

Providing a Trusted Path Through an App

We propose to introduce the MobileAuthenticator as a dedicated system app that serves as a trust anchor for the user in the communication with the web application. It establishes a trusted path between the UI and the application's back-end. However, as extending modern mobile operating systems is out of our scope, we describe the approach as an app that can be installed by the user. Concept The MobileAuthenticator is a dedicated application that encapsulates the user's credentials and authorization state and that maintains a trust relationship with the web server. Authorized actions are routed through the MobileAuthenticator on behalf of the web application. The mobile web browser never receives, processes, or sends credentials that can be utilized for conducting authorized actions. This way, the MobileAuthenticator serves both as a trusted UI for the mobile web interface as well as a second authentication factor, effectively elevating all supporting web applications to using an implicit two-factor authentication scheme.

Interaction Pattern For most purposes, the interaction between the web browser and the mobile web application remains unchanged. Only in cases, when the user initiates an authorized action, the control flow is routed via the MobileAuthenticator, implementing a challenge/response scheme to capture the user's intend.

1. Using a dedicated interaction bridge between the web browser and the Mo-bileAuthenticator, the authorized action, which is supposed to be triggered, as well as all needed parameters including the server's challenge are passed over to the app. 2. The user explicitly acknowledges the authorized action in the trusted UI of the MobileAuthenticator. This causes the MobileAuthenticator to compute the response to the server's challenge. 3. The MobileAuthenticator passes the control back to the browser including a dedicated credential which allows the triggered authorized action to be conducted. 4. This credential is passed from the web front-end to the server.

Please note: This process is only executed when authorized actions are conducted. For the vast majority of a user's web interaction, the web application remains unchanged (see Sec. 5.3). This also entails, that general authentication tracking is done the regular way, i.e., using HTTP cookies, and that application handling does not change significantly from a user's perspective.

Components

The overall architecture consists of three main components: The actual Mo-bileAuthenticator that runs on the mobile device and provides the trusted UI, a server-side module that evaluates incoming requests and checks the integrity of the authentication token, and a JavaScript library that is delivered to the browser and takes care of delegation between all participants. MobileAuthenticator The client-side component, the MobileAuthenticator, maintains a repository of preconfigured authorized actions (see Sec. 3.3) including a human understandable description of each action's impact. Upon receiving a security critical request from the browser, it looks up the respective action's details in its repository, displays the description to the user, and asks for consent. The MobileAuthenticator signs the request using a shared secret (see Sec. 3.3) with the web application, and passes it back to the browser, if the user agreed. Server-side Module On the web application's server side a counterpart is needed that maintains a trust relationship with the user's MobileAuthenticator instance and implements the challenge/response process to accept incoming authorized actions. AuthenticationBroker The AuthenticationBroker is a small JavaScript library that provides the necessary interface to the application's web front-end to delegate authorized actions to the MobileAuthenticator for obtaining user consent. Upon receiving the MobileAuthenticator's response, the acknowledged request is routed to the web application for processing. It is evident that the Authenti-cationBroker itself is not security critical. This is an important fact because otherwise malicious injected script code might be able to manipulate or disable the AuthenticationBroker and, thus, run an attack. The worst impact of an attack against the AuthenticationBroker, however, is a denial-of-service that prevents authenticated requests from being routed towards the MobileAuthenticator.

Initial Enrollment on the Mobile Device

Each instance of the MobileAuthenticator that the user wants to use has to be enrolled individually. In this process, the web application's server-side and the application instance initiate a device specific trust context, represented through a shared secret. This enrollment process works as follows:

After account setup, the web application provides the user with a unique URL pointing back to the application, which carries parameters that identify the enrollment process. The user copies this URL to the MobileAuthenticator. The MobileAuthenticator displays the application's domain to ask the user for confirmation. The user confirms by entering her password which is then used by the MobileAuthenticator for authentication. If the initial authentication step terminated successfully, the MobileAuthenticator and the web application compute a shared secret using the Diffie-Hellman key exchange. This secret is not only specific for the user but also for this particular MobileAuthenticator instance. The MobileAuthenticator then discards the user password as it is no longer needed. All further app-to-server interaction uses the shared secret for authentication. As long as this secret is valid, the user will not be required to enter her password again. Finally, the web application supplies a repository of configured authorized actions, including parameters and actionID, and a human understandable description of each request's impact. The MobileAuthenticator is able to maintain several of such (shared key,repository) records and can thus protect all user accounts for compatible web applications on the device.

User Login

After the MobileAuthenticator and the web application are synchronized, the overall login procedure adheres to the following protocol: The user first accesses the web application's login page in her mobile browser. As the user is not authenticated yet, the server can not utilize user-specific credentials at this step. Instead, it issues a challenge consisting of its AppID, the login's ActionID and a timestamp (see Sec. 3.7). The challenge is signed using the web application's private key. The respective public key is stored in the MobileAuthenticator during enrollment (see Sec. 3.3). When tapping the login button, the control is delegated by the AuthenticationBroker (see Sec. 3.2) to the MobileAuthenticator. In this step, the server challenge is pushed to the MobileAuthenticator that takes over and asks the user whether she wants to login to this web application. A phishing attack would fail at this point, as the password is never entered to the mobile device for login. If the signature is valid, the MobileAuthenticator compiles the response from the server's challenge, the username, and the device ID and signs it using HMAC with the shared secret, and control is transferred back to the browser. Finally, the AuthenticationBroker sends the signed login request to the web application.

Upon receiving this request, the web server extracts the username and device ID and verifies that the request was indeed signed using the shared secret and, thus, finishes the user's login process. Username and device ID are required to pick the correct shared secret for signing and verification.

Conducting Authorized Actions

The process for conducting further authorized actions is similar to the login process (see Sec. 3.4). For the login, the MobileAuthenticator witnesses the user's consent and proves the request's integrity and its own authentication by signing the request using the shared secret. The same features are necessary for authorized actions: First, in the browser, the user taps a link or a button requesting an authorized action. The respective request is then relayed to the MobileAuthenticator that obtains the user's consent, signs, and returns the request to the browser. The AuthenticationBroker forwards the request to the web application that checks the signature and performs the requested authorized action.

Unknown Authorized Actions

During enrollment, the server pushes a list of allowed authorized actions to the MobileAuthenticator. If the web application has been updated since the enrollment of the MobileAuthenticator instance, it can happen that the MobileAuthenticator receives a request for an unknown authorized action. In this case, the MobileAuthenticator updates its local repository by a new list from the web application. This update process can also be triggered in a regular manner or based on push messages. After receiving the updated list from the web server, the MobileAuthenticator verifies that the requested authorized action is indeed contained in the list. If this is not the case, the app rejects the action request.

Challenge and Response Formats

In this section, we briefly specify the challenge/response formats. Server Challenge For a given authorized action challenge, the server compiles a tuple consisting of: CT uple = {AppID, U serID, ActionID, timestamp}. The server HMAC-signs this tuple with the user-specific shared secret to allow the MobileAuthenticator to verify the challenge's authenticity. The values in this tuple have the following meanings:

-AppID & UserID: Identifiers of the web application and the user account, to allow the MobileAuthenticator to choose the correct authentication context. -ActionID: Unambiguous identifier of the requested authorized action.

timestamp: To mitigate potential replay attacks, each challenge can be assigned a dedicated lifespan. The resulting challenge consists of the tuple and the corresponding HMAC signature: SChallenge = HM AC(CT uple, shared secret). On the server-side, the challenge is bound to the user's session and, thus, to her session identifier. Client Response After interacting with the user to capture her explicit consent, the MobileAuthenticator creates the response by assembling the response tuple: RT uple = {SChallenge, (P arameter 1 ), ..., (P arameter i )}. Again, this tuple is HMAC-signed using the shared secret: CResponse = HM AC(RT uple, shared secret). The existence and number of the parameters depends on the authorized action. For instance, the login procedure requires the username and device ID (see Sec. 3.4), while the transfer of money in a banking application will most likely include the amount and the receiving account number in the signed response value.

Implementation

To practically evaluate the feasibility of our concept, we implemented the solution for the two leading mobile operating systems, iOS and Android. Furthermore, we outfitted the popular CMS Wordpress with server-side support for our system.

Client-side Implementation

In this section, we point out the platform dependent differences between the implementations for iOS and Android respectively. Our implementation shows that the approach can be put into practice without support by platform providers though we favor an integration into the mobile platforms. Implementation for iOS On iOS, communication between apps, such as the web browser and the MobileAuthenticator is severely limited. The onlyfor our purpose -usable channel is leveraging custom URL schemes: An iOS app can register a URL scheme, such as mobileauth:, which is registered with the operating system on app installation. When a different app accesses a URL that starts with this custom URL scheme, iOS conducts a context switch and activates the application that has registered the scheme while pushing the calling app into background. The activated app receives the full URL in form of a string for further processing.

We use this mechanism to delegate the authorized action from the web browser to the Mo-bileAuthenticator: The AuthenticationBroker (see Sec. 3.2) compiles a mobileauth-URL which carries the server's challenge and the required parameters. Furthermore, the location of the active web document is attached to the URL as the callback URL. Then, the script makes the browser request the compiled mobileauth URL via assigning it to document.location. This, in turn, causes the operating system to activate the MobileAuthenticator. After user acknowledgment, the MobileAuthenticator calls the callback (http-)URL and appends the CResponse as a hash identifier. This prevents a page reload in the browser and submits the response to the AuthenticationBroker.

Implementation for Android

The MobileAuthenticator provides a background service that is started right after the boot process completed. This service hosts a WebSocket server and is therefore accessible from the device's browser using the AuthenticationBroker and the HTML5 WebSocket API. The Authen-ticationBroker establishes a WebSocket connection to the MobileAuthenticator's background service when it hooks an attempt for an authorized action. It obtains the challenge from the action's HTML meta data and pushes the request together with the challenge to the background service. The background service then launches an activity bringing the MobileAuthenticator to foreground (see Fig. 2). After the user took a decision (either consent or denial, see Fig. 3), the app computes the HMAC on the entire request, including the challenge, appends it and sends the whole string back to the AuthenticationBroker using the established WebSocket connection. We implemented server-side components to support the MobileAuthenticator and integrated them into the popular PHP weblog Wordpress as a plug-in. This allows to support legacy web applications without changing the existing codebase. There are three logical components of the plug-in: First, a client administration component manages the enrollment process for new devices, including a device confirmation in the user account, and the revocation of authorized device connections, e.g. because the device was lost or stolen (see Sec. 5). Second, an action verification component issues new challenges and checks incoming requests for valid response tokens. These two components are generic and need no adaption to the particular web application. The last component, however, is application specific. It glues the above components into the legacy code, incorporates the client administration function into the user profile pages, and activates a central request filter that checks if an incoming request targets an authorized action. If so, it forwards the request to the action verification component. The AuthenticationBroker is a JavaScript file that is included with every web page. It is roughly 10kb, is stored in the browser's LocalStorage together with a list of authorized actions, and hooks requests for those actions.

Server-side Implementation

Evaluation

We evaluate the MobileAuthenticator with respect to its security and protection properties as well as to its usability.

Security Evaluation

Phishing: An attack can only succeed if the user enters credentials on a phishing site ignoring the fact that this is not on her device. Expecting a redirect to the MobileAuthenticator, users become suspicious if their used comfort is missing.

Clickjacking: An attacker can still lure his victim into clicking on links but the target web application then redirects the victim to the MobileAuthenticator where, of course, the attack becomes obvious and the victim does not acknowledge the targeted authorized action. CSRF: An attack is only detectable for a potential victim if the attacker can forward his payload to the MobileAuthenticator (see Sec. 4). Even if the attacker manages to do so, the victim suddenly faces the MobileAuthenticator asking for permission to perform an authorized action on a different website. XSS: Injected JavaScript code can perform all actions on the user's behalf. It can raise new authorized actions and redirect the respective requests to the Mo-bileAuthenticator. However, due to the missing shared secret, it can not sign the requests. So, as long as users do not acknowledge unintended actions, no authorized action can be triggered. The only damage an XSS attacker can cause is a denial-of-service by discarding all signed requests and, thus, preventing intended authorized actions. Session fixation: The attacker can still get access to the user's account. The login step elevates the session cookie to an authorized state granting access to the owner. However, the attacker can not perform authorized actions because he has no access to the shared secret. No more password entry: Felt and Wagner discussed the fact that mobile keyboards actively discourage the usage of complicated, and thus secure, passwords, as the entry of numbers or special characters require cumbersome context switches [START_REF] Felt | Phishing on Mobile Devices[END_REF]. Our scheme obliterates the necessity of entering passwords completely. Hence, the password cannot be stolen, as it is neither stored nor entered again. Moreover, this process allows the usage of arbitrarily complicated application (master) passwords, as the usability drawbacks upon password entry do not apply for our system. Device-specific credentials: As a matter of fact, mobile devices get lost or stolen from time to time. A thief or finder can use the MobileAuthenticator to log into accounts and conduct authorized actions, once he vanquished the display lock. However, there is built-in protection against this threat: During enrollment (see Sec. 3.3), the MobileAuthenticator and the web application compute a shared secret. The MobileAuthenticator does not store the user password. So, the user only has to revoke the shared secret in her account to prevent any access using the lost device. A thief, in contrast, can not exclude the user as changing the password is not possible without knowing the old password.

Attacking the MobileAuthenticator

We briefly discuss attacks that might apply directly to our implemented mechanism. The proposed solution as a system app is not susceptible to these attacks. App Spoofing An attacker may offer a malicious app via the respective platform's market, i.e., Apple's App Store or Google Play. When installed on a user's device, it could try to obtain user credentials pretending to be the legitimate Mo-bileAuthenticator. The only occasion is the registration of new accounts in the MobileAuthenticator. This, however, is initialized by the user, usually by shortcuts on her home screen. So, as long as this malicious app is not able to replace the legitimate app shortcut with its own, the attacker can not gain confidential knowledge. We want to emphasize that spoofing the legitimate app when the AuthenticationBroker forwards them for signing does not reveal any credentials to the malicious app, because the user only confirms or denies but does not enter anything. The implementation as a system app can register an exclusive protocol scheme such that the registration URL is instantly forwarded to the MobileAuthenticator. Task Interception There is a task interception attack on Android devices. A malicious app having the necessary permissions (given by the user at installation time) can poll running tasks and display a phishing screen as soon as the target app is started. The user, expecting this screen, would probably enter the credentials. Finally, the malicious app can exit and call the genuine app. This kind of attack is not promising when run on the MobileAuthenticator because the background service is permanently running, thus, revealing no indication for the moment to spoof the MobileAuthenticator screen.

Usability

Felt et al. phrase crucial criteria for user-friendly interaction with respect to questions and user-based decisions [START_REF] Felt | How to Ask for Permission[END_REF]. We generalize and apply their criteria though they study mobile apps and their questions for permissions. In fact, the MobileAuthenticator is similar because it needs a user's decision on the permission to perform an authorized action. We show that the MobileAuthenticator complies with their criteria.

Their first point is to conserve user attention and only ask if the respective question has severe consequences. The MobileAuthenticator only comes into play when such confirmation is necessary. This way, we limit user interaction to the absolute minimum while, in the end, the web application determines the actual authorized actions (see Sec. 2.3).

Second, a usable security mechanism avoids interrupting the user's primary task with explicit security decisions. We achieve this by integrating the user question into the usual workflow. For instance, the MobileAuthenticator can ask the user for consent while presenting an overview of the purchase, including payment information, goods, shipping, etc. The user expects such a final inquiry. So, the integration of the MobileAuthenticator does not interrupt the user's primary task.

Finally, Felt et al. recommend using a trusted UI for non-revertible, severe, and user initiated actions. The authorized actions are generally not revertible, which means that the MobileAuthenticator can not let them happen and revert if needed. They are severe, meaning that carelessness is not an option and drawing the user's attention is justified. Finally, authorized actions are generally user initiated. This is an important point why one can expect the user to confirm her intent. Other, i.e., implicit, actions can not be confirmed that easily because the user does not know what to decide and why that dialogue popped up.

For instance, a usual shopping workflow and an online banking transaction only require one acknowledgment using the MobileAuthenticator respectively. This acknowledgment can be smoothly embedded in the workflow as a last step being expected by the user anyway. Social networks need to assess their users' risk: publicly posted messages on the one hand are deletable (i.e., revertible), so there is no need for a trusted UI. On the other hand, however, annoying or insulting posts might damage the victim's reputation which is non-revertible and severe. This decision could also be left to each customer weighing her personal or business interests respectively. As a rule of thumb, an acknowledgment step using the MobileAuthenticator is at least necessary when a re-authentication (providing the password again) or second factor authentication (e.g., via Google Authenticator, one-time passcodes, flicker codes) has been in place.

Related work

There is no other approach covering the whole range of authentication-based attacks. Existing approaches either protect the login process against phishing [START_REF] Chou | Client-side Defense against Web-Based Identity Theft[END_REF][START_REF] Dhamija | The Battle Against Phishing: Dynamic Security Skins[END_REF][START_REF] Balfanz | TLS Origin-Bound Certificates[END_REF] or target session-based attacks [START_REF] Ryck | CsFire: Transparent Client-Side Mitigation of Malicious Cross-Domain Requests[END_REF][START_REF] Huang | Clickjacking: Attacks and Defenses[END_REF][START_REF] Jovanovic | Preventing cross site request forgery attacks[END_REF][START_REF] Sterne | Content Security Policy. W3C Working Draft[END_REF][START_REF] Johns | Reliable Protection Against Session Fixation Attacks[END_REF] Finally, the related body of work includes authentication and authorization protocols in the web [16][START_REF] Lockhart | SAML V2.0[END_REF][18]. GuarDroid [START_REF] Tong | GuarDroid: A Trusted Path for Password Entry[END_REF] aims at establishing a trusted path between the user and the web application using a modified execution platform (firmware). It protects against malicious apps installed on the mobile device and prevents leakage of the user's password. GuarDroid does not require changes of the installed apps nor of the remote web application, however, it can not protect against session-based attacks which still allow a malicious app to impersonate the user towards the web application. GuarDroid causes considerable network latency and requires the user to set, remember, and check a secure passphrase that authenticates the secure login form and delays the system boot process. Finally, the user is responsible to verify the target URL for login requests to prevent phishing attacks, thus, demanding a high level of awareness and increasing the risk that users just click through the dialog. Other existing approaches for trusted paths concerning user login [START_REF] Bursztein | SessionJuggler: Secure Web Login from an Untrusted Terminal Using Session Hijacking[END_REF] and user actions in authenticated sessions [START_REF] Braun | A User-Level Authentication Scheme to Mitigate Web Session-Based Vulnerabilities[END_REF] focus on surfing web applications using desktop browsers.

Conclusion

In this paper, we presented a web authorization delegation scheme for mobile devices that utilizes a native companion app, the MobileAuthenticator, to realize a trusted UI. For a set of predefined authorized actions, our system reliably mitigates state changing effects of currently known user impersonation attacks, such as phishing, CSRF, or clickjacking.

Furthermore, the MobileAuthenticator effectively becomes the user's authentication credential, obliterating the necessity to frequently enter passwords on the mobile device, thus, correcting the usability drawbacks that are observed when entering secure passwords on mobile keyboards.

The MobileAuthenticator itself is independent from specific characteristics of the protected web application and, thus, can serve as the central trust anchor for many different, independent applications. In consequence, a future integration of such a service on a platform-level into the mobile operating system is a compelling option.

Fig. 1 .

 1 Fig. 1. Solution Overview

Fig. 2 .

 2 Fig. 2. Triggering an authorized action

Fig. 3 .

 3 Fig. 3. Obtaining user consent to perform an authorized action

The Android platform offered limited support for Flash on a subset of existing devices. Adobe discontinued support by Aug 15, 2012. See http://adobe.ly/1a1EpPH.

[START_REF] Rydstedt | Framing Attacks on Smart Phones and Dumb Routers: Tap-jacking and Geo-localization Attacks[END_REF] See http://mzl.la/1fwQNoX and http://bit.ly/1k7NQOE for details.