Modern smartphones and tablets are equipped with a plethora of sensors that enable a wide range of interactions. However, some of these sensors can be used by malicious apps to surreptitiously learn about user location, mobility, and even keyboard input. BlurSense allows fine-grained, richer sets of privacy control. For a particular sensor, a BlurSense filter might perform an action such as blurring the resolution of photos and video taken by the camera, removing access point information from WiFi scans, or omitting the motion sensor data completely.

BlurSense Overview

While sensors on smartphones are a powerful tool for researchers, such as our Seattle Sensors project, they also pose a risk to users. A study showed that unscrupulous hackers typically find personal information stored on devices inviting [1]. There has been alarming news about privacy breaches of personal data on smart devices: 26% of Android apps in Google Play can access user’s personal data (link); an iOS app auto-posts false piracy accusations on users’ Twitter accounts (link); and a huge botnet that is collecting sensor data was discovered on more than a million end user smartphones (link). The Federal Trade Commission (FTC) recently recommended that mobile platforms should provide in-time disclosures to users of accessing sensitive content on smart devices (link). However, the current privacy mechanisms are rather limited, and most privacy controls are one-size-fits-all: the user either opts-in or cannot use the site or application.

Why BlurSense

Today’s smartphone OSes typically expose resources in a global way. For example, apps in Android use install-time manifests to request access to resources; once granted, the installed app has permanent access to the requested resources. Such permissions are often much more than necessary, and can open a door for malicious apps to surreptitiously learn about the user and their behavior. For example, Touchlogger [3] and Taplogger [2] employ gyroscopic orientation sensor to determine where a user touches on a large keypad, and infer PIN-like input based on phone key pad; TapPrints [4] which uses a combination of gyroscopic and accelerometer data to infer tap events and location of tap events on tablet and smartphone keyboards; (sp)iphone [5] can collect accelerometer readings while the smartphone is placed next to a keyboard; Soundcomber [6] demonstrated that a malicious app that has access to the microphone can learn the difference between general chatter and tone dialling, effectively learning the numbers a user calls; Xu et al. in [7] considered information that can be leaked if a malicious app has access to the smartphone’s camera, and Cai et al. investigate sniffing sensors including the microphone, camera, and GPS receiver [8].

Several related work has been proposed to refine or reduce permissions on mobile platforms [9-10]. CRePE [9] also allows privacy control by third parties. However, these prior work were implemented via modifying the device platform. BlurSense enables untrusted parties to add privacy filters from user space. From a technical standpoint, BlurSense provides a sensor interposition mechanism and a sandboxing mechanism that make it easy to implement privacy filters. A user can let a third party have access to their sensor data from within a security and performance isolated container [11]. By leveraging this security, the user provides minimal trust in the third party, but allows them an easy way to code their filters. This functionality also automatically handles multiple privacy filters from different parties through the sandbox policy composition functionality [11]. Security and privacy groups can easily build and disseminate their own privacy filters they recommend to users by adding them to BlurSense app store. Therefore, multiple security vendors can efficiently and effectively collaborate to strengthen user privacy.



[1] D. Mulligan and A. Schwartz. Your place or mine?: privacy concerns and solutions for server and client-side storage of personal information. In Proceedings of the tenth conference on Computers, freedom and privacy: challenging the assumptions, pages 81–84. ACM, 2000.

[2] Z. Xu, K. Bai, and S. Zhu. Taplogger: inferring user inputs on smartphone touchscreens using on-board motion sensors. In Proceedings of the fifth ACM conference on Security and Privacy in Wireless and Mobile Networks, pages 113–124. ACM, 2012.

[3] L. Cai and H. Chen. Touchlogger: inferring keystrokes on touch screen from smartphone motion. In Proceedings of the 6th USENIX conference on Hot topics in security, HotSec'11, 2011.

[4] E. Miluzzo, A. Varshavsky, S. Balakrishnan, and R. Choudhury. Tapprints: your finger taps have fingerprints. In Proceedings of the 10th international conference on Mobile systems, applications, and services, MobiSys’12, 2012.

[5] P. Marquardt, A. Verma, H. Carter, and P. Traynor. (sp)iphone: decoding vibrations from nearby keyboards using mobile phone accelerometers. In Proceedings of the 18th ACM conference on Computer and communications security, CCS ’11, 2011.

[6] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X. Wang. Soundcomber: A stealthy and context-aware sound trojan for smartphones. In Proceedings of the Network and Distributed System Security Symposium, NDSS, 2011.

[7] N. Xu, F. Zhang, Y. Luo, W. Jia, D. Xuan, and J. Teng. Stealthy video capturer: a new video-based spyware in 3g smartphones. In Proceedings of the second ACM conference on Wireless network security, WiSec ’09, 2009.

[8] L. Cai, S. Machiraju, and H. Chen. Defending against sensor-sniffing attacks on mobile phones. In Proceedings of the 1st ACM workshop on Networking, systems, and applications for mobile handhelds, MobiHeld ’09, 2009.

[9] M. Conti, V. Nguyen, and B. Crispo. Crepe: Context-related policy enforcement for android. Information Security, pages 331–345, 2011.

[10] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wetherall. These aren’t the droids you’re looking for: retrofitting android to protect data from imperious applications. In Proceedings of the 18th ACM conference on Computer and communications security, pages 639–652. ACM, 2011.

[11] J. Cappos, A. Dadgar, J. Rasley, J. Samuel, I. Beschastnikh, C. Barsan, A. Krishnamurthy, and T. Anderson. Retaining sandbox containment despite bugs in privileged memory-safe code. In Proceedings of the 17th ACM conference on Computer and communications security, CCS ’10, pages 212–223, New York, NY, USA, 2010. ACM.

Last modified 5 years ago Last modified on Feb 10, 2014 3:11:51 PM