Overview of Mobile Projects - That focus on either/and/or security, privacy, anonymity, source-available, Freedom Software.

Where is such a list? At time of writing, there is no recommendation on that page.

It’s possible to implement this in a secure way. When there’s a will, there’s a way. But if there’s no will, there’s certainly reasons.

At the very least this could be implemented as a boot option. Here’s the design plan how this user/admin/superadmin isolation could implemented in Kicksecure / Whonix: Multiple Boot Modes for Better Security: an Implementation of Untrusted Root

But it’s not wanted by GrapheneOS lead developer:

Quote GrapheneOS lead developer

GrapheneOS is not aimed at power users or hobbyists aiming to tinker with their devices more than they can via the stock OS or AOSP.

Refusing root rights without user data wipe has many repercussions. From the table iPhone and Android:

  • Internal storage can reasonably easily be removed and mounted elsewhere for the purpose of data recovery or hunting malware / rootkits. - No.
  • Internal storage can reasonably easily be decrypted once transferred to a different device if password is known. - No.
  • Can reasonably easily boot from external hard drive, ignoring internal harddrive for purpose of data recovery or hunting malware / rootkits.- No. But any Android phone currently has this issue.
  • Can reasonably easily create full data backup. No.
  • Applications cannot refuse data backup (for purpose of malware, spyware analysis or backup and restore). - No.
  • No culture of users can ask device (code) for permission and device (code) will decide to grant or refuse the request. - No.

Investigation of any compromise without root is hindered. Not possible to create a full raw backup, boot, create another full raw backup and then compare the changes on the disk.

Without such essential freedoms easily accessible, I consider this a platform inherent security risk as a (high profile) user suspecting they’ve been compromised, cannot hand their device to anyone capable of malware investigation. The data isn’t accessible. The device locks out the user from their own data with no recourse.

And that was asked. And someone is free to point out “there’s no I2P on Whonix-Gateway”, “there’s no I2P inside Whonix-Workstation”.

In Installation and Fix of i2p inside Whonix-Workstation by Default I have beenanswering to the maximum of my ability any and created config options to simplify this (the redirect custom workstation ports to the gateway using anon-ws-distable-stacked-tor part).

Such modding even if not implemented in the default Whonix builds is however very much welcomed.

Indeed. Undeniable. It’s a question of whether the projects wants that or not. Plans the feature, prioritizes or rejects the feature.

I guess it boils down to:

Does one oppose the war on War on General Purpose Computing?

Or asked in a different way…

Does one support the right to general computing?

The easiness of providing freedom is the critical point. Is the ease of general computing a development goal or not. Should the user be in ultimate control of all the programs running on their device or should developers control users through Device Attestation such as SafetyNet. That’s a point that should I want to be included in the mobile project comparison.

Should the user be in control or should the app vendors be in control?

Not providing easy access to root rights and supporting device attestation means that the app vendors should be in control.

There is none.
What I am proposing is creating new sections in the MobileOS page.
Recommended and Avoid sections.
Madaidam said to separate here

No, it is not possible.
Requires unlocking the bootloader, disabling verified boot.

Explained above this would remove security features.
Also multiple boot modes on Mobile is for debugging purposes, not for secure usage.
On computer, multiple boot options is available easily because there is not even secure boot for the majority of pcs.
I think, also as this removes the verified boot, there will be malware persistence across reboots.
https://madaidans-insecurities.github.io/android.html#rooting
In addition, root fundamentally breaks verified boot and other security features by placing excessive trust in persistent state.

No but I believe that is because the decryption keys are in the chip.

Not sure what this means exactly but I can backup my profile/user, but probably not all the partitions. So it is not “full” backup, but full “user” backup.

Isn’t that the security of it, not being able to run any root commands.

Not easy to do that on mobile, yes there is few vendors, but with OEM unlocked and build and signed, it is possible, just not documented on grapheneos site.

Regarding root, locking vs not documenting and advising against is a different thing.

Regarding attestation, GrapheneOS uses their own Attestation Server. Although on Auditor app, you cannot change the server, you will need to build it yourself with your server configured.
But, you don’t even need their servers, you can download auditor app to another android device and verify the first device with it.


