Application permissions: Difference between revisions
m →Mobile devices: lower case t |
→Analysis: Added more material for a critical analysis of the weaknesses of the permission approach, including references for three areas where the permission approach has been found suboptimal. |
||
| Line 56: | Line 56: | ||
== Analysis == |
== Analysis == |
||
The permission-based access control model assigns access privileges for certain data objects to apps. This is a derivate of the discretionary access control model. The access permissions are usually granted in the context of a specific user on a specific device. Permissions are granted permanently with few automatic restrictions. |
|||
In some cases permissions are implemented in 'all-or-nothing' approach: a user either has to grant all the requested permissions to an app, or be unable to use the app. Even if a user can revoke a permission, the app can [[blackmail]] a user by refusing to operate, for example just [[Crash (computing)|crash]]ing. There are some solutions, such as [[XPrivacy]], which instead of providing access to the requested data instead of throwing an exception and crashing an app returning [[disinformation]] to make an app operate as if the permission was granted. It is also possible to use static analysis to analyze the requested permissions.<ref name="BartelKlein2012">{{cite journal|last1=Bartel|first1=Alexandre|last2=Klein|first2=Jacques|last3=Le Traon|first3=Yves|last4=Monperrus|first4=Martin|title=Automatically securing permission-based software by reducing the attack surface: an application to Android|year=2012|url=https://hal.archives-ouvertes.fr/hal-00726196/document|doi=10.1145/2351676.2351722|arxiv=1206.5829}}</ref> |
|||
In some cases permissions are implemented in 'all-or-nothing' approach: a user either has to grant all the requested permissions to an app, or be unable to use the app. It remains intransparent to the user when the permission is used by a program or app to access the data protected by the permission access control mechanism. Even if a user can revoke a permission, the app can [[blackmail]] a user by refusing to operate, for example by just [[Crash (computing)|crash]]ing. |
|||
The permission mechanism has been widely critisized by researchers. Critique is voiced along three themes: |
|||
* Intransparency of personal data extraction and surveillance, including the creation of a false sense of security<ref>Moen, Gro Mette, Ailo Krogh Ravna, and Finn Myrstad: Deceived by Design - How tech companies use dark patterns to discourage us from exercising our rights to privacy., 2018, Consumer concil of Norway / Forbrukerrådet. Report. https://www.forbrukerradet.no/undersokelse/no-undersokelsekategori/deceived-by-design</ref><ref>{{Cite journal|last=Fritsch|first=Lothar|last2=Momen|first2=Nurul|date=2017|title=Derived Partial Identities Generated from App Permissions|url=http://urn.kb.se/resolve?urn=urn:nbn:se:kau:diva-63724|publisher=Gesellschaft für Informatik|pages=117–130}}</ref>; |
|||
* End-user fatigue of micro-managing access permissions leading to a fatalistic acceptance of surveillance and intransparency<ref>{{Cite journal|last=Kelley|first=Patrick Gage|last2=Consolvo|first2=Sunny|last3=Cranor|first3=Lorrie Faith|last4=Jung|first4=Jaeyeon|last5=Sadeh|first5=Norman|last6=Wetherall|first6=David|date=2012|editor-last=Blyth|editor-first=Jim|editor2-last=Dietrich|editor2-first=Sven|editor3-last=Camp|editor3-first=L. Jean|title=A Conundrum of Permissions: Installing Applications on an Android Smartphone|url=https://link.springer.com/chapter/10.1007%2F978-3-642-34638-5_6|journal=Financial Cryptography and Data Security|series=Lecture Notes in Computer Science|language=en|publisher=Springer Berlin Heidelberg|pages=68–79|doi=10.1007/978-3-642-34638-5_6|isbn=978-3-642-34638-5}}</ref>; |
|||
* Massive data extraction and personal surveillance carried out once the permissions are granted<ref>{{Cite journal|last=Momen|first=N.|last2=Hatamian|first2=M.|last3=Fritsch|first3=L.|date=2019-11|title=Did App Privacy Improve After the GDPR?|url=https://ieeexplore.ieee.org/document/8845749/|journal=IEEE Security Privacy|volume=17|issue=6|pages=10–20|doi=10.1109/MSEC.2019.2938445|issn=1558-4046}}</ref>. |
|||
There are some solutions, such as [[XPrivacy]], which instead of providing access to the requested data instead of throwing an exception and crashing an app returning [[disinformation]] to make an app operate as if the permission was granted. Mockdroid<ref>{{Cite journal|last=Beresford|first=Alastair R.|last2=Rice|first2=Andrew|last3=Skehin|first3=Nicholas|last4=Sohan|first4=Ripduman|date=2011|title=MockDroid|url=https://doi.org/10.1145/2184489.2184500|journal=Proceedings of the 12th Workshop on Mobile Computing Systems and Applications - HotMobile '11|location=New York, New York, USA|publisher=ACM Press|doi=10.1145/2184489.2184500|isbn=978-1-4503-0649-2}}</ref> is another instance of this approach. It is also possible to use static analysis to analyze the requested permissions.<ref name="BartelKlein2012">{{cite journal|last1=Bartel|first1=Alexandre|last2=Klein|first2=Jacques|last3=Le Traon|first3=Yves|last4=Monperrus|first4=Martin|title=Automatically securing permission-based software by reducing the attack surface: an application to Android|year=2012|url=https://hal.archives-ouvertes.fr/hal-00726196/document|doi=10.1145/2351676.2351722|arxiv=1206.5829}}</ref> Further transparency methods include longitudinal behavioural profiling and multiple-source privacy analysis of app data access<ref>{{Cite journal|last=Momen|first=Nurul|date=2018|title=Towards Measuring Apps' Privacy-Friendliness|url=http://urn.kb.se/resolve?urn=urn:nbn:se:kau:diva-68569}}</ref><ref>{{Cite journal|last=Hatamian|first=Majid|last2=Momen|first2=Nurul|last3=Fritsch|first3=Lothar|last4=Rannenberg|first4=Kai|date=2019|editor-last=Naldi|editor-first=Maurizio|editor2-last=Italiano|editor2-first=Giuseppe F.|editor3-last=Rannenberg|editor3-first=Kai|editor4-last=Medina|editor4-first=Manel|editor5-last=Bourka|editor5-first=Athena|title=A Multilateral Privacy Impact Analysis Method for Android Apps|url=https://link.springer.com/chapter/10.1007%2F978-3-030-21752-5_7|journal=Privacy Technologies and Policy|series=Lecture Notes in Computer Science|language=en|publisher=Springer International Publishing|pages=87–106|doi=10.1007/978-3-030-21752-5_7|isbn=978-3-030-21752-5}}</ref> . |
|||
== References == |
== References == |
||
Revision as of 12:51, 28 November 2019
Application permissions are a widespread coarse-grained way to limit applications' access to sensitive information, for example sound recorded by microphone, and valuable resources, like the battery, internet traffic and account balance. They are implemented in major state of the art PDA[clarification needed] operation systems (Android, iOS, Windows), web browsers and web services providing an OAuth API.
Mobile devices
The list of available permissions usually contains accessing.:[1][2]
- geolocation
- GNSS (GPS, GLONASS, QZSS)[clarification needed]
- system providers, using trilateration to nearby wireless networks, though it is possible to implement providers utilising other sensors, like microphone, accelerometer, gyroscope and barometer and an online DB of ambient measurements
- sensors and their identifiers and characteristics
- camera
- microphone
- biometric sensors used for identification and authentication, like fingerprint sensor
- biometric sensors used for medical and fitness purposes, like heart rate sensor
- unfortunately, other sensors, such as gyroscope, accelerometer, barometer, temperature, light, proximity, voltmeter, ampermeter are usually not behind permissions, even though they pose major privacy and security risks.[3][4][5][6][7][8] This can be partially fixed with additional software, like XPrivacy.
- internet access
- wired and wireless interfaces access, including their hardware identifiers and signal strength where applicable
- making and receiving phone calls
- sending and reading SMS
- account to make in-app purchases
- showing own GUI elements over other apps' GUI
- installing, deleting and otherwise managing applications
- changing device settings, including ...
- enabling and disabling wireless interfaces
- accessing storage
- authentication tokens (i.e. OAuth ones) of web services stored in system storage for sharing them between apps
- accessing dedicated interfaces registered by other apps, like
- contacts
- calendars, events and appointments
- superuser access on rooted devices (not quite a permission since it is used only for showing in GUI that the app uses root, lot of apps using su don't have this permission)
- push-services interfaces
On Android <6 permissions are not usually revokable, though there is AppOps mechanism in some OSes (it's usually present in vanilla Android and aftermarket OSes, but usually removed in stock OSes) allowing to deprive apps access to some personal data. In Android ≥6 apps can request permissions in run time, but this requires app developer collaboration (developer is free to use non-runtime permissions only and the app will likely crash if permission is not granted and the ones not granting the permission is not a target audience of an app) [9] and some permissions marked as permissions in previous versions of the OS, like internet access, are non-revocable and are not even show on apps installation. This can be fixed with XPrivacy.
On iOS usage of permissions is regulated using the guidelines.[10]
In Android ecosystem usage of permissions is often abused in order to spy on users, many applications require as much permissions as they can and monetize by integrating libraries by advertising networks, showing ads and spying on users to better target them.
WebPermissions
WebPermissions is a permission system for web browsers.[11] When a web application needs some data behind a permission, it must request it first. When it does it, a user sees a window asking him to make a choice. The choice is remembered, but can be cleared lately.
Currently the following resources are controlled:
- geolocation[12]
- desktop notifications[13]
- service workers[14][15]
- sensors
- audio capturing devices,[16] like soundcards, and their model names and characteristics
- video capturing devices,[16] like cameras, and their identifiers and characteristics
Analysis
The permission-based access control model assigns access privileges for certain data objects to apps. This is a derivate of the discretionary access control model. The access permissions are usually granted in the context of a specific user on a specific device. Permissions are granted permanently with few automatic restrictions.
In some cases permissions are implemented in 'all-or-nothing' approach: a user either has to grant all the requested permissions to an app, or be unable to use the app. It remains intransparent to the user when the permission is used by a program or app to access the data protected by the permission access control mechanism. Even if a user can revoke a permission, the app can blackmail a user by refusing to operate, for example by just crashing.
The permission mechanism has been widely critisized by researchers. Critique is voiced along three themes:
- Intransparency of personal data extraction and surveillance, including the creation of a false sense of security[17][18];
- End-user fatigue of micro-managing access permissions leading to a fatalistic acceptance of surveillance and intransparency[19];
- Massive data extraction and personal surveillance carried out once the permissions are granted[20].
There are some solutions, such as XPrivacy, which instead of providing access to the requested data instead of throwing an exception and crashing an app returning disinformation to make an app operate as if the permission was granted. Mockdroid[21] is another instance of this approach. It is also possible to use static analysis to analyze the requested permissions.[22] Further transparency methods include longitudinal behavioural profiling and multiple-source privacy analysis of app data access[23][24] .
References
- ^ "Manifest.permission - Android Developers". developer.android.com.
- ^ "iOS Security Guide" (PDF).
- ^ Michalevsky, Yan; Boneh, Dan; Nakibly, Gabi (2014). "Gyrophone: Recognizing Speech from Gyroscope Signals" (PDF). USENIX Security Symposium. 23: 1053–1067. ISBN 978-1-931971-15-7.
- ^ https://cse.sc.edu/~wyxu/719Spring12/papers/US-vibr-Phone.pdf
- ^ Michalevsky, Yan; Nakibly, Gabi; Schulman, Aaron; Veerapandian, Gunaa Arumugam; Boneh, Dan (2015-02-10). "PowerSpy: Location Tracking using Mobile Device Power Analysis". arXiv:1502.03182 [cs.CR].
- ^ Mosenia, Arsalan; Dai, Xiaoliang; Mittal, Prateek; Jha, Niraj (2017). "PinMe: Tracking a Smartphone User around the World". IEEE Transactions on Multi-Scale Computing Systems: 1. arXiv:1802.01468. doi:10.1109/TMSCS.2017.2751462. ISSN 2332-7766.
- ^ Hua, Jingyu; Shen, Zhenyu; Zhong, Sheng (2015-05-22). "We Can Track You If You Take the Metro: Tracking Metro Riders Using Accelerometers on Smartphones". arXiv:1505.05958 [cs.CR].
- ^ Guri, Mordechai; Daidakulov, Andrey; Elovici, Yuval (2018-02-07). "MAGNETO: Covert Channel between Air-Gapped Systems and Nearby Smartphones via CPU-Generated Magnetic Fields". arXiv:1802.02317 [cs.CR].
- ^ "Runtime Permissions - Android Open Source Project". Android Open Source Project.
- ^ Inc., Apple. "Requesting Permission - App Architecture - iOS Human Interface Guidelines". developer.apple.com.
{{cite web}}:|last=has generic name (help) - ^ "Permissions". w3c.github.io. Retrieved 2019-05-10.
- ^ "Geolocation API Specification 2nd Edition". www.w3.org.
- ^ "Notifications API Standard". notifications.spec.whatwg.org.
- ^ "Push API". www.w3.org.
- ^ "Web Background Synchronization". wicg.github.io.
- ^ a b "Media Capture and Streams". w3c.github.io.
- ^ Moen, Gro Mette, Ailo Krogh Ravna, and Finn Myrstad: Deceived by Design - How tech companies use dark patterns to discourage us from exercising our rights to privacy., 2018, Consumer concil of Norway / Forbrukerrådet. Report. https://www.forbrukerradet.no/undersokelse/no-undersokelsekategori/deceived-by-design
- ^ Fritsch, Lothar; Momen, Nurul (2017). "Derived Partial Identities Generated from App Permissions". Gesellschaft für Informatik: 117–130.
{{cite journal}}: Cite journal requires|journal=(help) - ^ Kelley, Patrick Gage; Consolvo, Sunny; Cranor, Lorrie Faith; Jung, Jaeyeon; Sadeh, Norman; Wetherall, David (2012). Blyth, Jim; Dietrich, Sven; Camp, L. Jean (eds.). "A Conundrum of Permissions: Installing Applications on an Android Smartphone". Financial Cryptography and Data Security. Lecture Notes in Computer Science. Springer Berlin Heidelberg: 68–79. doi:10.1007/978-3-642-34638-5_6. ISBN 978-3-642-34638-5.
- ^ Momen, N.; Hatamian, M.; Fritsch, L. (2019-11). "Did App Privacy Improve After the GDPR?". IEEE Security Privacy. 17 (6): 10–20. doi:10.1109/MSEC.2019.2938445. ISSN 1558-4046.
{{cite journal}}: Check date values in:|date=(help) - ^ Beresford, Alastair R.; Rice, Andrew; Skehin, Nicholas; Sohan, Ripduman (2011). "MockDroid". Proceedings of the 12th Workshop on Mobile Computing Systems and Applications - HotMobile '11. New York, New York, USA: ACM Press. doi:10.1145/2184489.2184500. ISBN 978-1-4503-0649-2.
- ^ Bartel, Alexandre; Klein, Jacques; Le Traon, Yves; Monperrus, Martin (2012). "Automatically securing permission-based software by reducing the attack surface: an application to Android". arXiv:1206.5829. doi:10.1145/2351676.2351722.
{{cite journal}}: Cite journal requires|journal=(help) - ^ Momen, Nurul (2018). "Towards Measuring Apps' Privacy-Friendliness".
{{cite journal}}: Cite journal requires|journal=(help) - ^ Hatamian, Majid; Momen, Nurul; Fritsch, Lothar; Rannenberg, Kai (2019). Naldi, Maurizio; Italiano, Giuseppe F.; Rannenberg, Kai; Medina, Manel; Bourka, Athena (eds.). "A Multilateral Privacy Impact Analysis Method for Android Apps". Privacy Technologies and Policy. Lecture Notes in Computer Science. Springer International Publishing: 87–106. doi:10.1007/978-3-030-21752-5_7. ISBN 978-3-030-21752-5.