Sovereign Smartphone: To Enjoy Freedom We Have to Control Our Phones
Friederike Groschupp, Moritz Schneider, Ivan Puddu, Shweta Shinde, Srdjan Capkun
SSovereign Smartphone:To Enjoy Freedom We Have to Control Our Phones
Friederike Groschupp Moritz Schneider Ivan Puddu Shweta Shinde Srdjan Capkun
ETH Zurich
Abstract
The majority of smartphones either run iOS or Androidoperating systems. This has created two distinct ecosys-tems largely controlled by Apple and Google—they dic-tate which applications can run, how they run, and whatkind of phone resources they can access. Barring some ex-ceptions in Android where different phone manufacturersmay have influence, users, developers, and governmentsare left with little to no choice. Specifically, users need toentrust their security and privacy to OS vendors and ac-cept the functionality constraints they impose. Given thewide use of Android and iOS, immediately leaving theseecosystems is not practical, except in niche applicationareas. In this work, we draw attention to the magnitude ofthis problem and why it is an undesirable situation. As analternative, we advocate the development of a new smart-phone architecture that securely transfers the control backto the users while maintaining compatibility with the richexisting smartphone ecosystems. We propose and analyzeone such design based on advances in trusted executionenvironments for ARM and RISC-V.
Smartphones are the centerpiece of most people’s digitallife. However, they do not offer the same flexibility asPCs, where users can install and run arbitrary software.Smartphone manufacturers and vendors of major operat-ing systems such as iOS and Android restrict which appscan be run on smartphones, type of peripheral access, anddata access. While Android allows side-loading, users arestill limited in the way they can run apps and the kindof access they have. There are several examples where,in order to protect the users from developers, Apple and In the following, Android refers to the Google-controlled variant.While there is the Android Open Source Project (AOSP), it does notcome with core features such as Google Mobile Services, which areclosed-source and proprietary to Google [10, 25]
Google limit apps’ access to peripherals and data even ifthe users would allow such access [27, 38].Smartphone manufacturers and OS vendors can usesuch control to optimize performance, provide a gooduser experience, and protect users from malicious apps.At the same time, these companies become arbiters andgatekeepers. Recent examples show that this is not a mi-nor issue. In the case of contact tracing apps, Apple (andto some extent Google) restricted access that governmentapps can have to Bluetooth beacons, citing privacy andperformance concerns. This restricted the design spaceand performance of contact tracing apps in several coun-tries [38, 44, 45]. After recent developments in the US, theParler app has been removed from Apple and Google appstores [22] and Google banned the app of a traditionalDanish children’s program after the company deemedits content unsuitable [37]. Apple and Google policiesrequired in-app purchases to use in-store payments, result-ing in these companies being accused of gatekeeping inseveral jurisdictions [46]. Users, developers, and govern-ments have therefore faced restrictions under the currentmodel. Most notably, users are unable to freely use theirsmartphones—they are subject to several limitations thatthey do not face on their PCs.This is clearly an undesirable situation. Even if thecurrent OSs offer some leeway, like side-loading, they canand have taken it away from users and developers [49].Few companies should not be in a position to have suchcontrol. As much as possible, control over the devicesshould be handed back to the users who own the phonesand whose data the phones primarily hold.This is a complex technical, legal, and societal issuethat cannot be resolved by technical means alone [19, 21].However, new smartphone designs can be a part of thesolution to this problem. Ideally, a sovereign smartphone will give the user full control of the software, hardware(e.g., peripherals), and data on the phone. One obvioussolution is to replicate the PC model for smartphones.Projects that allow this already exist [35, 36]. However,1 a r X i v : . [ c s . CR ] F e b hey require the users to switch to other app stores. Moreimportantly, they cannot easily replicate the functionalityand protections that existing OSs offer. Virtualization-based solutions [2, 11] would hand the control to the hy-pervisors. However, such privileged software can inspectand modify the OS and app memory, therefore, removingcontrol from the users and preventing OS vendor fromprotecting their ecosystems. Furthermore, removing con-trol from the OS vendor only to hand it to the smartphonemanufacturers, which would typically control such hyper-visors, would not solve the underlying issues.We propose a new design that demonstrates the feasibil-ity of building a sovereign smartphone . We give controlback to the users, without taking away the functionalityand security from the existing operating system vendorsand smartphone manufacturers. Such design allows com-panies to offer comprehensive protection to the users andsoftware on the platform without restricting the users’ability to run software and access platform resources. Thesovereign smartphone offers flexibility in the deploymentof new apps and functionalities and aligns the interests ofusers, phone manufacturers, cellular network operators,and even OS vendors.Our design builds on the recent advances in trustedexecution environments (TEEs). We discuss how it canbe implemented on top of ARM and RISC-V TEE archi-tectures. We outline several critical technical challengesin realizing sovereign smartphones. Restricted resource access.
Bluetooth-based contacttracing apps periodically receive and process BluetoothLow Energy (BLE) beacons to measure the distance toother smartphones and register contact. Due to concernsabout privacy and power consumption, iOS and Androiddid not permit apps running in the background to freelybroadcast and receive BLE beacons, effectively disal-lowing BLE-based approaches preferred by some coun-tries [38, 44, 45]. Instead, the introduction of such con-tract tracing apps almost entirely depended on Apple andGoogle implementing and providing an API for a particu-lar decentralized contact tracing approach [5, 38]. Clearly,these companies can always disable this API.
Censored app availability.
App store providers con-trol which apps are offered on their app stores. They mayreject or remove apps based on company policies [4, 24],public pressure, or executive authority. There have beenseveral notable instances of apps being removed fromofficial Apple and Google app stores. Examples includethe ad-blocker Adblock Fast [47], the game Fortnite overa feud on payment restrictions [48], the right-wing app Parler after civil unrests in the US [17, 22], and theHKmap Live app used by protesters during the HongKong protests [12]. If an app is not available throughthe official app stores, iOS users cannot easily install it. On Android, developers may circumvent this restrictionby offering their app as a side-loaded package. Even iftechnically users can side-load apps, iOS and Androidcan easily take this privilege away, either by selectivelyblocking apps or preventing any side-loading [49]. Fur-thermore, it might be technically feasible that OS vendorsare legally compelled to disclose if banned apps are run-ning on a user’s phone [6].
Forced Ecosystem.
When an app is distributedthrough the official app stores, all payment transactions,even in-app purchases, must be processed through the re-spective billing service offered by Apple and Google [46].This forces developers to use a specific payment API andsubdues them to any fees imposed, as they cannot easilyavoid offering their apps on these app stores [16, 28].
Data privacy concerns.
Users face uncertainty aboutwhen and what kind of data is collected by their phone,for example through the phone sensors, and how it is pro-cessed [14]. While the OS allows the user to manage pe-ripheral permissions for apps or to disable access to someresources globally, e.g., by turning off GPS or Bluetooth,they have to trust the OS. Intentional or unintentional mis-use of such OS-level privileges or opaque policies canput the user data in danger without the user’s knowledge.For example, Google gathered location information evenwhen the location history feature was turned off [3, 42].
OS vendors invest large amounts of effort, money, andthought in developing a phone OS. By acting as a centralauthority in their ecosystems, they simplify managementand engineering tasks. For instance, they can quickly reactto zero-day vulnerabilities or new classes of attacks [26,33]. They can avoid fragmentation of their ecosystembecause they provide a unified system, consistent APIs,and central app stores.Apple and Google aim to protect their users’ securityand privacy against third parties. Specifically, they vetapps and weed out potential malware before releasingthem on the official store. To enhance security, the OSsrestrict user permissions, enforce strict inter-app isolation,and suppress direct access to certain peripherals. Further,they provide useful security services, e.g., protection fordigital copyright content, Google SafetyNet, secure OSboot, OS tamper detection, and app-specific data protec-tion. In summary, a tightly controlled system preserves On iOS, custom apps can be installed with a special developeraccount and the app’s source code through XCode.
Rooting/Jailbreaking.
Users can gain root permis-sions on their phones by bypassing security mechanismsor exploiting vulnerabilities. They can run privileged appsand circumvent hardware manufacturer or OS vendor re-strictions. However, this approach is not user-friendly,might brick the phone, and voids device warranty [7, 43].
Unlocking the bootloader.
Users can unlock the boot-loader on some Android phones and install a differentOS. In theory, the user then has full control over the OSfunctionality, drivers, and the apps they want to install.However, alternative OSs lack compatibility with com-mon apps and key proprietary functionality [10]. In addi-tion, even though unlocking the bootloader is supported bysome hardware vendors, it still voids the warranty in manycases and irreversibly prevents particular apps from run-ning, such as Samsung’s security framework Knox [40].
Side-loading.
Android allows side-loading, i.e., the in-stallation of code distributed by other means than theofficial app store [39]. However, the user depends on OSvendor support for this feature, which can be potentiallydiscontinued [49]. Furthermore, this approach does notallow unrestricted access to resources. For example, side-loading a contact tracing app would not have resolved thelack of functionality at the OS level.
Reducing OS vendors’ control in the phone market neces-sitates shifting it to other entities, i.e., users, governments,or independent oversight committees. We argue that theusers, as device owners and as those whose information isprimarily processed on the devices, should be in controlof their data and able to freely use their devices withoutOS vendor restrictions.Giving users full control over their phone has sometrade-offs. First, it would simplify illegal activities onphones which could not be prevented by authorities. How-ever, criminals already have ways of circumventing theselimitations, such as using PCs or open stack devices. Lawenforcement has other ways of control, e.g., through ISPs.Second, an average phone user may not have the techni-cal expertise or necessity to configure a sovereign phone.Such a user can use configurations offered by a trustedparty (e.g., independent committees). Alternatively, theycan continue using an existing OS as is, if the sovereignphone platform is compatible with current OSs. While thisessentially delegates the control from the user to anotherentity, the choice is still up to the user.
We envision that a sovereign smartphone should maintaincompatibility with current OSs such as iOS and Android,referred to as legacy operating system (LOS) in the follow-ing. Users can continue to execute existing apps, whichare hereafter referred to as legacy apps . We introduce thenotion of sovereign app (sapp), an app that runs outsidethe LOS. A user can run a sapp when (i) it is not availablein the LOS app store and side-loading might pose a secu-rity risk to the LOS; (ii) they do not trust the LOS; or (iii)the sapp needs access to resources prohibited by the LOS. (P1) Full user control.
The user can assign certainshares of compute time to LOS and sapps. The user candeny or grant exclusive peripheral access to LOS or sapps. (P2) LOS protection.
The LOS and legacy apps con-tinue to have the same guarantees as they would in theabsence of sapps. The LOS is still in charge of protectinglegacy apps and enforcing permissions within its domain,legacy apps cannot directly access resources or bypassLOS protections, and the LOS can inspect and censorlegacy apps. The LOS and legacy apps are guaranteedto maintain their existing confidentiality, integrity, andavailability even in the presence of sapps. (P3) Sapp protection.
Each sapp has confidentiality,integrity, and availability guarantees in the presence ofLOS, legacy apps, and other sapps. (P4) Execution without leaking sapp identity.
Nei-ther the LOS nor sapps should have access to informationthat reveals the identity of other sapps on the device. (P5) Limited trusted computing base (TCB).
Thedesign should assume only a small amount of code tobe trusted and bug-free. The TCB should be around fewthousand LoC i.e., within the realm of formal verification.Satisfying P1–P5 enables several use-cases. For ex-ample, a contact tracing sapp can be granted exclusiveaccess to the Bluetooth card and guaranteed a certain pe-riodic runtime by a user policy (P1). As another example,a user could install a messaging app that is not offeredon the official app stores. They are assured that sapp con-fidentiality and integrity is protected (P3) on the phone.Technically, the legislation cannot force the LOS, otherlegacy apps or sapps on the phone to disclose that the userhas installed or is running a particular sapp (P4). In bothinstances, the user can continue to use the LOS with thesame confidence in its properties as before (P2).
Giving users full root permission to install an sappas an app in the LOS can be a legitimate alternative torooting. However, as the LOS is still mostly in charge,this approach satisfies neither of our properties: The usercannot assign resources (P1), the LOS and sapps are not3 olution P1 P2 P3 P4 P5
Root permissions (cid:55) (cid:55) (cid:55) (cid:55) (cid:55)
Extending LOS (cid:51) (cid:55) (cid:55) (cid:55) (cid:55)
Hypervisor (cid:55) (cid:51) (cid:51) (cid:51) (cid:55)
Traditional TEEs (cid:55) (cid:51) ( (cid:51) ) (cid:55) (cid:51) Our Design (cid:51) (cid:51) (cid:51) (cid:51) (cid:51)
Table 1: Properties provided by different solutions. P3 ( (cid:51) )implies confidentiality and integrity, without availability.protected from each other (P2, P3), and the LOS can mon-itor which sapps are installed and running (P4).
Extending the LOS with the capability of loading user-provided kernel modules, i.e., drivers, would allow usersto configure resource access (P1). However, the LOS andsapps would not be isolated from each other. Furthermore,the LOS would still be in charge of launching and schedul-ing all apps, allowing it to inspect sapps and deny serviceto sapps (P3, P4). We cannot trust the entire LOS (P5).
Hypervisors can virtualize resources and isolate theLOS in a VM [2, 11], thus fulfilling P2 and P3. Sappscan then execute in their own VM. However, the hyper-visor itself executes with the highest privileges. It candirectly inspect VM memory and interfere with its ex-ecution. Moreover, typical hypervisors have large codebases, up to 1M LOC (P5) [11]. More importantly, hyper-visor vendors may resort to similar tactics as current OSvendors and curtail user’s control over their device.
Executing sapps in traditional TEE enclaves canprovide confidentiality and integrity to LOS and sapps(P2) [18, 31] with a minimal TCB (P5) [30]. As the LOScontrols scheduling, availability is only guaranteed for theLOS, not for sapps (partial P3). Furthermore, the LOS canfingerprint a sapp or detect which sapps are executed (P4).Current TEE proposals do not allow access to systemresource without mediation by the LOS (P1).
Our approach is based on a TEE design with a small se-curity monitor (SM) containing the software TCB [31](see Figure 1). The SM runs with special privileges andis responsible for configuring isolation and peripheral ac-cess during context switches between the LOS and sapps.However, there are key differences to TEEs. First, the SMis not omnipotent in our approach: It can manage sappsand the LOS, but not inspect their memory or interferewith their execution. Second, sapps are able to access sys-tem resources such as Bluetooth without the LOS beingable to inspect or interfere. And third, we aim to provideavailability guarantees to both the LOS and sapps.
Management without inspection.
Maintaining exist-ing security guarantees and functionality of the LOS (P2)
OSApp App App Hardware PeripheralDriverAPI (a) Current smartphones
SM LOSLegacyApp LegacyApp Hardware PeripheralDriver API SovereignAppDriver (b) Our proposal
Figure 1: Software architecture of (a) current smartphonesand (b) our proposal. Green denotes trusted components,grey and blue are mutually-untrusted isolation domains.is critical. Thus, we try to reduce the SM’s capabilities byremoving its access permissions to the LOS or sapps. Sim-ilar solutions exist in cloud computing, where a hypervisorcannot inspect the private memory of its guests [1, 29].Traditional ARM or RISC-V platforms have partial sup-port for such hardware-based protection. We discuss howto enable this primitive for smartphones in Section 4.1.
Resource sharing.
Traditionally, OSes manage systemresources. Adding these management capabilities to theSM would bloat the TCB and only shift problems to alower layer. Instead, we propose the LOS to remain incharge of management, but it can concede control of a pe-ripheral to a sapp. From that point on, the SM enforces thesapp’s exclusive control over the peripheral by configuringa hardware access control mechanism to restrict accessto the peripheral memory ranges. In a mobile phone, allperipherals are set statically at design time. Their memory-mapped addresses and version numbers are included in adevice tree file burned into ROM on the SoC. Thus, theSM can consult the trusted device tree to ensure that aparticular peripheral is exclusively controlled by a sapp.Note that this approach only allows one sapp or the LOSto exclusively access a single peripheral at a time. We areinvestigating proposals that allow for more flexibility.
Mutual Progress.
Ensuring availability can beachieved by adding a scheduler to the SM. However, suchscheduling functionality must be immutable, i.e., an at-tacker cannot update it without getting detected. On theother hand, the LOS has a sophisticated scheduler that iswell-suited for legacy apps and hardware but is not trusted.Therefore, we propose a middle-ground: The user or thesapp can specify policies, e.g., a sapp should be assigneda certain amount of runtime during a specified interval.The LOS performs the scheduling. The SM verifies thatit is done as per the sapp- or user-defined policies byrecording the runtime that was granted to the sapp uponcontext switches. Since policy verification may be expen-sive for complex policies, we propose periodic checks.The SM merely verifies that these periodic checks havebeen performed regularly on every context switch. If theSM detects violations to the policies or no periodic checks,4t can impose sanctions (e.g., user notification or lockingthe device operation). We assume that this is a lose-losesituation that all sides want to prevent. Moreover, onceinformed, the user can replace the uncooperative LOS.
Attestation.
In our proposal, a local user wants to attestand verify the code running within a sapp. In addition, theuser wants to verify the scheduling policies and resourceaccesses permissions of the sapp are initialized correctly.Remote attestation of traditional TEEs has the basic mech-anisms to provide such guarantees. We will augment itto include sapp specific information. Moreover, our SMcan directly interact with the user through a secure userinterface to signal successful attestation.
On RISC-V, the SM runs in machine mode. It config-ures physical memory protection (PMP) entries to isolatesapps and the LOS running in the less-privileged user andsupervisor modes respectively [31]. We will use existinghardware mechanisms to restrict the SM from inspectingsapp and LOS memory. Specifically, the SM locks thePMP entries after sapp creation with a sticky bit (whichis only cleared on full system reset) such that it does nothave access to the respective memory regions [50].On ARM, the SM runs in the secure world. It configuresthe TrustZone address space controller (TZASC) [13] toprovision isolated execution environments in the normalworld for the LOS and sapps. To restrict the SMs capa-bility to inspect memory, we are investigating a combi-nation of features from two different TZASCs: TZC-380for locking configurations [8] and TZC-400 for per-corememory isolation [9]. Peripheral access can be enforcedby leveraging the TZASC as proposed in [32].
Threat Model.
In general, we assume the SM and thehardware to be trusted. A malicious SM could deny run-ning certain sapps or monitor the user’s activities. There-fore, the SM should remain as small as possible andshould potentially be implemented purely in hardware.One has to consider at least two perspectives whendiscussing the threat model of the sovereign smartphone.First, the LOS and sapps consider a malicious user againstwhom they want to protect their internal secrets. Thismeans that a local physical adversary is in scope in thisscenario. However, we note that current smartphones alsoconsider such an adversary. Second, from the user’s per-spective, the LOS is considered malicious, e.g., the LOSmight be under societal or even legal pressure to censorsome sapps, or even report the user to law enforcement forthe usage of an illegal sapp. In the worst case, the LOS isentirely malicious and tries to leak the users’ data. In this scenario, the user remains in physical possession of thephone, and thus, there is no physical adversary. We alsoassume that the foremost goal of the LOS is that userskeep running it, as a complete refusal to cooperate mighthurt both the user and the LOS.
Security Analysis.
The user needs to be able to assignsystem resources to sapps (P1). In our approach, the LOScan concede control of individual peripherals to sapps,which the user can then verify. The SM enforces exclusiveaccess to these peripherals as per the trusted device treeburned into ROM.As in traditional TEEs, the sapps or the LOS cannotaccess each other’s private memory (P2 and P3). How-ever, the SM can always read all memory on the system.To address this gap, we plan to remove the SM’s capa-bility to inspect memory by using once-set-never-unsetmechanisms in the hardware (until hard-reset) [50].While our proposal does not grant absolute availabil-ity, it guarantees mutual progress of the LOS and sapps.Moreover, we prevent selective denial-of-service of anindividual sapp. The SM will notice such violations bythe OS and take necessary actions to disincentivize this.We require that sapps can be installed and executedon our platform without being identified by entities otherthan the user and the SM (P4). We stress that this is aknown hard problem [34] and may be impossible for sappswith clearly distinct resource usage patterns. However,there are multiple probabilistic approaches leveragingobfuscation to hide sapp identities. We also note thatthe anonymity property might conflict with the flexibility,policy expressiveness, and the attestation mechanism.Many sapps and the SM will require user interaction.The security of this user interaction is critical to pre-vent various user-interface attacks [15, 23]. There havebeen various studies on the effectiveness of security in-dicators [41, 51], and recent work has proposed secureLEDs [20] or extra buttons [32]. However, it is unclear ifthese proposals are fully applicable to our scenario, or ifthere are more lingering issues.Thus, designing a sovereign smartphone that fulfillsour outlined properties presents a unique set of non-trivialtechnical challenges. Our analysis shows that, althoughnot straightforward, such a design is feasible.
In our proposal, we lay the foundation for a sovereignsmartphone architecture. It combines handing users con-trol over their devices with advantages of current ecosys-tems in a secure manner. It highlights important chal-lenges that need attention from the technical community.5 eferences [1] AMD. AMD memory encryption. Technical report,AMD, 2016.[2] Jeremy Andrus, Christoffer Dall, Alexander Van’tHof, Oren Laadan, and Jason Nieh. Cells: A virtualmobile smartphone architecture. In
Proceedings ofthe Twenty-Third ACM Symposium on OperatingSystems Principles , pages 173–187, 2011.[3] AP News. Google tracks your movements, like it ornot, Aug 2018. https://apnews . com/article/828aefab64d4411bac257a07c1af0ecb .[4] Apple. App store review guidelines. https://developer . apple . com/app-store/review/guidelines .[5] Apple. Apple and Google partner on COVID-19 contact tracing technology, Apr 2020. . apple . com/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology .[6] Apple. Privacy - government information requests- apple. . apple . com/privacy/government-information-requests/ , 2021.[7] Apple Support. Unauthorized modification of iOScan cause security vulnerabilities, instability, short-ened battery life, and other issues, Jun 2018. http://support . apple . com/kb/HT3743 .[8] ARM. CoreLink TrustZone address space controllerTZC-380 technical reference manual. Technicalreport, ARM, 2010.[9] ARM. ARM CoreLink TZC-400 TrustZone addressspace controller technical reference manual. Techni-cal report, ARM, 2014.[10] Ars Technica. Googles iron grip on Android:Controlling open source by any means necessary,Jul 2018. https://arstechnica . com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/ .[11] Paul Barham, Boris Dragovic, Keir Fraser, StevenHand, Tim Harris, Alex Ho, Rolf Neugebauer, IanPratt, and Andrew Warfield. Xen and the art of vir-tualization. ACM SIGOPS operating systems review ,37(5):164–177, 2003.[12] BBC News. Apple drops Hong Kong police-tracking app used by protesters, Oct 2019. . bbc . com/news/business-49995688 . [13] Ferdinand Brasser, David Gens, Patrick Jauernig,Ahmad-Reza Sadeghi, and Emmanuel Stapf. Sanc-tuary: ARMing TrustZone with user-space enclaves.In NDSS , 2019.[14] Business Insider. A security expert found thatApple’s latest iPhone can still track your locationdata, even if you toggle it off for every app, Dec2019. . businessinsider . com/apple-iphone-11-pro-collects-location-data-krebs-report-2019-12?r=US&IR=T .[15] Qi Alfred Chen, Zhiyun Qian, and Z Morley Mao.Peeking into your app without actually seeing it: UIstate inference and novel Android attacks. In ,pages 1037–1052, 2014.[16] CNBC. Fortnite maker: ’Apple has lockeddown and crippled’ the app store, Jul 2020. . cnbc . com/2020/07/24/epic-games-ceo-tim-sweeney-apple-crippled-app-store-with-30percent-cut . html .[17] CNN. Parler, right-wing social media app, isremoved from the Google Play Store, Jan 2021. https://edition . cnn . com/2021/01/08/tech/parler-google-play-removed/index . html .[18] Victor Costan and Srinivas Devadas. Intel SGXexplained. IACR Cryptol. ePrint Arch. , 2016(86):1–118, 2016.[19] Fiona Scott Morton Cristina Caffarra. Theeuropean commission digital markets act: Atranslation | vox, cepr policy portal. https://voxeu . org/article/european-commission-digital-markets-act-translation , Jan 2021.[20] Saba Eskandarian, Jonathan Cogan, Sawyer Birn-baum, Peh Chang Wei Brandon, Dillon Franke,Forest Fraser, Gaspar Garcia, Eric Gong, Hung TNguyen, Taresh K Sethi, et al. Fidelius: Protect-ing user secrets from compromised browsers. In ,pages 264–280. IEEE, 2019.[21] European Commission. The digital marketsact: ensuring fair and open digital markets. https://ec . europa . eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en , Jan 2019.622] Forbes. Parler at risk of going offline af-ter bans from Amazon, Apple and Google,Jan 2021. . forbes . com/sites/jemimamcevoy/2021/01/10/parler-at-risk-of-going-offline-after-bans-from-amazon-apple-and-google/ .[23] Yanick Fratantonio, Chenxiong Qian, Simon PChung, and Wenke Lee. Cloak and dagger: fromtwo permissions to complete control of the UI feed-back loop. In , pages 1041–1057. IEEE, 2017.[24] Google. Developer program policy. https://support . google . com/googleplay/android-developer/answer/10355942?hl=en .[25] Google. Google mobile services. . android . com/gms/ .[26] Google. Android security bulletin - january 2018,January 2018. https://source . android . com/security/bulletin/2018-01-01 .[27] Google. MediaRecorder overview, January2021. https://developer . android . com/guide/topics/media/mediarecorder .[28] Google. Service fees, 2021. https://support . google . com/googleplay/android-developer/answer/112622?hl=en .[29] Intel. Intel trust domain extensions. Technical report,Intel, 2020.[30] Ilia Lebedev, Kyle Hogan, Jules Drean, DavidKohlbrenner, Dayeol Lee, Krste Asanovi´c, DawnSong, and Srinivas Devadas. Sanctorum: Alightweight security monitor for secure enclaves. In , pages 1142–1147. IEEE,2019.[31] Dayeol Lee, David Kohlbrenner, Shweta Shinde,Krste Asanovi´c, and Dawn Song. Keystone: Anopen framework for architecting trusted executionenvironments. In Proceedings of the Fifteenth Euro-pean Conference on Computer Systems , pages 1–16,2020.[32] Matthew Lentz, Rijurekha Sen, Peter Druschel, andBobby Bhattacharjee. Secloak: ARM TrustZone-based mobile peripheral control. In
Proceedings ofthe 16th Annual International Conference on Mo-bile Systems, Applications, and Services , pages 1–13,2018. [33] Moritz Lipp, Michael Schwarz, Daniel Gruss,Thomas Prescher, Werner Haas, Anders Fogh, JannHorn, Stefan Mangard, Paul Kocher, Daniel Genkin,et al. Meltdown: Reading kernel memory fromuser space. In , pages 973–990, 2018.[34] Adam Meyerson and Ryan Williams. On the com-plexity of optimal k-anonymity. In
Proceedings ofthe twenty-third ACM SIGMOD-SIGACT-SIGARTsymposium on Principles of database systems , pages223–228, 2004.[35] Pine64. PinePhone. . pine64 . org/pinephone/ .[36] Purism. Librem 5. https://puri . sm/products/librem-5/ .[37] Reuters. Denmark angry at Google censor-ship of some Danish content, seeks talks, Aug2020. . re uters.com/article/us-google-censorship-denmark-idUSKCN2561TG.[38] Reuters. Germany at odds with Apple onsmartphone coronavirus contact tracing,Apr 2020. . reuters . com/article/us-health-coronavirus-europe-tech/germany-at-odds-with-apple-on-smartphone-coronavirus-contact-tracing-idUSKCN2251MR .[39] Samsung Business Insights. What are the risksof sideloaded Android applications?, Nov 2019. https://insights . samsung . com/2019/11/26/what-are-the-risks-of-sideloaded-android-applications/ .[40] Samsung Knox. What is a Knox war-ranty bit and how is it triggered? https://docs . samsungknox . com/admin/knox-platform-for-enterprise/faqs/faq-115013562087 . htm .[41] Stuart E Schechter, Rachna Dhamija, Andy Ozment,and Ian Fischer. The emperor’s new security indi-cators. In , pages 51–65. IEEE, 2007.[42] Douglas Schmidt. Google data collection.Technical report, Vanderbilt University, 2018. . dre . vanderbilt . edu/~schmidt/PDF/google-data-collection . pdf .[43] San-Tsai Sun, Andrea Cuadros, and KonstantinBeznosov. Android rooting: Methods, detection,and evasion. In Proceedings of the 5th Annual ACMCCS Workshop on Security and Privacy in Smart-phones and Mobile Devices , pages 3–14, 2015.744] The Guardian. France urges Apple and Googleto ease privacy rules on contact tracing, Apr2020. . theguardian . com/world/2020/apr/21/france-apple-google-privacy-contact-tracing-coronavirus .[45] The Guardian. NHS in standoff with Appleand Google over coronavirus tracing, Apr 2020. . theguardian . com/technology/2020/apr/16/nhs-in-standoff-with-apple-and-google-over-coronavirus-tracing .[46] The New York Times. Fortnite creator sues Ap-ple and Google after ban from app stores, Aug2020. . nytimes . com/2020/08/13/technology/apple-fortnite-ban . html .[47] The Verge. Google removes Samsung’s firstAndroid ad blocker from the Play Store, Feb2016. . theverge . com/2016/2/3/10905672/google-samsung-adblock-fast-android-ad-blocker-removal . [48] The Verge. Apple just kicked Fortnite off the appstore, Aug 2020. . theverge . com/2020/8/13/21366438/apple-fortnite-ios-app-store-violations-epic-payments .[49] The Verge. Apple is blocking Apple siliconmac users from sideloading iPhone apps, Jan2021. . theverge . com/2021/1/15/22233754/apple-blocking-m1-iphone-app-sideloading .[50] Andrew Waterman, Yunsup Lee, Rimas Avizienis,David A Patterson, and Krste Asanovi´c. The RISC-V instruction set manual volume ii: Privileged archi-tecture. EECS Department, University of California,Berkeley , 2019.[51] Tara Whalen and Kori M Inkpen. Gathering evi-dence: Use of visual security cues in web browsers.In