In summary, you (Patrick)

  • wish for root easily available as a boot mode or build distributed.
  • to have full control of the device, but as of now, requires you to build and sign, and that is how mobile systems works.

On the other hand GOS, AOSP:

  • will not provide easy for because of many security issues, including breaking verified boot
  • breaking verified boot leads to malware persistence
  • full control of the device via should not be implemented for distributed user builds

The war on general purpose computing to make any user have root breaks the security model of AOSP.

Having control over everything is great, but that is for advanced users, there is no vendor locking from GOS, it is just not distributed with root as it is not suitable for users.

Also, the manual malware check of the device is not needed because of verified boot.
So in the end, what remains, is full system backup for some unkown reason because malware changes are reverted on boot via verified boot and user data backup is enough to create the same user again.

  • /root (system, vendor, oem) - cleaned on boot
  • /user_data (user space applications) - can be backed up

I don’t know how malware inspection works on mobile, but with the verified boot, it greatly reduces the attack.

No. There is no hard technical requirement for that. Lower levels (such as firmware) and hands over control to the next level (such as bootloader). If any stage is broken, then verified boot is broken. The levels are approximately: hardware trust root → firmware → (shim ->) (grub) bootloader → (linux) kernel → kernel modules → initrd → (systemd) init.

For example, you can have verified boot SecureBoot (actually RestrictedBoot) on the Intel/AMD64 platform. Windows uses it.

As for Linux desktop distributions, I don’t think any offers full verified boot support yet. But that partial verified boot process is interesting to use an as example how this could be implemented. The firmware has a built-in key (by Microsoft). It verifies shim and if the signature checks out, it hands over control to shim. Next, shim verifies grub and hands over control to it. Next, grub verifies the kernel. Then it should verify the initrd but that’s not implemented in any Linux desktop operating system as far as I know. (Chromium OS …) That’s where the verified boot implementation stops for now.

So for most Linux desktop distributions currently the verified boot isn’t very useful. It’s a development progress start but it’s incomplete. The takeaway message is, that any level during the boot process can implement its own key management.

For example, on Linux systems using verified boot, users have to manually sign kernel modules so these can be load. But what does that tell us? That users can add their own keys which the Linux kernel accepts to verify kernel modules. There’s no need to add user custom key to the firmware just to load custom installed kernel module (such as the VirtualBox kernel module or LKRG).

Consider a design where the current way to implement verified boot is called the “the unbreakable stage1 verified boot”.

This stage1 verified boot (immutable, verity-protected, signed file system) could verity a stage2 image. If it’s modified it could report it and refuse to boot (unless some kernel parameter is set by user but this needs more description).

Similar to Android A/B (Seamless) System Updates concept where when the upgrade is supposedly atomic. If it fails, it reverts to the previous one. Two images. The old one and the new one. And these don’t break verified boot either.

This blog post goes into that direction: Fitting Everything Together
But while probably well intentioned, the “Developer Mode” described in that blog post could also lead to further user freedom restrictions.

At the moment the big surveillance corporate complex cannot yet lobby the governments to mandate that only big corporate signed full verified boot operating systems can boot. But if most devices are verified boot anyway and only a few Linux desktop computers remain while they’re one day also only available with full verified boot… At some point there’s not much devices left where general computing is possible without the approval (signature) of a third-party. And then a law mandating that only corporate signed full verified boot operating systems can boot becomes more likely.

Indeed. It’s mentioned in the Android vs iPhone table footnotes.

I am referring to the following. It’s in the table, footnotes…

Quote <uygulama>  |  Android Developers

android:allowBackup

Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.

Currently on most Androids (which have verified boot + refuse root rights to the user), if an application is configured by the vendor allowBackup=false, then no backups are possible unless verified boot is broken and/or the device has been rooted.

If no backups are possible, then it’s also not possible to inspect the data. In essence, the app vendor gets a bit of private storage on the user’s device which the user cannot access.

Operating system and app vendors dictating such restriction to users is a bad direction to go specifically if more and more devices are already locked out the user in that way (most phones used my most users, smart TV, tables and whatnot) and are already developing towards that direction and the few remaining ones, which are desktop computers are already on the decline as well as going into the same direction. Referring to Intel/AMD64 platform with RestrictedBoot.

The the question boils down, which one does one support. Power to the hardware/software vendors or power to the users.

No. Verified boot unfortunately isn’t a cure for all the security threats. If verified boot is broken, then it’s broken. Meaning, then malware can persist.

Any locked Android where the modding community managed to found a vulnerability to exploit it to free/unlock the bootloader is evidence that verified boot has been broken in past. To illustrate:

  • When the modding community broke the bootloader then they did it to gain control over their hardware.
  • When Advanced Mobile Phone Spyware breaks verified boot / the bootloader, then they do this to spy on the user why at the same time keeping the user locked out from auditing. Malware uses technically similar methods to how the modding community sometimes archives unlocking of the bootloader. This then it invalidates any security advantages by verified boot. And that is then the worst of both worlds. Malware has the ability to spy on the user while the user still has no access ability to perform an audit of their device.

User freedom and security auditing is crucial in security. Verified boot and locking the user out is “trust us”.

It mostly doesn’t. Security researchers have to invent complex hacks to get around the obfuscation and locks. Requires bootloader unlock. But if bootloader unlock isn’t possible without user data wipe then auditing is prevented. Here’s a research paper that briefly mentions research hurdles vs user locked-out bootloaders as well as the research methods.

Quote:

Reverse Engineering

A fairly substantial amount of non-trivial reverse engineering is generally required in order to decrypt messages and to at least partially decode the binary plaintext. 1) Handset Rooting: The first step is to gain a shell on the handset with elevated privileges, i.e. in the case of Android to root the handset. This allows us then to (i) obtain copies of the system apps and their data, (ii) use a debugger to instrument and modify running apps (e.g. to extract encryption keys from memory and bypass security checks), and (iii) install a trusted SSL root certificate to allow HTTPS decryption, as we explain below. Rooting typically requires unlocking the bootloader to facilitate access to the so-called fastboot mode, disabling boot image verification and patching the system image. Unlocking the bootloader is often the hardest of these steps, since many handset manufacturers discourage bootloader unlocking. Some, such as Oppo, go so far as to entirely remove fastboot mode (the relevant code is not compiled into the bootloader). The importance of this is that it effectively places a constraint on the handset manufacturers / mobile OSes that we can analyse.

Unbreakable verified boot + user locked out = no auditing possible for users. They are then only users, guests, non-administrators on their own devices.

Expanded a lot on bootloader locking, verified boot, non-root enforcement versus root rights, the ideological conflict of user-freedom prioritization versus app developer prioritization, user controlled keys, verified boot + locked bootloader + root compatibility.


Added:

The section about GrapheneOS is misleading/inaccurate and should be fixed/removed.
Disclosure: I am a moderator on GrapheneOS’s Matrix and Telegram channels (not an actual developer).

Comes with numerous anti-features. Some of the same anti-features as Google Android Anti-Features

Without arguing whether the features mentioned are anti features or not (though most of them are security features, not anti features imo), they are the same on every Android distribution, including CalyxOS, /e/ OS, LineageOS, and CopperHeadOS. It is unfair to say this specially about GrapheneOS but not the others operating systems.

Argues that allowing users to gain root (superuser) access would inevitably break the security model and that there is no conceivable solution that can uphold both user security and freedom.

Only LineageOS and /e/ OS ships userdebug builds. I know that CalyxOS does not, and I assume CopperHeadOS does not either. Again, it is unfair to say this about GrapheneOS and not the other operating systems.

Worth noting:

  • Neither LineageOS or /e/ OS support verified boot
  • Both of them come with significant security regressions beyond just not having verified boot, including not shipping firmware updates. /e/ bundles in years old versions of Orbot and call it their “IP scrambler”. This is specific to those 2 operating systems and not mentioned anywhere on the wiki.
  • Unlike on Linux, apps are designed to work without root, so there really isn’t any significant reduction in freedom.

Sometimes when they use the word “security” in connection with GrapheneOS, they do not mean what is normally understand normally mean by that word: protecting your machine from things you do not want. They mean upholding the much praised “Android Security Model”, which includes providing guarantees to app developers that the operating system will behave in a certain way at the expense of user freedom (anti-features).

Not sure where this even comes from. GrapheneOS provides significant user controls over what apps can and cannot do beyond just the “Android Security Model”.

See some of its user-facing features:

  • Network permission toggle
  • Sensor permission toggle
  • Storage Scopes
  • SUPL control
  • Sandboxed Play Services (which runs Play Services unprivileged and force it to play by the permission system)

GrapheneOS already provides much better control and guarantees regarding what apps can and cannot access compared to a “rooted” Android phones, either via adb or via Magisk.

  • Denied access to the devices host’s file (“/etc/hosts”) which can be used to block advertisements.

This is from the Android anti-features section, but I want to point out that DNS based blocking can still be done with a VPN/custom DNS server. Regardless, either solution is privacy and security theatre and are trivially bypassable.

More and more businesses communicate over proprietary messengers such as WhatsApp and WhatsApp cannot be used on rooted devices or with custom ROMs.

WhatsApp works just fine on GrapheneOS.

More and more government services require the same. For example, an Android or iPhone with Google maps location history enabled and Skype is mandatory for entering Japan. Google maps is produced by Google and Skype produced by Microsoft are among the worst privacy-intrusive companies.

This is not GrapheneOS’s problem. If the government wants that information, then you have to give them said information. It doesn’t even matter if it is Android or a traditional Linux desktop operating system.

Many people would loose their job if they decided not to use for example WhatsApp since many companies internally use WhatsApp.

Again, WhatsApp works perfectly fine on GrapheneOS.

Three are still 2 billion unbanked people. People who do not even have access to the most basic financial services such as a bank account. For unbanked people it would be unreasonable and should not be expected of them to refuse their first chance to use a mobile banking app with such restrictions

A significant amount of banking applications do work on GrapheneOS. I have a crowd sourced list of them on my website. Even if an app does not work, there is nothing stopping them from logging in using a web browser, just like on a computer.

Supports DRM (Digital Restrictions Management / walled garden / anti-freedom / Google SafetyNet style hardware attestation where developers can configure their applications to only run on devices on certified firmware which are a technologies that are part of the War on General Purpose Computing.

Given what is written in the wiki - people not being able to using WhatsApp for their jobs, banking apps not working, etc because of DRM - would you prefer it if GrapheneOS did not support DRM at all? Because this will not result in those app changing - it will just result in people not being able to use them, which is the problem at hand.

Besides, how is this GrapheneOS’s problem? Things like SafetyNet is a common issue with custom OSes, not GrapheneOS specific. Why is this not mentioned against CalyxOS, CopperHeadOS, LineageOS, and /e/ OS?

Potential Conflict of Interest. If GrapheneOS wouldn’t disable easy to use technical ways that most laymen users can use to gain root and/or to keep control over the software running on their devices, then GrapheneOS’s chances to be ever get a highly profitable hardware producer partnership would be severely diminished.

The supported “ways” to gain root are not in the stock OS, GrapheneOS can’t “disable” it when it doesn’t exist to begin with. Also, as mentioned above, the apps are designed to work unprivileged, so what control are you even losing? If anything, I would argue that designing a system with root then catering to apps which insist on having it is anti freedom, because it will make it significantly harder if not impossible to control what those apps can do. With that being said, the same thing can also be said about every other Android based OS on the list, so why is it only said about GrapheneOS?

Full verified boot which would be great if the key would be held by users and encouraged through a first start process or similar instead of held by the developer.

The user can make their own build and sign with their own keys. The same thing can be said about every other Android based operating systems. I don’t see how it could work any other way.

The other approaches like Heads are akin to downloading random binaries from the developers then blindly signing them and gaining 0 security/freedom in the process. If anything, such approach is quite bad because you cannot even do automatic updates anymore. If you use automatic updates and see a warning, you would have no idea if it is because of an update or because of actual tampering/corruption.

Ironically, in order to to purchase a device compatible with GrapheneOS, one has to buy a supported Google Pixel device and therefore support with the purchase one of the biggest anti privacy, most data harvesting and user freedom prohibiting companies in the world, Google.

Currently only the Pixels meet the hardware requirements, one of which is support for verified boot for third party operating systems. GrapheneOS is about providing actual security and privacy for the end user, not about being anti-Google.

There are also other inaccuracies, such as:

Location information: IP address, GPS, and other sensors providing information on nearby services such as Wi-Fi access points and cell towers. It was recently discovered Google continues to track users even after they opt-out of Location History.

This is just plain wrong. What’s going on here is that the user disable location history on the Google account settings (entirely policies based) as opposed to using the location toggle on the OS (which is OS enforced). This is a messed up configuration on the user’s part, not a problem with Android, even on the “Google Android” phones.

Local storage: Storing personal information locally with local browser storage (like HTML5) and application data caches.

This is every-operating-system-and-non-Tor-browser ever.

Regading /e/:

Open source as much as possible.

Nope. This is just marketing. See DivestOS’s notes on /e/ as an example (I am unable to post links so I will just quote part of it here):

  • Includes the proprietary Mapbox library
  • With a tracker
  • Includes proprietary Google Widevine DRM on nearly all devices
  • Includes the proprietary Magic Earth app for navigation Despite FOSS user friendly alternatives existing such as OSMAnd and Organic Maps
  • Enables Safetynet checks by default which downloads and executes obfuscated proprietary code from Google

Regarding Lineage:

Google services can be optionally installed as an add-on

Which is as privileged as stock OS. Don’t see how this fits into the whole freedom/privacy/open source/anonymity thing. The Sandboxed Play Services that’s available on GrapheneOS is what’s actually providing privacy/security/freedom, not this.

Regarding Fairphone:

Hardware: Now the third iteration Fairphone 3 is available and is a testament to the success of the prior models.

They are on the fourth generation now, and both the 3rd and 4th generation have botched verified boot because they use the AVB test keys.

Built for easy hardware repairs and upgrades to combat planned obsolescence .

This is just marketing - they ship software updates late and the SOC is already 1 year old or so when the phone comes out. Effectively, a fairphone only has around 2 years of security update for the firmware SINCE THE RELEASE DATE as opposed to 5 years on the Pixel.

Regarding OnePlus:

  • Hardware that grants users the “right to flash”

Nope. It is extremely broken. See CalyxOS’s blog post on OnePlus 8+9 firmware issue and DivestOS’s issue tracker for the OnePlus 7 series.

1 Like

Thank you for taking time and posting this here!

I am not sure this could be regarded as a revision request from a project representative but either way. Until this wiki chapter has been improved [1], I added the following change.

This wiki chapter about GrapheneOS is currently being under revision discussed here: https://forums.whonix.org/t/overview-of-mobile-projects-that-focus-on-either-and-or-security-privacy-anonymity-source-available-freedom-software/4557/48

In other words that chapter is offline for now so this can be discussed, edited without time pressure.

[1] Some points are valid. If any statements apply to GrapheneOS and other distributions, then these need to be moved to separate wiki chapters. For other points, it’s just non-ideal wording. And maybe more. Will see later.

It will take some time to research, address of of this. Sometimes I might quote, discuss some parts. Some stuff I might not address for now. (But that wiki chapter will stay offline or at least that part will stay removed until that was done.) In that case, I won’t be trying to avoid/ignore the point. It will be addressed later. Once your post has been fully addressed, I will say something like:

“Post Overview of Mobile Projects - That focus on either/and/or security, privacy, anonymity, source-available, Freedom Software. - #48 by TommyTran732 has now been fully processed (points raised researched, discussed, improved on the wiki page). Should some points have been forgotten or still apparently having some issue, please bring this up again.”

So far for the meta reply. The first reply addressing the content coming soonish.

I am addressing these points rather “randomly”. So easy (for me) things first that don’t require lots of research first.

All points regarding distributions (quoted now or not) other than GrapheneOS, you’re welcome to post references. That would really help. Ideally, original/good sources.

If it’s marketing but not actually true, I am eager to improve the wiki.

Where this is coming from… Here’s a quote, I wouldn’t know how to summarize and word it better for now:

Security is very important. Why? In order to not be exploited by strangers (criminals, spys…) against my interests. If security enables exploitation against my interests (by whomever, be it the OS vendor, the movie industry, or the government), it is not the security I want.

Here are some more citations from people that have the viewpoint:

There’s basically two groups.

  • A) The traditional, normal definition of computer security:

It’s about the security of the person who’s talking. I.e. the user’s security. “Freedom security”. The user can remove the microphone permission from the app? That’s “user security”. I.e. just “security”. An app is adamant about location permission or reading hardware serials and otherwise refused to work but the OS or some other app provides a way to provide fake information, that’s also “user security”.

  • B) The re-definition of “security” by cooperates such as Google, distributions such as GrapheneOS and others.

These are often security features that vendors want. These wants power to control how code is executed / data is processed on user’s devices. This includes DRM, SafetyNet.


An Android app can configure features such as allowbackup=false. This will prevent (or at least make it super difficult for the user) to backup application data. That’s an anti-feature. That’s probably part of the “Android Security Model”. I am part of group A). I don’t care what the Android Security Model has to say about this. Let me look at my data on my device. Let me do the backup.

If I cannot look at all data on my device through some normal, easy mechanism, then I am not really the person with the highest user rights, i.e. device administrator. Then I am just a user. Not an administrator. I am not secure if I cannot view that data. It’s part of malware analysis. It’s a basic feature of “normal” Linux distributions (such as Debian) where at least root has some way to view all application data and network traffic. So being able to analyze the application, to see what data it sends over the network or it stores (either the app stores it intentionally or because a third party compromised the app) is essential for malware analysis. An operating system having anti-features that prevent this are considered user freedom restrictions and that part is considered anti-security / insecure.

I didn’t test the functionality / check the security of implementation of GitHub - chriswoope/resign-android-image: Resign Android OS (esp. GrapheneOS) images with your signing keys and add ADB root and other modifications. But that’s irrelevant to explain the different uses of the word “security”. As far as resign-android-image’s readme goes, it goes exactly into the direction, having the goal of “real” security and user freedom, where the user and not someone else is in full control of their own devices.

Does this explain what this is about?

I am happy to elaborate about this in the wiki. Could probably use parts of this forum post of mine.

And yes, this wouldn’t only apply to GrapheneOS but also other distributions. So this will go to its own chapter.

Btw why was/is the GrapheneOS chapter the longest one? That’s not to specifically pick on GrapheneOS. It’s a bit similar to looking at Free Haven's Selected Papers in Anonymity and then asking why is all research about Tor and none about let’s say I2P or VPNs. Lots of issues with Tor being expressed without mentioning that these equally or even more so apply to I2P, VPNs as well. For some reasons, Tor caught more interest by researches. Hence, more research papers are available about Tor. In a way, not a fair comparison of all.

Since GrapheneOS has the top or very high search results for search engine search terms such as “mobile phone security operating system” as well as in my experience seems to be most frequently brought up in online discussions around topics of Android and security you could argue that it’s the most popular in that niche. GrapheneOS is also what caught most of my interest in this area.

To have a more extensive writeup on GrapheneOS but many other Android ROMs basically only being short mentions (interesting stuff to maybe look up later, see how these projects develop over the next years watchlist) and then call that wiki page a Mobile Operating System Comparison is non-ideal. Hence, the depth of review for each mobile operating system will be expressed in the future and/or short mentions versus more extensive reviews will go to different top level wiki chapters.

The wording is imperfect indeed. Rather than saying “If GrapheneOS wouldn’t disable easy” it could be rewriten as “If GrapheneOS would support”?

And since it’s not only about GrapheneOS but also other distributions, I need to rewrite that sentence without mentioning GrapheneOS or while not only mentioning GrapheneOS.

My point is a different one:

I would prefer if GrapheneOS would provide easy, secure ways to become a full device administrator. Reasonable documentation, warnings, sure thing. Allow easy customization. There’s no need for a feature request because Daniel already expressed his viewpoints on this. Was quoted in the wiki.

https://archive.ph/94YVQ

  • It doesn’t sound like you want GrapheneOS since you don’t care about the core security goals. I recommend using something else.

  • GrapheneOS is not aimed at power users or hobbyists aiming to tinker with their devices more than they can via the stock OS or AOSP.

I am not expecting GrapheneOS to add features such as “ignore_allowbackup_false=true”, i.e. a feature that ignores allowbackup=false.

But GrapheneOS would probably become my favorite Android distribution if it there was an easy way for third parties developers (such as “$Magisk”) to provide apps that can implement features such as “ignore_allowbackup_false=true” when then can be easily used by users.

I am writing “$Magisk” and not Magisk because it doesn’t have to be literally Magisk. I don’t know enough about it. You could say Magisk is insecure. That’s not the point. It’s more “alike Magisk” or better said software solutions that could provide similar functionality similar to Magisk.

Desired state of GrapheneOS that I would like to see… Example…
Applications such as banking apps have a SafetyNet check?

  • by GrapheneOS: Doesn’t work. Not GrapheneOS’s fault that apps are adamant about this check. GrapheneOS doesn’t need to develop on SafetyNet bypass. I would celebrate such features but there’s really no need for it.
  • third party developers (with a mindset similar to Magisk and its users): Have the ability to develop software solutions that can bypass user freedom restrictions such as SafetyNet. Users could easily install these. This means without having to fork GrapheneOS or rather complicated looking (and maybe new issues introducing) methods such as resign-android-image.

How that could be done, see:
Verified Boot - Kicksecure chapter Verified Boot Compatibility with Rooted Phones in Kicksecure wiki

I don’t think a web browser is a great solution. Often none at all. This is elaborated here:
Mobile Operating System Comparison: Difference between revisions - Kicksecure

But indeed not specific to GrapheneOS and will be moved to a dedicated wiki chapter before it goes online.

(The wiki diff can only be viewed when having a wiki account. Not yet online. Soon visible without wiki account after moving it to a dedicated wiki chapter.)

This link?

Seems like a great list! Will add to the wiki.


Btw you can also post links now.
(Previously you couldn’t. Background details of this: Posting Links for New Users)

I was sure that it wouldn’t work.

  1. I experimented with a rooted / custom ROM phone (prior GrapheneOS release) and saw a WhatsApp screen saying something like “you cannot use WhatsApp because your phone is rooted”. And there was no button to say “ok, proceed anyhow”.

  2. The WhatsApp FAQ About rooted phones and custom ROMs reads

Custom ROMs and rooted phones aren’t supported by WhatsApp.

Which I guess now can mean many thing from forced refusal to start or just a potential warning that there’s a high likelihood oi issues and no bug reports would be accepted.

I am not sure this could be regarded as a revision request from a project representative but either way. Until this wiki chapter has been improved [1], I added the following change.

I am not a representative of GrapheneOS. No one actually speaks for the project but Daniel Micay. I am just saying it so people don’t say I am pretending to be a random third party.

All points regarding distributions (quoted now or not) other than GrapheneOS, you’re welcome to post references. That would really help. Ideally, original/good sources.

If it’s marketing but not actually true, I am eager to improve the wiki.

Yeah, I will be more than happy to link them. The problem is I cannot post any links on Whonix’s forum at all. It will not let me post :confused:

1 Like

Very weird. I already increased your user level from “0: new user” to “1: basic user”. Then posting links should be possible. It is not possible for new accounts (that are not manually updated) but usually always worked.

Still an issue? Any error message?

If still an issue, please encode the links. Documented here:
https://www.kicksecure.com/wiki/Forum_Best_Practices#Posting_Links_for_New_Users

Either as [link text](link) or just link. I’ll then “unencode” links, i.e. make them clickable.
Sorry for that trouble.

  • A) The traditional, normal definition of computer security:

It’s about the security of the person who’s talking. I.e. the user’s security. “Freedom security”. The user can remove the microphone permission from the app? That’s “user security”. I.e. just “security”. An app is adamant about location permission or reading hardware serials and otherwise refused to work but the OS or some other app provides a way to provide fake information, that’s also “user security”.

Does this explain what this is about?

The thing is, this overlooks the various “Freedom Security” GrapheneOS adds. Malware analysis aside, Android does provide some of these protections (and does it much better than say, Debian).

Since Android 10, apps without the READ_PRIVILEGED_PHONE_STATE permission cannot actually read hardware serials, IMEI, and the like. GrapheneOS runs Play Services unprivileged if you opt into using it, so it cannot see your hardware identifiers like on stock OS either. It doesn’t have to deal with apps having access to /sys and reading your identifiers that way.

What about apps insisting on having access to all of the user’s files? GrapheneOS adds storage scopes so you can force these apps to just work with limited storage permission regardless. What about access to network and sensors? On stock OS, the sensor permission is granted to all apps by default, and the network permission is granted to apps which declare it in their manifest. GrapheneOS added per app control for this. This falls into the first camp, it provides what the users want rather than what software vendors want.

1 Like

I forgot to mention, regarding hardware identifiers:

On stock OS/CalyxOS/other distributions, SUPL sends the IMSI to either Google or whoever the carrier sets it to be:

See section 4.5 on this blog post: CalyxOS: De-Googled geht anders – Custom-ROMs Teil2 ⋆ Kuketz IT-Security Blog (kuketz-blog.de). (I generally do not agree with using connection counts as a privacy metric, but there is a packet capture of the request there).

GrapheneOS on the other hand just changes this to send the IMSI as 0 (as if it doesn’t have a sim card inserted) by default. Implement toggle for restricting device identifiers sent to non-carrier Google SUPL server · Issue #915 · GrapheneOS/os-issue-tracker (github.com)

1 Like

It seems to be working now. Here are the links regarding the other non-Pixel phones I mentioned:

Fairphone botching verified boot:

Bootloader // AVB keys used in ROMs for Fairphone 3+4 - Discuss / The Products - Fairphone Community Forum

Fairphone using outdated SOC and will not have security updates for the firmware after ~2 years:

Why did Fairphone use an outdated SoC for the FP4 even though they knew Qualcomm would not support it longer? - Discuss / The Products - Fairphone Community Forum

Pixel support life cycle:
Google Pixel | endoflife.date

In general, the SOC vendor has to provide support for the SOC, and then the OEM has to distribute it. If the SOC vendor does not provide support for the SOC, then there is nothing the OEM can do. Think of computer vendors selling Intel CPUs. If Intel considers the CPU end of life and no longer release microcode updates for it, there is nothing the computer vendor can do. The same thing applies here.

As far as I know, old Qualcomm SOCs are supported for 3 years since their release date. Newer ones are supported for 4 years. Google makes their own SOC now and promises a full 5 year of support since the release date of their phones (rather than the SOC).

The Fairphone 4 uses an SOC that only has 3 years of support and was only released 1 year after the SOC came out. So it is clear that they cannot provide fixes for it after 2 years, as the discussion thread shows.

Here is also a tweet from Micay: https://twitter.com/DanielMicay/status/1444028533186117633?s=20

OnePlus from the 7th series and above stops supporting relocking with alternative operating systems:

OnePlus 7 Series Firmware Issue Fun · Issue #167 · Divested-Mobile/DivestOS-Build (github.com)

OnePlus Android 12 firmware - relocking no longer works (calyxos.org)

The OnePlus 7 series has already gone EOL, so only the OnePlus 8 series and above are worth discussing at this point: OnePlus 7/7T reach end-of-life as OnePlus rolls out final OxygenOS update (xda-developers.com)

1 Like

Mobile Operating System Comparison chapter GrapheneOS in Kicksecure wiki is back online.


Changes:

Not wrong but inapplicable. The wiki is about:

Users are prevented from accessing the device’s host file (/etc/hosts), which can be used to block advertisements.

Blocking advertisements with /etc/hosts is imperfect, sure. That’s always a cat and mouse game. It can be “good enough” in the opinion of the user but it cannot be perfect. The wiki didn’t bring up privacy/security in this context. So in the limited context of advertisement blocking the statement is true.


If something has’t been addressed yet regarding GrapheneOS, please mention, copy/paste or quote.