[HN Gopher] Experimental release of GrapheneOS for Pixel 9a
___________________________________________________________________
Experimental release of GrapheneOS for Pixel 9a
Author : moelf
Score : 344 points
Date : 2025-04-13 01:05 UTC (21 hours ago)
(HTM) web link (grapheneos.social)
(TXT) w3m dump (grapheneos.social)
| JeremyBarbosa wrote:
| I was bit confused why this was notable, but the Pixel 9a just
| released Thursday. So this is an incredibly fast turnaround for a
| community OS.
| bitpush wrote:
| They are starting from an OS that is made to work on these
| devices.
| nzeid wrote:
| ?
|
| As in the OS in question is GrapheneOS itself?
| nofriend wrote:
| i assume referring to aosp
| nzeid wrote:
| Right, and that would actually be a mountain and a
| monumental achievement.
|
| But one could argue that the team can move fast on 9a
| because they can piggyback existing (GrapheneOS) distros.
| strcat wrote:
| All Android devices support running the Android Open Source
| Project via Treble and we could quickly add support for non-
| Pixel devices doing things in a reasonable way too. Those
| devices don't meet our hardware security requirements
| (https://grapheneos.org/faq#future-devices) which is why we
| don't support them. It wouldn't be that hard to add a Sony or
| Motorola device but they're missing the expected security
| features and proper updates. It wouldn't be possible to
| provide our standard security protections on them which is
| the real blocking issue, not difficulty. Android has made
| device support simple, but the rest of the Android device
| ecosystem is not at all competitive in security with Pixels
| and iPhones.
|
| We automate a huge portion of the work via
| https://github.com/GrapheneOS/adevtool. We do a GrapheneOS
| build with it and it outputs state you can see in
| https://github.com/GrapheneOS/vendor_state which is then used
| to automatically figure out all of the missing overlays,
| SELinux policy, firmware files, etc. When we have our own
| devices in partnership with an OEM we won't need to use
| adevtool. We can borrow a lot from Pixels for those devices
| though.
|
| Pixels are very similar to each other, which does make things
| simpler. The entire kernel source tree is identical for 6th,
| 7th, 8th and 9th generation Pixels. They all use the Linux
| 6.1 long term support branch on bare metal and the Linux 6.6
| branch for on-device virtual machines. They'll likely advance
| to new Linux kernel branches together rather than ending up
| very split across different ones as they were in the past.
| That makes things easier for us.
|
| Pixels also share most of the same drivers for the SoC and
| lots of other drivers. Those drivers support the different
| generations of hardware with the same codebase for the most
| part. There are still 6 different Wi-Fi/Bluetooth drivers
| across them but 5 of those are variations of a very similar
| Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate
| Qualcomm Atheros driver (Pixel 7a).
|
| We have various hardware-based hardening features such as our
| hardware-based disabling of the USB-C port with variations
| across different hardware generations
| (https://grapheneos.org/features#usb-c-port-and-pogo-pins-
| con...) and similar features. Our exploit protection features
| also uncover lots of memory corruption bugs across devices in
| their drivers. We do have a lot of device-specific work
| fixing uncovered bugs. Hardware memory tagging in particular
| finds nearly every heap memory corruption bug occurring
| during regular use including out-of-bound reads so that finds
| a lot of bugs we need to handle. Many of the bugs we find
| with hardware memory tagging and other memory corruption
| exploit protections are in drivers or the portable Bluetooth
| software stack which is thankfully one of the components
| Android is currently gradually rewriting in Rust along with
| the media stack.
|
| If we supported a device with much different drivers, there
| wouldn't be much work to deal with that directly but enabling
| our features like our hardware memory tagging support would
| require fixing a bunch of memory corruption bugs occurring
| during regular use across it. Supporting other Android
| devices with the Android Open Source Project is easy.
| Supporting them with GrapheneOS is significantly harder due
| to various hardening features needing integration at a low
| level along with others uncovering a lot of latent bugs which
| were occurring but not being noticed most of the time. The
| ones which get noticed often due to breaking things get
| fixed, but many latent memory corruption bugs remain there
| unless the OEM heavily tests with HWASan or MTE themselves,
| which is unlikely. Pixels are tested with HWASan and MTE by
| Google but yet we still have to fix a lot ourselves largely
| because testing them in a device farm is different than users
| actually using them with assorted Bluetooth accessories, etc.
| haukem wrote:
| Thank you for all the insights.
|
| Nice to know that all supported Pixel phones are not only
| on the same kernel version, but actually are build fro the
| same source tree now.
|
| Do you also contribute your fixes back to the upstream
| projects like the upstream Linux kernel, AOSP or Google?
|
| Many of the security features you are using are already
| included in AOSP, why does Google not activate them by
| default? Do they have a different balancing of performance,
| stability and compatibility on the one side and security on
| the other? I understand that Google has a different view on
| privacy for business reasons.
| crossroadsguy wrote:
| Reminds me of iOS and iDevices and how even after months they
| keep stabilising and then they fail to stabilise and then
| they release the next version after a year with all those
| bugs intact and accumulated. In this case that OS is
| literally made for only those devices and vice-versa, in iron
| claw control of one control freak corporation that has a net
| worth more than GDPs many countries would nuke for.
|
| Let's contrast that with a pure community led effort,
| motivated by freedom, privacy, and safety, that neither
| controls the OS nor the devices. It's not what I tried to
| saltily explain above.
|
| Respectfully, I hope that sunk in.
| CartwheelLinux wrote:
| Incredibly fast.
|
| While the 9a and 9 pro are very similar, for comunity based
| development this is substantial.
|
| I am often very critial, but I must give props to the grapeneos
| team.
| tripdout wrote:
| I think a lot of the work is in new device bringup, and given
| that they can start from official Pixel trees, it shouldn't be
| too much work to adapt them for whatever GrapheneOS-specific
| build processes they have, and then I'm assuming the rest of
| the GrapheneOS customizations are framework side which should
| be device agnostic. I guess they could have kernel changes for
| hardening, but not sure how easy or hard porting those would be
| - is the Pixel 9 series on a newer kernel version than say the
| Pixel 8?
| strcat wrote:
| GrapheneOS has various features requiring hardware
| integration. Our hardening features also uncover bugs across
| the code especially in drivers, especially the hardware
| memory tagging integration in our hardened_malloc project and
| the standard Linux kernel hardware memory tagging support we
| use in the kernel. Pixels are very similar to each other
| though so this work is largely but not entirely done for
| them.
|
| Adding new Pixels including whole new generations tends to be
| quite easy. When we still supported Snapdragon Pixels in the
| official GrapheneOS branch, it would have been fairly easy to
| add support for a theoretical Sony or Motorola device meeting
| our security requirements (https://grapheneos.org/faq#future-
| devices). Now that we don't have a Snapdragon device, we'd
| need to deal with fixing or working around all the bugs
| uncovered in Snapdragon drivers, integrating support for the
| USB-C controller into our USB-C port control feature
| (https://grapheneos.org/features#usb-c-port-and-pogo-pins-
| con...), adding back our code for coercing Qualcomm XTRA into
| being privacy respecting, etc. Snapdragon doesn't have memory
| tagging yet like Tensor (and recent flagship Exynos/MediaTek
| now), but pretending it did, we'd need to solve a lot of
| issues uncovered by it unless Qualcomm and the device OEM
| heavily tested with it.
|
| See https://news.ycombinator.com/item?id=43669913 for more
| info including about kernels. 6th, 7th, 8th and 9th
| generation Pixels share the same Linux 6.1 source tree and
| kernel drivers since Android 15 QPR2 in March 2025.
|
| Pixel 9a is still using a branch of Android 15 QPR1 due to
| how device launches work so most of the work involved taking
| our last Android 15 QPR1 release from early March and
| rebasing it onto the Pixel 9a device branch tag where they
| forked off from an earlier Android 15 QPR1 release and
| backported current security patches to it. We then had to
| backport our changes since early March. The device branch
| will go away in a couple months and it will be on the same
| branch as everything else until it's end-of-life as usual. We
| could spend more time to integrate it into our main Android
| 15 QPR2 based branch ourselves but we can also simply wait a
| couple months. As an earlier example, the Pixel 8a was
| released in May 2024 based on Android 14 QPR1 rather than the
| current Android 14 QPR2. It was incorporated into mainline
| Android 14 QPR3 in June only a few weeks later. We know
| Android 16 is already going to deal with this so spending our
| time on this instead of implementing new privacy, security,
| usability and compatibility improvements would be a waste.
| NoahKAndrews wrote:
| Off-topic, but as someone who's followed your work for a
| long time, it's cool to see you posting again! I hope
| you're doing better these days.
| edm0nd wrote:
| Thank you for all the work on GrapheneOS that is done.
|
| I got it on a P7P and love it.
| fph wrote:
| Am I supposed to trust security information coming from a
| user named strcat? /s
|
| Quick, someone named strcat_s or strncat correct them!
| matheusmoreira wrote:
| Thank you for your work and the interesting and insightful
| comments. I've learned a lot from you.
|
| I wish it was feasible to run GrapheneOS on more devices.
| For some reason, Google seems to be incapable of selling
| Pixels world wide.
| rzk wrote:
| Thank you for all the hard work you do on GrapheneOS.
| mixmastamyk wrote:
| Anyone know why drivers in this OS can't be ported to Linux, so
| it could support newer phones as well?
| strcat wrote:
| Android Open Source Project and operating systems based on it
| like GrapheneOS are Linux distributions. The kernel drivers
| are Linux kernel drivers. The userspace drivers are part of
| Android's Treble hardware abstraction layer providing
| forwards compatibility with future Android releases and
| SELinux-based sandboxing with the drivers split up into
| isolated processes. Most of the driver complexity is in
| userspace with most kernel drivers acting as shims between
| the isolated drivers and the hardware. It's done that way for
| practical reasons on Android but it's good for security.
|
| Treble's compatibility system isn't very relevant to us right
| now. There's a new Android release every month: a monthly,
| quarterly or yearly release. The devices we currently support
| (Pixels) receive each of these updates officially. Most
| Android devices do not get the monthly or quarterly updates,
| only the yearly ones. Other devices rely on partial backports
| of security patches (Android Security Bulletins) to an
| initial release, which are provided for ~3-4 years after the
| initial yearly release. If we supported typical Android
| devices with that situation, then we'd at least partially
| rely on Treble to provide the latest OS version. Pixels are
| currently the only devices meeting our hardware security
| requirements listed at https://grapheneos.org/faq#future-
| devices. Having proper updates for 7 years from launch is
| just part of that, most of the requirements are for hardware-
| based security features like the secure element features,
| hardware memory tagging, pointer authentication, USB
| controller support for blocking new connections and disabling
| USB data, etc.
|
| GrapheneOS uses the 6.1 and 6.6 long term support branches of
| the Linux kernel with 6.12 as the next one that's likely
| going to be used to replace 6.6 for on-device virtual
| machines and the emulator with Android 16.
| yjftsjthsd-h wrote:
| > The kernel drivers are Linux kernel drivers.
|
| But they're drivers that are not upstreamed and which
| therefore make it hard to move to a newer kernel, right?
| strcat wrote:
| > But they're drivers that are not upstreamed and which
| therefore make it hard to move to a newer kernel, right?
|
| It's no harder than it would be dealing with them if they
| were upstream. Google ports all the Pixel drivers to
| newer LTS branches and a recent branch of the mainline
| kernel themselves.
|
| With the recent Android 15 QPR2 release last month (March
| 2025), 6th/7th generation Pixels moved from the 5.10
| branch to 6.1 and 8th generation Pixels moved from 5.15
| to 6.1. 6th, 7th, 8th and 9th generation Pixels share the
| same kernel and kernel driver source tree now. They have
| them ported to 6.6 and mainline kernels too, it's just
| not ready to ship yet. 6.6 is used for virtual machines
| run on the devices and the emulator. 6.12 will be what's
| used for Android 16.
|
| You can see at
| https://android.googlesource.com/kernel/google-
| modules/aoc/+... that they still port the 6th gen Pixel
| drivers to newer mainline kernels. They're ported to 6.13
| and probably moving along to 6.14 soon. It doesn't mean
| they're going to ship them. Only LTS branches make sense
| to ship and they need long term stabilization first. The
| likely model is going to become ~12 months of
| stabilization and then ~12 months of usage since LTS
| kernel branches are moving back to 2 years of support. It
| was essentially increased to 6 years for 6th gen Pixels
| having 5 years of support, but they moved along to
| upgrading to newer LTS branches for 8th gen Pixels moving
| to 7 years of support. Greg KH works for and with Google
| on the LTS kernel maintenance / testing so it's actually
| quite Android centric rather than server centric. Long
| term support desktop/server distributions historically
| maintain their own LTS branches so they're not really the
| ones involved in that for the most part.
|
| Drivers that are upstream don't actually get much free
| maintenance and testing. People making API changes
| blindly update the drivers without testing them. They get
| lots of updates and refactoring, but not much ongoing
| maintenance. Maintainers still need to deal with it. It's
| very common for upstream drivers to continuously regress.
| They can go a long time without actually working properly
| across releases due to how few people use them. Most
| people are using distributions with frozen package
| versions like Debian, not a rolling, and people using a
| rolling release like Arch Linux can use an LTS kernel
| branch to avoid a lot of this. The drivers for embedded
| hardware and things not used much by enthusiasts on
| desktops often break without it being noticed.
|
| Android made a Generic Kernel Image system with ABI
| stability for drivers which does not benefit Pixels
| because they update the drivers to match the latest GKI
| kernel they ship. Similarly, Pixels don't really need the
| Treble HAL ABI forwards compatibility because they update
| all the vendor code to the latest monthly, quarterly and
| yearly OS releases anyway. It's helpful that drivers
| don't need to add all the new standard features to keep
| providing working support for new OS versions though.
| It's nice having it all nearly all neatly standardized
| and stable. We like Treble because of the sandboxing. The
| forwards compatibility benefits are largely unrealized
| because the vendors needing it aren't doing updates much
| anyway. Qualcomm is moving to 8 years of full update
| support for Snapdragon to partially match Pixels anyway.
| yjftsjthsd-h wrote:
| Two thoughts (and a half, I suppose).
|
| First: I did momentarily forget that you're only
| targeting Pixel devices that are actively getting updates
| from Google. In light of that, so long as Google stays on
| top of maintaining those devices, yeah in your case
| that's probably fine. I'm somewhat accustomed to less
| responsible vendors and a lot of my views are shaped by
| that.
|
| That said, I'm not wholly convinced that Google's
| downstream kernels are as good as running from upstream.
| AFAICT, for example, GrapheneOS is currently shipping a
| kernel for the Pixel 6 that's 3 minor versions behind.
| Trying to track things through the Android development
| process is... unintuitive... to me, so forgive me if I've
| missed something... If I go to
| https://github.com/GrapheneOS/device_google_raviole-
| kernels_... , grab a .ko file that shows as being
| committed yesterday, and run modinfo on it, I get a
| version of 6.1.131 which https://cdn.kernel.org/pub/linux
| /kernel/v6.x/ChangeLog-6.1.1... says is from March 13 and
| has been superseded by 6.1.134 at this writing (from
| checking https://www.kernel.org/ ). Contrast
| https://archlinux.org/packages/core/x86_64/linux-lts/
| which says that Arch's LTS kernel is at 6.12.23 which
| _is_ the latest of that line. EDIT: Actually, the much
| better comparison is that Debian 12 is shipping 6.1.133
| according to
| https://packages.debian.org/stable/kernel/linux-image-
| arm64 now. So the super stable slow moving distro is in
| fact still ahead of Android, even slightly lagging as it
| is.
|
| As to breakage/testing... Yes, someone has to test new
| versions. Ideally that'd be a CI farm flashing and
| testing devices, but I appreciate that it's not exactly a
| trivial problem. Nonetheless, if that results in Graphene
| not shipping the latest bugfixes, I feel like that's an
| extremely awkward position to be in.
| strcat wrote:
| Linux 6.12 is not better for security than Linux 6.1 or
| Linux 6.6. It doesn't work that way. Newer kernels have
| substantially more attack surface and complexity. They
| also have tons of new bugs. Bug density is far higher in
| new or recently changed code. Bug density drops over
| time. However, backporting patches gets increasingly less
| complete for the older branches. There's a balance
| between the new and older branches. 6.12 is far too new
| to be a reasonable choice. Google already ported Pixels
| to Linux 6.12, etc. It's not what is shipped because it's
| full of serious bugs. Separately from that, if you
| believe using an LTS release and shipping the latest
| revisions means you avoid regularly having serious
| regressions, that's very wrong with the Linux kernel.
|
| Pixels only recently started moving to new LTS releases
| and will likely be moving to a new LTS release each year
| going forward. Moving the older generations to 6.1 to
| match current devices was done in March 2025. They'll
| likely move along together to a new branch each year
| going forward.
|
| Linux kernel LTS revisions are nothing like LTS revisions
| of most other projects. They're largely untested patches
| blindly applied by the LTS maintainers based on patches
| to mainline being marked for stable backports. If the
| patches apply cleanly, they ship. If they don't apply
| cleanly, they largely don't ship. Whether it works is an
| open question.
|
| > GrapheneOS is currently shipping a kernel for the Pixel
| 6 that's 3 minor versions behind
|
| That's not quite right.
|
| We're shipping the latest Linux 6.1 and Linux 6.6 GKI LTS
| branch releases from Greg KH. They're currently in
| between 2 upstream revisions upstream, not on a specific
| one. The devices all use both 6.1 and 6.6, not just 6.1.
| They use 6.1 for bare metal and 6.6 for virtual machines.
| Even the Pixel 6 has been ported to 6.13 by Google but
| that doesn't mean that's a stable enough kernel ready to
| ship.
|
| The Android kernel branches also have a bunch of
| backports not included in the kernel.org LTS releases,
| including security patches and improvements they decided
| were important. Google does their own backporting and
| fixes in the GKI branch and Greg KH merges those into the
| GKI LTS branch. The kernel branch we use is the
| combination of the Google GKI backporting/fixes with the
| kernel.org backporting. The kernel.org LTS releases are
| far messier than you realize, and combining these things
| is messy too.
|
| Linux LTS kernels are not very well tested and have tons
| of regressions. Quickly updating to the new LTS versions
| is problematic and we regularly encounter major
| regressions, especially in certain areas like f2fs and
| USB. We still update right away to the new GKI LTS
| versions. We're currently on the latest GKI LTS releases
| for each branch.
|
| You'd have to ask Greg KH why there are still delays
| despite Google supporting it. It still seems to be him
| doing most of the kernel.org LTS and also GKI LTS work by
| himself, without nearly as much review or help by others
| as you would think. This is also tied into the severe
| regressions regularly happening with the LTS releases.
| Those can be security regressions too. Immediately
| updating to them is not necessarily a great idea with how
| much goes wrong at the moment.
|
| They unfortunately sometimes lag behind the kernel.org
| releases. We used to merge the latest upstream kernel.org
| LTS releases ourselves but Greg KH convinced us we don't
| need to do that anymore and should just use the GKI LTS
| branch instead. We're not completely happy with it since
| it's not fully kept in sync but we're using our resources
| elsewhere at the moment.
|
| > Actually, the much better comparison is that Debian 12
| is shipping 6.1.133 according to
| https://packages.debian.org/stable/kernel/linux-image-
| arm64 now. So the super stable slow moving distro is in
| fact still ahead of Android, even slightly lagging as it
| is.
|
| Debian is usually further behind than Greg KH's GKI LTS
| branch. Comparing at a snapshot in time doesn't mean
| much. GKI LTS branch should really be kept in sync but
| the GKI ABI stability system makes maintenance hard and
| is entirely worthless for Pixels. We would prefer if the
| whole GKI system did not exist. For Pixels, the kernel
| image and all the drivers are built with the same kernel
| source tree for Pixels so the whole system for driver ABI
| compatibility is just making things more complex and
| worse.
|
| > As to breakage/testing... Yes, someone has to test new
| versions. Ideally that'd be a CI farm flashing and
| testing devices, but I appreciate that it's not exactly a
| trivial problem. Nonetheless, if that results in Graphene
| not shipping the latest bugfixes, I feel like that's an
| extremely awkward position to be in.
|
| We do heavily test them. Our community helps with it. We
| OFTEN find regressions in the new LTS kernels. It often
| takes months before the issues we find and work around
| get fixed upstream. It's worth noting that due to
| mistreatment we've largely stopped helping them except
| for firmware, hardware or things we don't want to
| maintain downstream for some reason. It would be better
| if everyone collaborated on maintaining LTS kernels but
| instead it's largely 1 person and a couple others doing
| it with support from Google for testing, etc.
| yjftsjthsd-h wrote:
| Right, no, I wasn't particularly objecting to 6.1, I was
| pointing at the patch level on it. I would personally
| take [quickly checks kernel.org] 5.15.180 (latest 5.15)
| over 6.1.130 (not-latest 6.1), because I'm more concerned
| with bugfixes than feature releases at this point. If the
| GKI LTSs are backporting fixes, that may well cover it,
| although that starts to veer into making me nervous
| because I rather agree with
|
| > Linux kernel LTS revisions are nothing like LTS
| revisions of most other projects. They're largely
| untested patches blindly applied by the LTS maintainers
| based on patches to mainline being marked for stable
| backports. If the patches apply cleanly, they ship. If
| they don't apply cleanly, they largely don't ship.
| Whether it works is an open question.
|
| I'm also not super fond of frankenkernels. And... I'm
| confused how you feel about them? If backports suck,
| shouldn't you _want_ to be chasing the very bleeding
| edge? I wasn 't originally intending to argue that
| everything _had_ to ride the very latest and greatest,
| but if backporting is inherently fragile and bug-prone,
| shouldn 't you want to be on the very latest stable
| version (so as of this writing, 6.14.2)?
| strcat wrote:
| We want to be on an LTS branch, but we'd prefer to be on
| a newer LTS branch. We would currently want to be on 6.6
| with a near future move to 6.12 once it was stabilized
| enough. However, we would much rather be on what Google
| is heavily testing than using a kernel they're not using
| on their CI infrastructure and production devices.
|
| Pixels moving 6th, 7th and 8th gen devices to 6.1
| happened in March 2025. It's the first time they've moved
| to new LTS branches. It's likely going to move to using a
| newer LTS release where it would currently be using 6.6
| and then moving to 6.12 after the next one comes out. We
| expect they move to having around a year to stabilize the
| new LTS and then use it for around a year before moving
| to the next. That fits nicely into the new 2 year
| lifespan for LTS kernels. This is a transition period.
| Once the longer than 2 year LTS kernels are gone, the
| quality of the LTS kernels will rise because there won't
| be as many to maintain. There are currently too many
| combined with too few people working on it. Greg KH
| having to handle both the kernel.org LTS and GKI LTS
| doing a huge portion of the work is clearly a problem.
| We'd also like to see the end of GKI ABI stability but
| that's highly unlikely. Yearly moves to new LTS kernels
| will at least make it a lot better.
|
| > I would personally take [quickly checks kernel.org]
| 5.15.180 (latest 5.15) over 6.1.130 (not-latest 6.1)
|
| Latest 5.15 has far fewer fixes backported for the same
| time periods than 6.1. The missing fixes in 5.15 are far
| more than a couple minor revisions. Similarly, 6.6 has
| more than 6.1 for the same time period and 6.12 has more
| than 6.6.
|
| > And... I'm confused how you feel about them? If
| backports suck, shouldn't you want to be chasing the very
| bleeding edge? I wasn't originally intending to argue
| that everything had to ride the very latest and greatest,
| but if backporting is inherently fragile and bug-prone,
| shouldn't you want to be on the very latest stable
| version (so as of this writing, 6.14.2)?
|
| Linux kernel code quality, review and testing is quite
| low. The bleeding edge kernels are nearly unusable in
| production for this use case (users running all kinds of
| software, using all kinds of different Bluetooth, USB,
| etc. accessories and so on while caring deeply about
| battery life) and have a ton of newly added security bugs
| which aren't found and fixed yet. We think that's a much
| bigger issue. We happily use Arch Linux for a lot of
| stuff but we use the LTS kernel package which is 6.12 at
| the moment.
|
| If LTS quality was increased substantially, then we'd
| want to be on the latest LTS branch a while after the
| initial release, i.e. 6.12.15+ or so. However, at the
| moment, some serious regressions take them so long to
| find that it's still too new. We have high stability
| requirements where we can't have niche USB functionality,
| Bluetooth, video recording, etc. functionality
| regressing. The out-of-tree drivers are an area we don't
| have as much pain with since they're nearly all made for
| Exynos / Pixels and the drivers from the vendors so
| changes actually get tested well. The regressions are in
| the upstream code. More stuff coming from upstream would
| make LTS updates more, not less, painful, other than the
| GKI ABI stability nonsense we don't want.
| mixmastamyk wrote:
| Ton of information here. But was hoping to find out how
| mobile Linux distros (mobian, postmarket, pureos, new
| ones) could support newer phones, like these Pixels. I
| still don't know after reading this thread. :-D
|
| I don't want to use Android, I want to use Linux and
| Phosh or similar. But so far, the supported hardware is
| junk.
| strcat wrote:
| GrapheneOS is a mobile Linux distribution. It's not
| systemd and GNOME which makes it a Linux distribution but
| rather the Linux kernel. There's nothing stopping people
| from running a traditional desktop Linux software stack
| on the same hardware we support. That doesn't interest us
| since it would be a massive privacy and security
| regression from the Android Open Source Project. It would
| also give a lot of usability, robustness and the huge
| mobile app ecosystem including a large number of open
| source mobile apps.
|
| The Linux kernel is increasingly the elephant in the room
| when it comes to security and hasn't experienced anything
| like the massive progress made in Android's security in
| userspace. Piling on many more exploit mitigations to the
| Linux kernel won't really change this. We need to do a
| lot more work on it than we already do.
|
| GrapheneOS has hardware virtualization support, which is
| going to be one of the ways to avoid depending so much on
| the Linux kernel's fragile security. The main usage for
| it in GrapheneOS will be running nested GrapheneOS
| instances for better sandboxing rather than running other
| operating systems. Android supports using the
| virtualization support to run other operating systems via
| the Terminal app and we have support for GUI
| applications, speaker, microphone and opt-in GPU
| acceleration backported to the Terminal app. The main use
| case for that app will be running desktop applications
| from other operating systems for the desktop mode.
| Windows 11 support would be a compelling addition to it
| and we may implement that in the next year or so.
| charcircuit wrote:
| Having the kernel that is being shipped to customers be
| less than 1 month behind is not that bad.
|
| >So the super stable slow moving distro
|
| Slow isn't referring to the speed Debian takes for hot
| fixes. It is referring to how long Debian stays hot
| fixing packages over updating to the latest version.
| speed_spread wrote:
| Sounds like Android is making a microkernel out of Linux.
| strcat wrote:
| There are some huge drivers from companies like Broadcom
| and Qualcomm. There's still a massive amount of kernel
| driver code along with the massive amount of core kernel
| code. Android is the main driving force behind the push
| for Rust for Linux kernel drivers because Google wants
| all these SoC and device drivers to start being written
| in Rust for security reasons but also for stability too.
| Driver memory corruption bugs are a huge source of both
| security and stability issues. A majority of new code in
| Android releases since Android 13 has been in memory safe
| languages. The Linux kernel is increasingly the elephant
| in the room with the monolithic kernel driver (zero
| isolation / sandboxing within the kernel) combined with
| memory unsafety. It's largely the opposite of Android's
| extensive work to improve security in userspace. They've
| worked hard on getting exploit mitigations into the
| kernel but those tend to be much weaker than they are in
| a lot of userspace (browser renderer processes have
| similar issues).
| rollcat wrote:
| For entire classes of applications, you can treat Linux
| as a black box. Things like syscalls, /proc & /sys, are
| all incredibly stable. So that's what Go does with its
| syscall package; it completely sidesteps libc, ld.so, and
| whenever it can, it just produces static builds - at
| least on Linux.
|
| They tried to get away with it on OpenBSD, macOS, etc and
| got their hand chewed off.
| hedora wrote:
| There are a few reasons I avoid Go, and their syscall
| pacakge is on the list. It breaks a bunch of tooling that
| requires LD_PRELOAD or static linker interposition. (One
| example: Interposing on the clock to test timeout logic.)
|
| I wish they had an option that just used libc. Maybe,
| someday someone will add a target architecture/port that
| just uses posix. I'd prefer that in Linux too.
| kowabungalow wrote:
| Also, this is the first pixel after this announcement:
|
| https://news.ycombinator.com/item?id=43485950
| codethief wrote:
| Oh wow, how did I miss that! If strcat / Daniel Micay happens
| to pass by: How much will this impact future development of
| GrapheneO?
| strcat wrote:
| The changes are overstated in the media and has little
| impact on it. See
| https://news.ycombinator.com/item?id=43674145. We would
| benefit a lot from early access to quarterly and yearly
| releases but that hasn't ever been public and the AOSP main
| branch only provided the most recent changes for a few
| components, and not any of the ones we actually need most.
| codethief wrote:
| Thanks!
| strcat wrote:
| The changes are overstated and it really changes very little
| for GrapheneOS. See
| https://discuss.grapheneos.org/d/21315-explanation-of-
| recent....
|
| Android already published the full source code for Stable
| releases but barely anything for Beta releases. They didn't
| publish anything for upcoming releases with support for new
| devices. AOSP main branch received most changes through the
| Stable releases being merged into it. Most components were
| developed internally. Certain components were developed
| publicly in AOSP so they had to repeatedly merge back and
| forth between the internal and public main branches.
|
| GrapheneOS would benefit from having early access to the
| monthly, quarterly and yearly releases as Android OEM
| partners do. The only benefit of having access to the main
| development branch would be the ability to backport more
| fixes than they do along with doing it earlier. We
| occasionally backported fixes from AOSP main for the few
| components developed publicly through it, which is what's
| going to be mostly going away. It was a big help to us as
| access to the upcoming quarterly and yearly releases would
| be. Monthly updates are too small for it to really matter but
| it'd still help.
|
| Also worth noting the monthly security patch backports
| (Android Security Bulletins) are a separate thing from the
| new OS release each month. Those are backports of many of the
| High and Critical severity patches to older Android versions,
| often a month or two after they were released in the actual
| OS releases each month which are the monthly, quarterly and
| yearly releases (it's one of the 3 each month, with 3
| quarterly releases and 1 yearly release per year although
| Android 16 is coming earlier this year instead of a 3rd
| quarterly release).
| OsrsNeedsf2P wrote:
| I installed GrapheneOS on my Pixel 4a after Google deleted the
| battery life[0], and while the initial move was frustrating with
| things not working, I've adapted and have a nice feeling of
| security while using my device again. It feels like it's mine,
| and I don't have to worry about who will spy on me or rug-pull me
| next.
|
| [0] https://grapheneos.social/@GrapheneOS/113917226566692707
| jeffbee wrote:
| > deleted the battery life[0]
|
| Such a bizarre phenomenon to me that people are still griping
| about a software update that stops a 4-year-old battery from
| detonating when the same company will also fix the phone for
| free or just hand you $50 if you prefer that.
| broodbucket wrote:
| I don't have any idea what the situation is here and whether
| it's as black and white as you paint it, but regardless,
| surely something as significant as this should be presented
| to the user as an option rather than the manufacturer
| deciding for you that your phone that you own and paid for
| should now be unusable?
| gpm wrote:
| > or just hand you $50 if you prefer that.
|
| Not really just handing it to you
| https://arstechnica.com/gadgets/2025/03/how-google-nerfed-
| my...
| tgsovlerkhgsel wrote:
| The fixing offer is only valid in some locations, would
| require you to be without your phone for some time, and since
| Android still doesn't have anything that would be considered
| working backup and restore, I can't imagine many people being
| comfortable mailing their phone out for a replacement.
|
| The $50 "cash" offer came with so many downsides that just
| ignoring it would be the smarter choice for anyone who values
| their time (someone already provided a link).
| mmmpetrichor wrote:
| They never ack'd the reason why they did it. My wife's phone
| was basically bricked, and the google offer for "free fix"
| was functionally worthless because the contracted companies
| wouldn't repair it. See many articles online (including ars
| technica editor who personally was screwed).
| Teever wrote:
| I just bought a replacement battery from ifixit and replaced
| it myself as the original battery was worn out only to now
| suddenly have garbage battery life on a brand new battery for
| no good reason.
|
| I doubt that they'll give me any sort of money or do repairs
| on a phone that I opened up.
|
| It's frustrating as I thought I would be able to get several
| more years of life out of this phone.
| Spunkie wrote:
| I was never even notified for my 4a and when I try to check
| it's eligibility it simply says my pixel 4a "is not eligible
| for a repair, cash payment, or discount." without any
| additional information.
|
| Does this mean my pixel 4a battery was unaffected for some
| reason... or simply that the lawyers managed to weasel out of
| paying 100% of active pixel 4a owners back and my phone is
| still dangerous or degraded? -\\_(tsu)_/-
| kwk1 wrote:
| Yes, not all 4a's were affected. Of two of mine, one was
| eligible, but the other was not.
| tengbretson wrote:
| Of all the selling points for GrapheneOS, I don't think battery
| life is one I'd highlight. Their Google Play services shim
| smokes my battery. Like 20-30% discharge while overnight idle
| kind of bad.
| strcat wrote:
| That's not at all normal. Sandboxed Google Play doesn't
| consume more batter than privileged Google Play in a standard
| Google Mobiles Services device. It indicates something is
| very wrong with your setup.
| tengbretson wrote:
| Its definitely pretty close to normal. Battery drain is
| probably the top mentioned drawback in any online post
| discussing GrapheneOS.
| strcat wrote:
| No, it's not at all normal. Here's a poll someone did on
| Mastodon with 124 anonymous responses from our community:
|
| https://23.social/@mj1982/114210416377875387
|
| 54% Battery consumption is lower under GrapheneOS
|
| 13% Battery consumption is lower under stock Android
|
| 33% Can't tell the difference.
|
| For users with a single profile with sandboxed Google
| Play installed before other apps, it should be very
| similar to the stock Pixel OS if you installed the dozens
| of Google apps they bundle on GrapheneOS and disable the
| various privileged apps they integrate which aren't
| usable on GrapheneOS. The stock OS drains more power with
| a typical simple setup because it has so much more
| installed and running. If you make it similar, it's
| nearly the same. If you use a more complex setup with
| multiple profiles and multiple push implementations on
| GrapheneOS, that's going to use more power. It still
| shouldn't drain nearly as much as you said above without
| something seriously wrong with the setup.
|
| It's very easy to make battery life much worse. Using
| multiple push messaging implementations simultaneously is
| inefficient. As an example, using sandboxed Google Play
| in your Owner user, sandboxed Google Play in a work
| profile and a Private Space without it with various apps
| doing their own push would of course be far less
| efficient than a single Firebase Cloud Messaging push
| connection shared across the entire device. Having 2
| installations of sandboxed Google Play you always keep
| running would be less efficient than privileged Google
| Play. Regular privileged Google Play shares the same
| processes and connections across profiles since it's
| built deeply into the OS and is implemented that way for
| efficiency like many OS services. If you compare having a
| single privileged Google Play vs. multiple sandboxed
| Google Play alongside apps doing their own push, of
| course privileged Google Play would be more efficient.
| You can use GrapheneOS with a similarly efficient setup
| and battery life will not be worse. You likely just have
| an inefficient setup. It can still be hard to narrow down
| what's really draining battery usage despite Android's
| battery stats getting much better over time.
| hedora wrote:
| To back up your survey with a reproducible experiment:
|
| On my 6 pro, I got 2x advertised battery life until I
| installed one copy of Google Play services. Then I got
| advertised battery life.
|
| It should be easy enough to uninstall Google's stuff for
| a week and measure battery drain, then put it back.
|
| Even with it though, I wasn't losing 30% overnight.
| There's probably some other problem. Maybe wipe +
| reinstall, then try with and without the 24/7
| surveillance daemons?
| blablabla123 wrote:
| I know, I had the problem when I got the Pixel. Already
| with the stock Android and then when installing Graphene.
| It took one or two weeks of tweaking until the battery
| life was on par with LineageOS. Not sure if I'd be able
| to reproduce it, but I think a combination of display
| settings and stand-by/background services. It's a thin
| line though, also making sure that Whatsapp notifications
| still work.
| blablabla123 wrote:
| Yeah it's really great, before switching to GrapheneOS I used
| LineageOS for years so battery life is already good in that
| case. But the whole access control, and checking every few
| months which apps are hardly used is just super practical. I
| don't do online banking on my phone though, I guess for people
| who do it's not feasible. The only thing I don't like is that
| it only works with Google Pixels
| sureglymop wrote:
| Online banking (anecdotally) works great, though may use the
| sandboxed google play services. At least here in Switzerland
| with Swiss banking apps I've never had issues with it.
|
| I would recommend people to install the play services and
| play store in the main profile. Then, install apps in the
| main profile too but remove all permissions and abilities,
| restrict and disable them. After that, enable them in a
| "banking" profile. One can then selectively enable and
| disable the play store to update these apps which propagate
| to the other profiles. The disabled apps are still updated
| normally by the play store.
|
| I do believe that they are working on a feature to limit app
| intercommunication in a similar vein as the other scopes.
| This would be cool because it would allow one to allow "point
| to point" communication of certain apps with the play
| services but otherwise restrict them. Though I don't know the
| state of development for this feature.
| blissofbeing wrote:
| I would like to root, but I like my Google pay.
| strcat wrote:
| In many countries, there are tap-to-pay options permitting
| using GrapheneOS including Curve Pay and also the standard used
| by many European banks. US lacks an option but will hopefully
| get Curve Pay soon. Garmin Pay and Android Pay can be used via
| a Garmin or Android smart watch so that's what some of our US
| users do. Pixel Watch works fine paired with GrapheneOS with
| sandboxed Google Play.
|
| Note installing GrapheneOS doesn't involve rooting. Installing
| it uses an officially supported process and doesn't void the
| warranty. It preserves the standard security model and
| massively improves privacy and security on top of that
| (https://grapheneos.org/features). It's largely the opposite of
| most other alternative Android-based operating systems are
| doing with security.
| rollcat wrote:
| Genuinely curious, why do you need root access on your EDC
| phone? Personally I would stick with a throwaway for
| experimentation, so I'm curious about your motivation.
| blissofbeing wrote:
| To do things like turn off and on airplane mode when certain
| conditions are met with automate https://play.google.com/stor
| e/apps/details?id=com.llamalab.a... for example. There are
| work arounds but having a rooted phone is the easiest.
| rollcat wrote:
| I see. I get this out of the box on iOS via Shortcuts &
| automations, it's a part of the base OS and honestly pretty
| powerful. I get it that iOS is not for everyone, but at the
| very least it's a proof and an incentive for Android to
| implement this as well.
| adikso wrote:
| GrapheneOS != root. You don't have root when running GrapheneOS
| - it would be a security risk.
| privacyking wrote:
| What's the next big feature being implemented? The last was the
| network location one.
| strcat wrote:
| Feature development is going to be a bit slower for at least a
| couple months due to several of our core developers being
| temporarily unavailable.
|
| We're actively working on several major improvements including
| automatic generation of random passphrases and PINs, further
| improvements to VPN lockdown mode, per-app toggles for access
| to clipboard content from other apps to go beyond the existing
| restriction of only the focused app and keyboard being able to
| read it, etc.
|
| You can look through https://github.com/GrapheneOS/os-issue-
| tracker/issues with the Feature type and enhancement label.
| GitHub unfortunately didn't provide a way to automatically
| migrate the older enhancement label to Feature type. We could
| use the API for it but haven't yet so you'll need to use both
| the old and new methods.
| neodypsis wrote:
| Is there a GrapheneOS image for use with Android Emulator? I want
| to test an app on it but got no physical Pixel device.
| strcat wrote:
| Many apps won't work in the Android emulator. Banking apps,
| etc. will detect it and ban it. Far more apps will ban the
| emulator than will ban GrapheneOS. We aren't aware of an app
| which would work in the Android emulator with a standard
| emulator image containing Google Play but wouldn't work with
| GrapheneOS. Nearly all Android apps work on GrapheneOS. It's
| nearly entirely just the subset which ban using any non-stock
| OS with the Play Integrity API which can't be used. We
| convinced a few banking apps to start allowing GrapheneOS via
| hardware attestation but the pace of banking apps integrating
| the Play Integrity API is unfortunately quite a bit faster than
| the pace we're convincing apps to support it after they do
| that.
|
| You can build it for the emulator. It's straightforward to do,
| but it requires a lot of disk space and it will take around
| 40-60 minutes on a high end desktop CPU like a Ryzen 9950X. We
| don't publish official releases for the emulator at the moment
| because it's not intended for production use and isn't really a
| good experience to use. We could start doing it, but it'd add
| some extra work and we'd be concerned about people
| misinterpreting what it's meant to provide. Emulator builds
| don't have the regular security model intact or OS updates,
| etc.
| neodypsis wrote:
| Thanks for the reply, yeah, my interest was to test
| compatibility when we add support for Play Integrity to our
| app.
| strcat wrote:
| Please read https://grapheneos.org/articles/attestation-
| compatibility-gu.... It's possible to support GrapheneOS by
| using the Android hardware attestation API either as an
| alternative to the Play Integrity API or instead of it. By
| using the hardware attestation API, you can make a list of
| allowed key fingerprints for the SelfSigned boot state for
| non-Google-certified operating systems. We list all our
| current keys for non-end-of-life devices on that page.
| Recently, Swissquote used this approach to add support for
| GrapheneOS to their Yuh app and may be adding it to their
| main Swissquote app soon.
|
| You can test hardware attestation on any modern Android
| device but you'd need GrapheneOS on a real device to fully
| check that you have the SelfSigned fingerprint allowlist
| working properly. It wouldn't be hard to do it without
| testing it though, and our users can test if app developers
| ask our community on https://discuss.grapheneos.org/.
| azalemeth wrote:
| Please _don 't_ add play integrity to your app. There are
| many of us using custom ROMs, and it can relatively easily
| be worked around, but very much is often a giant screw you
| to technical users...
| AlgebraFox wrote:
| What problem do you think Play Integrity solve other than
| keeping the user's under Google's walled garden? Play
| Integrity is a fake marketing term for DRM fromGoogle . It
| does not guarantee security of the device in any way. My 6~
| year old and unpatched Android 10 passes Play Integrity and
| can run banking apps. That explains everything about Play
| Integrity. I don't use apps from developers who think they
| know better than their users.
| gruez wrote:
| >What problem do you think Play Integrity solve other
| than keeping the user's under Google's walled garden?
|
| It ensures requests to your backend are vaguely from
| actual devices, rather than a bunch of emulators. There's
| many reasons why developers might want this. It
| significantly raises the bar for credential stuffing
| attacks, for instance.
| 64848374 wrote:
| I feel like GrapheneOS shot itself in the foot, being exclusive
| to Pixel phones. Pixel phones were great, in the past, but now
| they're mediocre offerings for their price range and the removal
| of the 3.5mm jack pushed many of the more techy users away --
| GrapheneOS's target audience.
|
| Not sure if I'd use GrapheneOS even if it was available on other
| devices though. Really not a fan of the hostile attitude towards
| rooting when it's needed for basic functionality like backups --
| actual, reliable backups for every app, unlike those provided by
| the built-in solution.
| hexagonwin wrote:
| Huh? Pixels haven't had 3.5 jacks since Pixel 2 in 2017. wdym?
| GrapheneOS is exclusive to Pixels because no other device has
| the same security features like bootloader relocking.
| 64848374 wrote:
| 2017? Maybe I'm getting old... Still, the point stands -- the
| lack of a 3.5mm jack drives techy users away, and the Pixels
| just aren't very good for their price range today.
|
| > GrapheneOS is exclusive to Pixels because no other device
| has the same security features like bootloader relocking.
|
| Sure, because they picked a set of features exclusive to
| Pixels. Nothing is stopping them from being more permissive
| about the security features they require.
|
| I do understand why they chose to stick to Pixels; I think it
| was a mistake nonetheless.
| sksrbWgbfK wrote:
| > Nothing is stopping them from being more permissive
|
| Except for the fact that they don't want to be permissive
| to keep on being secure.
| strcat wrote:
| > Sure, because they picked a set of features exclusive to
| Pixels.
|
| No, we don't do that. The security requirements are not
| exclusive to Pixels. Samsung flagships with an Exynos or
| MediaTek SoC have nearly every feature listed at
| https://grapheneos.org/faq#future-devices. They don't quite
| have proper updates and quality of implementation is an
| issue. If Samsung allowed us to properly support their
| devices, we would likely be supported a few Samsung
| devices. There are no other devices with a reasonable level
| of security combined with support for using another OS
| available for us to support. We've also made sure to keep
| the required support time at 5 years instead of 7 to allow
| for non-Pixel devices. Snapdragon still not supporting
| hardware memory tagging at this point is embarrassing for
| Qualcomm and it should be expected that it's supported at
| this point, especially since even MediaTek has it now. The
| OEM making that and other security features available is
| also needed.
|
| > Nothing is stopping them from being more permissive about
| the security features they require.
|
| It would not have our core feature set and comparable
| protections. It would not protect users from real world
| adversaries like Cellebrite and NSO in the way that it does
| right now. Our security requirements exist for a reason and
| major parts of GrapheneOS are built around hardware-based
| security features. If the device doesn't have hardware
| memory tagging, then how can we provide one of our main
| flagship features?
|
| > I do understand why they chose to stick to Pixels; I
| think it was a mistake nonetheless.
|
| It's strange that you keep mentioning this in the past
| tense. We support Pixels because they're currently the only
| devices providing our security requirements while
| permitting us to use them. If Samsung started permitting us
| to support their devices, we could support certain Samsung
| devices. There aren't currently any other devices meeting
| our requirements, but there isn't a reason to think that
| there won't be in the future. Our list of security
| requirements is a very reasonable list of industry standard
| features. Android OEMs largely aren't trying to provide
| reasonably secure devices and are not trying to compete
| with Pixels and iPhones on security. Samsung is an
| exception, but quality of implementation isn't as high and
| they're ruining the end result with the massive non-
| security changes they make that's massively expanding
| attack surface and making updates much harder.
| rollcat wrote:
| > Sure, because they picked a set of features exclusive to
| Pixels. Nothing is stopping them from being more permissive
| about the security features they require.
|
| You're not the target audience for this OS. Strong security
| guarantees require vertical integration.
| Georgelemental wrote:
| The 3a, 4a, and 4a 5G had a headphone jack.
| strcat wrote:
| See https://grapheneos.org/faq#future-devices for the
| official list of security requirements. We've gone out of the
| way to keep them very reasonable to permit non-Pixel devices
| such as only requiring 5 years of updates rather than 7. We
| also don't require pKVM for virtualization to permit SoC
| vendors using their own proprietary hypervisors. It's a very
| reasonable list of requirements. Samsung has devices like
| their current generation flagship tablets meeting nearly all
| the security requirements. The blocker is Samsung not
| permitting another OS to properly support their devices
| including crippling security for them. The blocker isn't that
| there aren't devices providing the security features we need
| but that those devices don't allow us to support them. We
| aren't interested in low security devices like the Fairphone
| without even the basic security features included and with
| significant delays even for the security patch backports from
| the beginning.
|
| If Samsung had allowed a non-stock OS to properly support
| devices like Samsung Galaxy Tab S10+ and Samsung Galaxy Tab
| S10 Ultra, we'd have been very interested. They did not allow
| it. They permanently cripple their devices if you unlock
| them. People should criticize Samsung for this rather than
| criticizing us for something we don't control. Companies like
| Fairphone are not realistically capable of building what we
| need due to lack of resources so there's little point in
| people bothering them about it.
| snvzz wrote:
| >bootloader relocking
|
| My OnePlus3 (2017-ish?) can do that.
|
| It's not even a feature, but standard android bootloader will
| do this much. Vendors deliberately remove such features, if
| not disable phone unlocking outright[0].
|
| 0. https://en.wikipedia.org/wiki/Bootloader_unlocking
| strcat wrote:
| Qualcomm offers the feature as an option to every OEM using
| Snapdragon. Our understanding is that it costs extra money
| to license, like many of their features including security
| features. Snapdragon is immensely expensive for a modern
| flagship SoC with long term support and the full feature
| set including security features.
|
| OnePlus supported it on several devices but then removed it
| in updates fixing serious security vulnerabilities. Their
| non-stock verified boot support was insecure and instead of
| fixing it they removed it. It's likely there wasn't a clear
| or possible way to fix it due having a poor implementation
| which never worked properly. Fairphone 4 had a completely
| insecure implementation of verified boot trusting publicly
| available AOSP test keys. Having support for it really
| doesn't mean it works or will even keep appearing to work
| in future updates.
|
| It's also just one feature. Our overall hardware security
| requirements are listed at
| https://grapheneos.org/faq#future-devices. People focus too
| much on relocking the device but we require a lot more than
| that. There are non-Pixel devices with essentially all the
| features we require such as the Samsung Galaxy S10+ and S10
| Ultra but they don't allow using another OS without losing
| the security features. The updates are also still not what
| we expect, but if Samsung actually make it possible to
| support their devices we could accept some compromises. On
| the other hand, supporting far less secure devices missing
| things we consider hard requirements like memory tagging
| needed to provide our core feature set doesn't interest us.
| SubzeroCarnage wrote:
| The oneplus3 cannot be relocked as it wrongly trusts test-
| keys. It also has public EDL firehose files available
| allowing anyone to flash it arbitrarily even when locked or
| further dump ram or userdata.
|
| I previously documented this here: https://web.archive.org/
| web/20250120181249/https://divestos....
| strcat wrote:
| > I feel like GrapheneOS shot itself in the foot, being
| exclusive to Pixel phones.
|
| Pixels are the only available smartphones meeting our hardware
| security requirements while permitting us to use the hardware-
| based security features. Our requirements are very reasonable
| and listed at https://grapheneos.org/faq#future-devices. Recent
| Samsung flagships using an Exynos or MediaTek SoC have
| essentially all the security features on this list on paper.
| However, Samsung doesn't let us support their devices. Samsung
| cripples the device if you use another OS, mainly by
| disallowing using security features. Some of it is permanently
| disabled even if you go back to the stock OS and lock it again.
| There's an eFuse they refer to as the warranty bit which they
| burn when you unlock, crippling the device forever.
|
| The audience using GrapheneOS has become much less technical
| over time as usability and app compatibility has greatly
| improved. Installation via the web installer is something many
| very non-technical people are regularly doing successfully,
| largely without help. 24/7 real time help with installation is
| available via our chat rooms. Our overall audience is less
| technical than you think. The chat rooms attract a more
| technical subset of the community and isn't really
| representative.
|
| Pixels have digital USB-C audio output and DisplayPort
| alternate mode support. They have the start of a proper desktop
| mode and hardware virtualization support for running
| applications from other operating systems. In GrapheneOS, that
| can already be used for GUI applications with speaker,
| microphone and opt-in GPU acceleration support. Analog 3.5mm
| audio output isn't something people focused on bleeding edge
| technology want. Audiophiles never wanted to use low quality
| DAC in the phone but rather a high quality one connected via
| USB-C with digital audio output.
|
| > Really not a fan of the hostile attitude towards rooting when
| it's needed for basic functionality like backups -- actual,
| reliable backups for every app, unlike those provided by the
| built-in solution.
|
| GrapheneOS has a built-in encrypted backup system which uses
| the device-to-device mode. That's the mode Google Play services
| uses on Google Mobile Services devices when you transfer to a
| new device. It does back up every app, they can't opt-out of
| it. They can explicitly exclude data from device-to-device
| backups which is non-portable or shouldn't be used across
| devices such as a device-specific login token. The previous
| systems for opting out of backups or excluding files only
| exclude them from cloud backups now.
|
| Some apps like Signal encrypt their data themselves as an
| additional layer so no backup system other than the one built
| into their app is going to back that up and restore it in a
| useful way. Transferring data encrypted with a hardware
| keystore key which then can't be read/used by the app wouldn't
| be helpful. Transferring device-specific login tokens, etc.
| isn't wanted. The way the standard backup infrastructure is
| designed in Android is the right approach since Android 12. It
| does work well. The current backup service we're using is not a
| great implementation of it but has gotten better. We intend to
| completely fork it and massively overhaul it at some point. It
| was originally written by a GrapheneOS user for GrapheneOS but
| it got largely taken over by others and we don't agree with
| their approach or choices for it, so we'll be forking it.
| kazinator wrote:
| Samsung is banned in my household. Separately from what you
| say, every Samsung anything I ever owned was a piece of shit,
| starting with a certain DVD player back in 2003 whose
| firmware crapped out exactly one day after the one year
| warranty.
| switch007 wrote:
| > [backup]...which uses the device-to-device mode
|
| That's a very recent feature, isn't it?
|
| > They can explicitly exclude data from device-to-device
| backups
|
| Curious how many apps abuse that for purposes beyond the
| original intention? The big/popular apps etc? Ie what will be
| the real world experience despite this new feature
| strcat wrote:
| > That's a very recent feature, isn't it?
|
| Android 12 theoretically added it but it didn't fully work
| yet and apps needed to start targeting Android 12+. Then,
| the backup app needed to add it which took a long time, so
| it's fairly recent as in within the past 2 years.
|
| > Curious how many apps abuse that for purposes beyond the
| original intention? The big/popular apps etc? Ie what will
| be the real world experience despite this new feature
|
| Many apps use the older system to disable backups or
| exclude files which only applies to cloud backups now. Most
| apps don't exclude files from device-to-device backups
| improperly. Excluding device-specific login tokens, caches,
| etc. is how it's intended to be used. It annoys people they
| need to login to apps again after a transfer but that's
| generally how those apps want their security model to work
| so there's an entry for each login session and logging out
| of it only logs it out on 1 device.
|
| Apps can exclude files and define their own backup agent
| for handling converting to and from a portable format.
| Chrome does this to backup Android-specific settings, etc.
| not handled by Chrome's Sync feature. This means non-Chrome
| Chromium-based browsers largely lacking sync have poor
| backup support. We plan to address this in Vanadium but
| haven't decided how we want to approach it yet.
|
| It does work well. People mostly have a good experience
| with device-to-device transfer with Google Mobile Services
| devices now. Certain apps like Signal or TOTP apps using
| the hardware keystore inherently can't be backed up this
| way. Signal doesn't use it in a sensible way for security
| and really just seems to have introduced hardware keystore
| based encryption to prevent using root-based backup systems
| not taking into account which data should be backed up or
| not backed up. They don't trust the OS backup
| infrastructure particularly since OEMs can include sketchy
| backup services so they don't want that to work either.
| switch007 wrote:
| Thanks for the comprehensive reply! I gave it a go today
| with a USB stick. Just have to test a restore now :)
| strcat wrote:
| Backups are per-profile so you can test restoring most
| data in a temporary secondary user, just not settings it
| will only restore when restored in Owner.
| push0ret wrote:
| GrapheneOS, in my opinion, can only exist the way they do
| because of their exclusive support for Pixel devices. It allows
| them to provide a uniquely high quality ROM with proper support
| guarantees.
|
| Compare that to other custom ROMs, where you typically depend
| on volunteers maintaining the various devices. Sometimes people
| decide to step down, and suddenly find your device unsupported.
| This happened to me with LineageOS/CyanogenMod.
|
| My understanding is also that the OEM ROMs of Pixel devices are
| closer to AOSP than those of other vendors like Samsung. This
| simplifies the maintenance of the ROMs, and enables the project
| to develop meaningful features instead.
| strcat wrote:
| See https://news.ycombinator.com/item?id=43670303 for a
| detailed explanation. If we were going to support another
| device, it would need to meet the security requirements AND
| provide proper production quality non-stock OS support with a
| strong commitment to keeping it properly working.
|
| We can't safely use a device where they might patch out
| support for what we rely on. As an example, OnePlus patched
| out support for alternate OS verified boot due to serious
| security vulnerabilities with how they'd implemented it.
| Operating systems relying on it would no longer be able to
| update the firmware, leaving them insecure, but yet the
| verified boot never worked properly anyway so it ended up
| worse than them not trying in the first place.
|
| Realistically, what we expect is that Pixels are the only
| devices we're not involved in making which we'll be able to
| support for the foreseeable future. To support other devices,
| we need a partnership with a competent OEM like Samsung. We
| can raise money to pay the usual licensing fees for platforms
| and then work with them where we have paid support so they
| aren't going to break things for us, drop update support
| unexpectedly, etc.
| imiric wrote:
| Thank you for working on GOS. It is one of the few, if not
| only, OS that makes mobile devices usable for me.
|
| > To support other devices, we need a partnership with a
| competent OEM like Samsung.
|
| How realistic would it be to have an official Graphene
| phone? Could you partner with an open-source friendly
| company like Purism or Framework to design and manufacture
| the hardware to your specifications? That would be the
| ultimate mobile device for tech and privacy nerds, for
| which I'm sure many would be willing to pay a premium over
| mass manufactured devices.
|
| As much as I trust your vetting of Google devices, there's
| a strong incongruity between the mission of a trillion-
| dollar adtech company and yours that I just can't
| reconcile.
| strcat wrote:
| Samsung is the main company we'd really want to work
| with. They already provide devices meeting nearly all our
| requirements, they just don't provide us a way to support
| them yet. If they started doing that, we could support
| some of their devices. Better yet, if they actively
| worked with us, we could help them make major security
| improvements and there could be first class GrapheneOS
| support. We can raise money for it rather than having to
| convince them that it makes business sense to fill a
| product niche they aren't currently providing.
|
| > As much as I trust your vetting of Google devices,
| there's a strong incongruity between the mission of a
| trillion-dollar adtech company and yours that I just
| can't reconcile.
|
| Apple and Google provide a high level of security for
| their mobile devices. Other OEMs aren't on the same
| level. Samsung is the only one that's even remotely
| close. We'd love to work with Samsung but wanting to do
| it doesn't mean they will work with us. We could
| potentially pay them to build a device for us if we
| raised enough money in advance. We choose devices based
| on their security and other properties along with the
| actual record of the company making it. Corporations are
| amoral profit seeking entities in general. That's not
| something specific to Google.
|
| > Could you partner with an open-source friendly company
| like Purism or Framework to design and manufacture the
| hardware to your specifications?
|
| Framework doesn't currently build devices close to
| meeting our requirements but is not anti-security or
| misleading people like Purism. We wouldn't have any issue
| working with them, we just don't really expect them to
| start building what we need any time soon.
|
| Purism has extremely anti-security practices and makes
| extraordinarily insecure devices incredibly far from
| meeting our requirements. They purposely choose low
| security components and don't provide important updates.
| They even block providing the updates from the OS. We'd
| much rather support a low-end Motorola phone with only
| 2-3 years of support than a Purism device because they're
| so much less secure than mainstream hardware. Purism has
| 0 days of update support for their products in the sense
| that we require.
|
| We don't consider Purism to be a privacy friendly company
| due to the atrocious security of their products and
| services. The software they use on top is also far less
| private and secure than the Android Open Source Project.
| It's largely the complete opposite of GrapheneOS. They
| also do a lot of false marketing that's directly harmful
| to us such as their false claims about cellular radios.
| In reality, their device has a much less secure cellular
| radio with far more attack surface exposed from the OS
| than an iPhone. It's less isolated, not more isolated,
| and yet they've convinced many people otherwise with
| their marketing and done harm to the whole space with the
| misconception people now have. The same applies in other
| areas.
|
| If we partnered with Samsung, people would know they're
| going to get a good product and that the company making
| the hardware would still be around providing support
| years later. If we instead partnered with a company known
| for not shipping people what they ordered and not
| providing what was claimed in the promotional material,
| that would be very hard for people to trust. Our
| community would be shocked and incredibly disappointed if
| we did that.
| wiseowise wrote:
| > removal of the 3.5mm jack
|
| Jesus Christ, this again. Just buy good wireless headphones
| already, gramps.
| xorcist wrote:
| I would pay you (almost) anything to find me a pair that
| fits. It has taken me a long time to finally find a pair that
| I can use not only walking but also running.
|
| Then what to do when the battery dies? They only a last a
| couple of years. I can replace my phone pretty easily, but
| how can I find another pair of earplugs? That's a process I
| don't want to go through again. The human-device interfaces
| should just work.
|
| The only other solution I have found is a USB-C-to-3.5mm
| dongle but then the phone doesn't fit comfortably in my
| pocket anymore, and it's very inconvenient when running.
| Epa095 wrote:
| What about a Bluetooth to 3.5mm dongle? They can be quite
| small, and then you can place your phone independent of the
| headphone/dongle.
| strcat wrote:
| USB-C headphones and DACs do exist too.
|
| > The only other solution I have found is a USB-C-to-3.5mm
| dongle but then the phone doesn't fit comfortably in my
| pocket anymore, and it's very inconvenient when running.
|
| Get USB-C headphones rather than a DAC so that the DAC is
| in the headphones. There are high quality ones including
| earbuds.
| xorcist wrote:
| I would gladly pay you generous reward if you can find a
| pair that fits me.
|
| I literally mean this.
| strcat wrote:
| USB-C headphones and DACs do exist too.
| bornfreddy wrote:
| I'm with GP on this one. I am also on a phone without 3.5 mm
| jack and have wireless headphones because of that. It sucks.
| With wired (3.5) headphones thing just worked. With wireless,
| I have to think about headphones' battery level. I can charge
| from an independent source, but that is a problem when I'm
| moving (but yes, powerbank would work). I can also use wired
| headphones through USB-C, but this is a problem in a
| different setting - the phone better be full or I won't be
| able to charge it at the same time because the port is used.
|
| I'm sure there are valid technical reasons for removing the
| 3.5 jack, and I have adapted my headphones to the new
| situation, but man do I hate it.
| bslanej wrote:
| > I feel like GrapheneOS shot itself in the foot, being
| exclusive to Pixel phones. Pixel phones were great, in the
| past, but now they're mediocre
|
| Interesting that someone would say this. I've had several Nexus
| and Pixel phones in the past (last one was a Pixel 2) and they
| were all pretty bad in terms of hardware and the support from
| google was non existent. I only bought for them for the
| software... which wasn't great either. They have always been
| mediocre phones, to put it mildly.
| sureglymop wrote:
| I would say the exact opposite. The latest Pixel phones are
| "pretty much iPhones" in terms of hardware (and looks too). It
| seems smartphones have arrived at an agreed upon form factor
| and design in general.
|
| What I noticed though is that Google often tries to upsell
| based on software features alone. For example, there is really
| no point in buying a Pixel 9 Pro instead of a base Pixel 9 as
| the hardware is practically the same except certain things. But
| Google markets the Pro model with more software based AI
| features. When installing GOS this really doesn't make a
| difference so one can always opt for the more inexpensive
| models.
| strcat wrote:
| Only providing the Pro mode in Pixel Camera on the Pro
| devices is one of the only ways they're artificially
| segmenting them via software. The AI model differences are
| largely based on real differences in available memory and
| that doesn't have much impact on available OS features. That
| matters to LLM enthusiasts but probably isn't a selling point
| for most people at this point.
|
| The base devices are better value but the Pro devices do
| mainly differentiate based on hardware. Better display,
| addition of the 5x telephoto camera, better front camera and
| more memory are the main selling points. Pixel 9a is
| similarly a downgrade for the screen, cameras, memory,
| wireless charging speed and cellular radio (back to a variant
| of the 7th/8th gen Pixel radio). Pixel 9a has very good value
| but the cellular radio downgrade is a big one which people
| may care about more than they realize due to how it impacts
| battery life when using 5G.
| gostsamo wrote:
| what is the screen reader story with Graphene? Is talkback
| supported or it is a victim of the security model?
| strcat wrote:
| In general, we do not reduce app compatibility by removing any
| useful features. Our privacy improvements are implemented in a
| compatible way, like Contact Scopes pretending to be the
| Contacts permission having been granted but users choose which
| contacts can be seen and which data for those is visible. The
| only issues with app compatibility by default are due to app
| bugs including apps having bugs uncovered by exploit protection
| features. We have toggles to work around that including a
| simple per-app exploit protection compatibility mode changing
| the values of the finer grained ones. There are also a tiny
| subset of apps banning using a non-Google-certified OS, which
| are mainly a small subset of banking apps. We do have opt-in
| features which reduce compatibility with non-buggy apps, but
| they're all opt-in, such as the Dynamic Code Loading and native
| debugging restrictions.
|
| GrapheneOS includes a fork of the open source TalkBack. You
| need a text-to-speech implementation such as Google's Speech
| Recognition & Synthesis, RHVoice or eSpeak NG too. None of
| those is suitable for inclusion in GrapheneOS due to licensing
| and other reasons. There are some promising new apps based on
| more modern approaches which we're keeping an eye on. We may
| make our own text-to-speech and speech-to-text similarly. We
| recently built our own network location implementation in the
| OS and are building our own network location database/service
| with full offline support. The same thing is probably needed
| for TTS and the other direction.
|
| You can install Google's Android Accessibility Suite for the
| full proprietary feature set including extended TalkBack
| features. It works fine on GrapheneOS. It needs sandboxed
| Google Play for the full feature set.
| gostsamo wrote:
| thanks, this was one of my main unknowns about the
| alternative oses.
| max_ wrote:
| How "private" is graphene?
|
| How much do I gain from switching to it instead of say, remaining
| on the Stock Android?
|
| Edit: This looks comprehensive --
| https://staging.grapheneos.org/features
| MrDrMcCoy wrote:
| It's extremely private. It doesn't have Google services by
| default, but makes it easy to install them as unprivileged apps
| that - apart from giving you more control over what they can do
| and limiting certain access by default - work mostly exactly
| the same way as their privileged installs on other versions of
| Android. It also lets you disable Internet access privileges to
| any app that you don't want to have phone home.
|
| Beyond that, most of the other advantages will be less visible.
| They have hardened memory allocators that make various classes
| of security beaches significantly more difficult. There's a lot
| less superfluous background services eating resources. All that
| and more are listed on their website. It's well worth a read.
| therein wrote:
| That sounds really good. What are the downsides? How does it
| fare in terms of PlayIntegrity and SafetyNet etc?
| 10729287 wrote:
| I may be wrong but I think most bank apps won't run on
| those devices. Anyone can confirm ?
| switch007 wrote:
| YMMV. I'm on mobile but I think someone maintains a wiki
| page of compatibility.
|
| Remarkably, Nationwide (UK) runs perfectly even without
| Google services. (Except it doesn't poll for payment
| confirmations but that's understandable. They're always
| fetched when you open the app though. Or it could be my
| setup). It's actually quite shocking and it speaks to
| Nationwide as being a decent organisation.
|
| It's also not necessarily a downside. Having your banking
| app on your phone can be a risk of you often take your
| phone out in public
|
| The absolute blocker is Google Pay. That isn't supported
| fph wrote:
| Here it is:
|
| https://privsec.dev/posts/android/banking-applications-
| compa...
|
| with its github backend
|
| https://github.com/PrivSec-dev/banking-apps-compat-report
|
| If you are in Europe, Curve recently enabled mobile
| payments without Google Pay, and that might solve the
| issue (but I haven't tried it myself).
|
| Some app that don't work because they require strong
| integrity are listed here:
| https://grapheneos.org/articles/attestation-
| compatibility-gu...
| switch007 wrote:
| Great thanks for linking! I'm sleep deprived and was
| being lazy.
|
| Awesome to read the support chat from nationwide saying
| it's explicitly supported. I figured as it works so well.
|
| They're a very decent building society/bank if anyone is
| looking for a new one!
| xorcist wrote:
| > Curve recently enabled mobile payments without Google
| Pay,
|
| This could be very useful. My Google skills came up
| short. Do you have a link?
| codethief wrote:
| Not sure my search engine skills are any better but here
| are a few links:
|
| From 2 years ago: https://www.reddit.com/r/GrapheneOS/com
| ments/126nd51/comment... -> Sounds like Curve (without
| Google Pay) wasn't officially supported in Europe and
| didn't work for most people.
|
| However, this seems to have changed a couple days ago:
|
| https://www.reddit.com/r/curve/comments/17txz6u/comment/m
| kwl...
|
| https://discuss.grapheneos.org/d/443-gpay-alternatives-
| for-g...
|
| https://discuss.grapheneos.org/d/475-wallet-google-
| pay/105
|
| https://discuss.privacyguides.net/t/curve-pay-available-
| as-a...
|
| This is in line with an interview with the CEO of Curve
| from last month, https://paymentsconsulting.com/qa-with-
| shachar-bialick-at-cu...
|
| > We are launching Curve Pay in beta for Android soon and
| plan to release it on iOS thereafter. This will allow
| customers to use Curve as their default wallet, just like
| Apple Pay or Google Pay.
|
| ...and with various German news sites reporting that
| Curve Pay is now available in Germany (and likely other
| parts of the EEA).
| blackbear_ wrote:
| I can't say for "most" apps but I've never had any issue
| with banking nor digital identity apps.
| mikae1 wrote:
| Same here, no problems. You can run Google Play Services
| and Google apps sandboxed using the built-in GrapheneOS
| App Store. There's nothing like it.
| Eavolution wrote:
| I wouldn't say most, but a large portion. You should be
| able to look up in advance which ones are funny about
| custom roms, the key words are safetynet or play
| integrety api.
|
| My solution to this is put the bank apps that are
| annoying about it on an old phone (I knew I'd find a use
| for one eventually!)
| darthrupert wrote:
| https://privsec.dev/posts/android/banking-applications-
| compa...
|
| Many seem to work, if you apply some tweaks. Google
| Wallet NFC payments totally don't, I believe.
| haakon wrote:
| All bank apps I've tried works.
| fragmede wrote:
| Which, I mean, I'm willing to buy that, but it would be
| helpful if you named names.
| ProfDreamer wrote:
| There's a crowd-sourced list of banking apps known to
| work on GOS at
| <https://privsec.dev/posts/android/banking-applications-
| compa...>.
| Biganon wrote:
| I'm in Switzerland, and both Neon (Hypothekarbank
| Lenzburg) and Zak (Banque CLER) work perfectly fine.
|
| Google Wallet does not work, therefore I cannot use my
| phone to pay wirelessly with my Neon card, which is a
| shame.
|
| The only apps I had trouble with were Twint (had to
| install it with F-Droid, as Play kept telling me it was
| not compatible with my device), and... the McDonald's app
| (which forces me to move my fat ass to one of their
| kiosks to order my food instead of doing it from the
| table).
| Vinnl wrote:
| One downside (that may be a very manageable one) is limited
| device support (which enables all that).
| nvllsvm wrote:
| Balatro is not installable from the Play Store on my Pixel
| 7 due to Play Integrity.
|
| Side note, balatro-mobile-maker works really well as an
| unofficial port to Android.
| https://github.com/blake502/balatro-mobile-maker
| strcat wrote:
| The features page you've linked is the best place to look for
| an overview of what we provide. It lists what we change and add
| compared to the latest release of the Android Open Source
| Project or the stock Pixel OS. Lots of important features are
| listed together in a single section, particularly in the
| exploit protection section / sub-sections covering a huge
| portion of what we provide in terms of security. It covers most
| of what we provide other than assorted smaller changes. Also
| worth noting we remove features from the list when they become
| standard Android features, and we successfully got various
| features we implemented into the Linux kernel or Android Open
| Source Project.
|
| Here's an example demonstrating the impact of our security
| improvements:
|
| https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
|
| February 2025 Cellebrite Premium documentation was posted by
| someone further down in the thread, which is essentially the
| same overall situation.
|
| https://discuss.grapheneos.org/d/20401-grapheneos-improvemen...
| has some details on how we've improved that since early 2024.
|
| The stock Pixel OS is approximately AOSP with a bunch of Google
| apps deeply integrated into it. Pixels don't actually change
| anything compared to the AOSP code, they just substitute
| various components with their own and add a bunch of overlays,
| apps, etc. AOSP has all the stuff they need to provide that
| included already. They give extensive privileged access to
| Google Play and various other apps via privileged permissions,
| SELinux MAC/MLS policy (which is included in AOSP) and various
| allowlisting, etc. They also use Play services, etc. as
| backends for various AOSP APIs. One of our major features is
| our sandboxed Google Play compatibility layer enabling running
| Google Play services, Google Play Store, Google Search, etc. as
| regular sandboxed apps with no special access at all where
| users don't even need to grant them the regular non-privileged
| permissions like Contacts, Location, etc. to use most of their
| functionality (some functionality requires that such as if you
| wanted to use Google Maps location sharing or Google Contacts
| sync).
| Phelinofist wrote:
| Do you think you are target (idk, by maybe three letter
| agencies or black hat groups) for the work you do? Do you
| have any special OPSEC to account for something like this?
| mystified5016 wrote:
| Graphene is not for everyday casual users. It really only works
| well if you don't rely on _any_ apps that depend on Google
| play, like steam or discord. If you 're on AT&T, you don't get
| caller ID or voicemail.
|
| This is an OS for people who care more about privacy and
| security than having an everyday usable phone. It is very much
| not for normal people.
| strcat wrote:
| > Graphene is not for everyday casual users.
|
| GrapheneOS is intended for everyone.
|
| > It really only works well if you don't rely on any apps
| that depend on Google play, like steam or discord.
|
| Steam, Discord and the vast majority of Android apps work
| perfectly on GrapheneOS. Sandboxed Google Play is a robust
| feature which works very well. If you're choosing to
| completely avoid using Google Play, that's your choice. Steam
| and Discord both still likely work without it, but without
| push notifications since they have no alternative to FCM as
| certain other apps do.
|
| > If you're on AT&T, you don't get caller ID or voicemail.
|
| You do get caller ID and voicemail on AT&T. Visual voicemail
| doesn't work with AT&T with the built-in Dialer app because
| it uses a protocol not supported by AOSP. It does work with
| Google Dialer based on user feedback on our forum.
|
| > This is an OS for people who care more about privacy and
| security than having an everyday usable phone. It is very
| much not for normal people.
|
| GrapheneOS is very usable as an every day usage phone for
| regular people. Nearly every Android app can be used on it.
| It sounds like you were choosing to use it without sandboxed
| Google Play, which is a choice to have a more limited app and
| service ecosystem. That's not the same as a choice to use
| GrapheneOS. It can be used like a regular Android phone with
| 1 profile containing sandboxed Google Play, or people can use
| sandboxed Google Play in a specific profile with most of
| their apps in another profile. Using it without sandboxed
| Google Play in a secondary profile is something many
| GrapheneOS users do successfully but it's in no way required
| or expected. We wouldn't have made that huge feature if we
| didn't want it to be used by a lot of people.
| gradeless wrote:
| Not sure if you've used GrapheneOS recently? If apps are
| heavily tied to Google Play Services you can install that
| and, in the vast majority of cases, get very good
| compatibility.
|
| Compatibility with carriers also improved a lot a few years
| ago. Configurations for most carriers are pulled in from the
| stock Pixel OS. Some US carriers do weird things that depend
| upon having highly privileged apps bundled into the OS which,
| for security reasons, GrapheneOS doesnt include. I dont
| recall AT&T being one of them.
|
| GrapheneOS is very usable and fine as a everyday phone for
| normal people.
| pinetroey wrote:
| I've been eying GrapheneOS for a few years. But there is one
| thing holding me back, Auto Call Recording.
|
| I'd love to make the switch.
| strcat wrote:
| It's a planned feature but isn't a high priority. It's hard for
| us to get to it with all the other things we want to implement.
| We'll add it one day. We need to keep hiring more developers
| and expanding to do more.
| sureglymop wrote:
| I have a question you may be able to answer. Are
| contributions to GrapheneOS in general welcome? If yes, where
| would one start, is there a page about setting up a
| development environment or outlining a list of features/areas
| that could need work/help? I have quite a few spare Pixel
| phones that are currently just idling but I'd love to try
| building and installing GOS myself to start out.
| oth001 wrote:
| Isn't there an app for that?
| gitaarik wrote:
| https://f-droid.org/packages/com.github.axet.callrecorder
| RandomBacon wrote:
| I use ACR Phone app with the APH app and removed Network
| permissions.
| pinetroey wrote:
| Does it record 2-way audio in good quality? Ear & speaker &
| Bluetooth
| RandomBacon wrote:
| It uses the phone's microphone (Android OS limitation), so
| if it's Bluetooth in the car, it should pick up everything
| (just like the people in the next car over can hear your
| conversation, fyi), but if it's a Bluetooth headset, I
| don't think it will pick up their side.
|
| Audio quality is very good. By all means test it out in
| different configurations before relying on it.
|
| A native implementation would still be better. I hope the
| GrapheneOS devs can pull it off.
| darkwater wrote:
| Off topic but related to Android replacement on phones, let see
| if anyone can help me: I have an old Xiaomi Mi 9SE in a drawer,
| and I would like it to give it to my daughter as a Spotify player
| and that's it. No phone, no camera, no browser. Just Spotify.
| What would be the best way to start? PostmarketOS doesn't support
| it, GrapheneOS is security-focused, LineageOS is basically a
| full-fledged Android, I don't know if I would be able to limit it
| as I would.
| tentacleuno wrote:
| You _might_ be able to use App pinning to stop them leaving the
| Spotify app...
| codethief wrote:
| On LineageOS with a bit of work you can also remove built-in
| apps like browser, camera, etc.
| 0x38B wrote:
| The Pixel 9a is really tempting for someone like me who's tired
| of living in Apple's walled garden (1), but wants a decent device
| at a fair price that'll be supported for a good long time - the
| Pixel 9a ticks all of those boxes.
|
| 1: Why? File management and getting files into apps is the #1
| area where Android wins.
|
| For example, iOS has me copying or saving audiobooks into a
| folder only to import them into BookPlayer, whereas Android's
| Smart Audiobook Player lets me copy my book to my audiobooks
| folder and hit 'rescan'.
|
| Funnily enough, one of the only music apps on iOS that offers the
| same functionality - copy a folder into your library and rescan -
| is the same Neutron Player I used to use on Android. The
| interface is clunky, but that's a small price to pay.
| piyuv wrote:
| I wish I didn't have to pay google of all companies to escape
| Apple.
| Epa095 wrote:
| I wonder how much Google actually makes on these. I won't be
| surprised if they basically make nothing on them.
|
| It is a bit fun that seemingly the best way to de-google and
| de-apple yourself is to buy an actual Google device and
| install grapheneos on it.
| notorandit wrote:
| I hope the so-called blobs have been replaced with unprivileged
| opensource versions.
|
| Otherwise privacy and security would be meaning basically
| nothing.
| strcat wrote:
| Open source doesn't provide any magical privacy or security.
| iPhones have solid privacy and security despite being mostly
| closed source software. iPhones are the next best options for
| privacy and security in most ways. They have great privacy from
| apps and aren't awful at privacy from Apple particular if
| people use Advanced Data Program for iCloud, and they have
| solid security overall along with some useful settings for it.
| GrapheneOS of course provides better privacy from the OS
| services. We provide a full list of default connections made by
| the OS at https://grapheneos.org/faq#default-connections and
| none are made by the hardware without the OS prompting it.
| GrapheneOS also defends better against sophisticated real world
| attacks, and there's real world evidence for that from leaked
| capabilities of Cellebrite, Magnet Forensics (Graykey) and MSAB
| (XRY) along with some basic info about remote exploit sellers.
|
| All of the kernel drivers are open source, which would be the
| case for Snapdragon too.
|
| Firmware is largely closed source but Pixels do use Trusty OS
| for the TEE and secure core, littlekernel as the late stage
| bootloader firmware and OpenTitan as the firmware/hardware
| basis for the Titan M2 secure element that's holding up much
| better to attacks than anything but Apple's SEP (see brute
| force info in
| https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
| or the newer February 2025 documentation someone posted further
| down). We still do security research work on the hardware and
| firmware including reporting vulnerabilities and suggestions.
| Several firmware and hardware based features we've proposed
| were implementing including the pinning-based hardware
| attestation support we used to improve our Auditor app and
| AttestationServer, reset attack protection and various other
| things.
|
| There are still shared source libraries and services for
| certain hardware but Pixels moving away from Snapdragon has led
| to that approach being on the way out. The move away from
| Exynos with the Pixel 10 should help.
|
| If we make our own device with an OEM using Snapdragon, we'd
| have access to most of the sources for their driver
| libraries/services and a lot of firmware. It's not open source
| but OEMs have access. That also means a lot of it gets
| consistently leaked. They stopped sharing their radio firmware
| sources with OEMs because of those leaks.
| haukem wrote:
| > If we make our own device with an OEM using Snapdragon,
| we'd have access to most of the sources for their driver
| libraries/services and a lot of firmware. It's not open
| source but OEMs have access.
|
| Is it normal that phone OEMs have access to most of the
| source code of the kernel drivers and user space libraries
| provided by the SoC vendor.
|
| I worked in the home router business and there it was normal
| that a OEM gets most of the kernel drivers and user space
| code in source code, but it was often restricted what they
| are allowed to publish in source code. Many vendors even
| published much less than they had to according to GPL and
| allowed by the SoC vendor.
|
| I have heard that in the smart TV industry OEMs sometimes are
| only allowed to write an app and have no kernel source code
| access for their product.
| ram_rattle wrote:
| I wonder how they handle cellular and wifi part, lot of
| proprietary shit in that.
| m1keil wrote:
| How is the camera quality on the GrapheneOS phones?
| celsoazevedo wrote:
| GrapheneOS' own camera app doesn't have Google's propriety
| processing, so it's not as good as stock, but with Pixel
| devices, you can install the original Google Camera/Pixel
| Camera app and get the original camera quality.
| strcat wrote:
| GrapheneOS Camera does have hardware accelerated HDR+ and
| Night mode along with HDRnet and EIS for videos on Pixels.
|
| Photos in Pixel Camera look different because the HDR+ it
| uses by default is more aggressive resulting in higher
| contrast but a less natural look. Both are using HDR+ with
| hardware acceleration though. Videos are more similar and
| Night mode photos likely are too.
| strcat wrote:
| Camera quality is the same within the same app on either.
|
| Pixel Camera can be used on GrapheneOS with full features and
| photo/video quality if you want it.
|
| GrapheneOS Camera has support for HDR+ on Pixels for regular
| photos and has Night mode too. It has EIS and HDRnet for video
| recording. It has a single exposure slider rather than their
| dual exposure sliders. It uses each of the cameras via zoom
| level / light level in the same way. More advanced features and
| configuration are being added to it over time.
|
| Pixel Camera has more features and the HDR+ it uses is more
| aggressive which makes the photos look higher contrast than a
| more natural look.
| versluis wrote:
| I love GrapheneOS. The biggest downside is that Google integrity
| API block wireless payments in Google Pay. All Dutch banks now
| advertise to install Google pay for wireless payments. I've tried
| asking Google to support GrapheneOS but they told me to do a
| feature request. Which I did and got no reply to. I've contacted
| the consumer market authority and made a formal complaint since
| Google and Apple share effectively a contactless payments duopoly
| and decide which OS distributions get access. Those are closed
| source and usually bundled with a lot of spyware. I also
| explained how the Google integrity API might affect banking
| availability in the future (and already does for some banking
| apps). They took it very seriously and I hope to hear from them
| in the future.
| decide1000 wrote:
| Did you do your complaint at ACM? I want to follow your example
| versluis wrote:
| I did using their website form. It needs to be clear from the
| complaint that Google is violating fair market principles.
| They also like details about what exactly is happening and
| who is affected. That was why they called me after I filed
| the complaint.
| Aachen wrote:
| I would love to chip in and see if we can get this ball
| rolling, usually I feel like I'm the only person who cares
| or files AP/ACM/... complaints and then it's too small
| beans for them to care. I'd not submit the literal same
| thing again, but could you share what wording you've used?
| Specifically in this case I'd also not be sure whether this
| blocking of Graphene etc. is abuse of market power when
| there is another option on the market (Apple) and so it's
| not a monopoly
|
| There's no contact info in your profile so I couldn't reach
| you. If you don't want to share it here, you could use the
| email address in my profile
| versluis wrote:
| Good that you mention it. I will add contact details. It
| has been a while so I don't remember the exact wording. I
| wouldn't use the same wording since it is not a petition
| and doesn't add value. They want to research if it is an
| unfair practice. In my opinion banking and wireless
| payments is a common good. Having two companies, who only
| approve software of partners, most of them including
| unremovable spyware, is limiting on access to banking and
| privacy (although privacy is another department). I
| mentioned security since that is Google's argument for
| the block even though GrapheneOS is more secure than
| approved builds. I gave the number of GrapheneOS users to
| make clear it doesn't affect only a few individuals. I
| think LineageOS users might also be affected?
| Aachen wrote:
| It shouldn't work like a petition, but these
| organisations do treat it as such unless something is
| very obviously a major violation. Even with numbers of
| Graphene users, what part of that is Dutch? What part of
| that wants to use Google Pay? What part makes use of a
| workaround? Multiple reports of problems does give some
| information/signal that this is worth their time
|
| But yes, as said I'd not use the same wording because it
| shouldn't just be a copy-paste, that's also wasting their
| time. I could refer to what was already submitted so they
| can more easily bundle them, but I understand you don't
| have it anymore so np. Thanks for mentioning you've
| submitted this in the first place and the additional
| info, that does motivate me to continue also submitting
| things and to know better what makes sense to submit :)
| palata wrote:
| > All Dutch banks now advertise to install Google pay for
| wireless payments.
|
| That sounds like a very big mistake to me. And a missed
| opportunity: in some countries, banked work together to develop
| their own systems. People can send money to each other and pay
| everywhere with a small app that is not BigTech from the US.
|
| I think there should be such an app in every country; you don't
| want your payment system to fully depend on US companies.
| argsnd wrote:
| Generally what you're describing is in countries that don't
| have widespread adoption of NFC payments. In Europe almost
| every country has standardised NFC payments so Apple/Google
| Pay is the most frictionless option for users.
| palata wrote:
| Switzerland (which is not a country that doesn't know how
| to do banking :-) ) uses Twint (a Swiss app) with QR codes
| instead of NFC. To me it's better than NFC (it works with
| printed QR codes, e.g. on parking payment machines).
|
| I don't know anyone in Switzerland using Apple/Google Pay,
| which IMO is a national success.
| sushibowl wrote:
| Dutch banks did this, it is called iDeal:
| https://www.ideal.nl/en/
|
| iDeal is ubiquitous in The Netherlands for individuals
| sending money to each other, and for online payments. However
| it does not support NFC payments in physical stores. Dutch
| banks decided to go with Google/Apple wallet for this. I
| believe in the longer term Wero https://wero-wallet.eu/ (and
| potentially the digital euro https://www.ecb.europa.eu/euro/d
| igital_euro/html/index.en.ht...) is supposed to take over
| this usecase in the EU.
| palata wrote:
| That sounds good! Instead of NFC, they could use QR codes.
| All the payment terminals can show a QR code, and it's even
| possible to print a QR code on a piece of paper without the
| need for the terminal.
|
| Twint does that. They started trying to make it "seamless"
| with NFC, but couldn't do it because of Apple (maybe now
| with the DMA it may change) and went for some kind of weird
| bluetooth stuff. Nobody used it. Then they moved to QR
| codes, and it quickly got very popular.
|
| Everybody understands QR codes. No need to know whether
| your phone supports NFC or not, no need to go check if NFC
| is enabled in the settings, nothing. Everybody understands
| that they need to scan the QR code with their camera,
| period. Seems perfect to me.
| jonkoops wrote:
| > they could use QR codes
|
| It already does for web purchases, so there is no reason
| it could not. Not sure why this is not more commonplace.
| dzikimarian wrote:
| Banks do that for p2p payments and e-commerce (like iDeal
| mentioned by sibling comment or BLIK in Poland).
|
| For physical transactions there's barrier of hardware and
| network effect - everybody has card terminal. Users expect
| near 100% acceptance for them to use payment method daily.
|
| If you consider creating own NFC payment app instead of
| Google/Apple Pay - that's actually possible, but more
| expensive and often disliked by the users due to inability to
| easily switch between cards issued by different apps.
| codethief wrote:
| > If you consider creating own NFC payment app instead of
| Google/Apple Pay - that's actually possible
|
| Is it? Last time I checked, Apple & Google were also
| interfacing with banks on the server side, i.e. banks had
| to integrate with Apple/Google specifically. I'd love to be
| wrong, though.
| palata wrote:
| I believe that for a long time, Apple was preventing the
| use of NFC (or was it just for payments?). The EU Digital
| Markets Act is supposed to prevent them from doing that,
| as part of the "interoperability" part. And I think the
| DMA is great in that sense.
| codethief wrote:
| True, on iOS access to the NFC chip has been a additional
| blocker. But on Android apps have been able to use the
| NFC chip just fine and it's still not that easy to write
| a generic "wallet" app (that's compatible with all banks
| & cards), see my previous comment.
| charcircuit wrote:
| >But on Android apps have been able to use the NFC chip
| just fine
|
| The last time I looked at it, it was not possible because
| Android doesn't let apps control the uid that gets used
| for NFC.
| codethief wrote:
| Ah right, good point. I did forget about that.
|
| Either way, even if apps had full control over the chip,
| my understanding is that building a wallet app would
| still amount to much more than just interfacing with the
| NFC chip.
| dzikimarian wrote:
| It's optional if you want "add to wallet button".
|
| That's not related to ability to create own app - on both
| ios and Android you can access NFC hardware directly (on
| iOS it's limited geographically), and send card data as
| you see fit - Google & Apple do nothing in such case.
| palata wrote:
| As mentioned in the sibling comment, Twint goes with QR
| code. It just works.
|
| It's even better than NFC because a small store can print
| their QR code on a piece of paper and not need to buy a
| terminal. Most stores just have the normal card terminal
| print the QR code and people scan it.
| andrewaylett wrote:
| NFC, for payments, has bidirectional communications and
| limited scope for MITM. It's a bit too easy to cover a
| sticker.
|
| The TWINT app says -- if their promo videos are to be
| trusted -- "Scan only QR codes from trusted sources and
| check the receiver of the payment in the next step". That
| doesn't fill me with confidence :(.
|
| A dynamic QR code could be _fine_ -- they have their app,
| you 're able to bootstrap what is effectively a secure
| channel between the PoS machine and the app to give the
| vendor confidence their device has received payment and
| the consumer confidence that they're paying the right
| vendor. A static QR code is more challenging, and it
| sounds like they're putting more weight into social
| protections than I'm comfortable with -- especially
| considering a technical solution is possible _and
| exists_.
|
| I'm especially wary of the warning that individuals can't
| have QR codes. Why not? Unless it's part of the social
| protection. But I can personally accept NFC contactless
| payments (having opened an account with a suitable
| provider), and indeed I bought a device which means I can
| accept chip and PIN payments too.
| palata wrote:
| Multiple things here.
|
| * The vast majority of the payments (almost all of them)
| are done with dynamic QR codes.
|
| * The static QR code is mostly used by very, very small
| entities. Like the person asks you to scan their code,
| enter the amount and show them the confirmation. It is in
| their interest to show the right QR code.
|
| * Sending money to a friend is done with the phone number
| as an id. It works, but you need to enter the mobile
| phone number of the receiver.
|
| * There is one situation where static codes are printed
| and where phishing has been reported (it's not MITM, it's
| really just a QR code that sends you to a bad website):
| when paying for parking. You don't have to use it if you
| don't feel comfortable, and it is possible to feel
| comfortable because it actually just opens a website (so
| if you use it regularly you can learn to check that you
| are on the legit website before you make the payment).
|
| Overall, it is _super popular_ and it works _really
| well_. No need for NFC, and _no need to install the
| Google Play Services_ \o /.
| nebulous1 wrote:
| I agree, but in this banking apps (around me) use the
| Integrity API anyway.
| dopidopHN wrote:
| It's great. Thanks for doing that. The French concurrence
| authority would probably love that type of reasoning. Specially
| now that the US is officially an adversarial entity.
| ohgr wrote:
| I just use contactless cards now. I'm done with tying my
| financial capability to a third party device. If I want to pay
| someone directly it's PayPal family and friends or direct bank
| transfer.
| encom wrote:
| Yea, I really don't understand how using a phone is any
| simpler than just tapping my debit card at the terminal.
| There's no way in hell I'm letting Google anywhere near my
| personal finances.
| darthrupert wrote:
| Nfc card payments have a pretty low max limit at least
| without a pin.
|
| Phone nfc payments do not.
| dnzm wrote:
| Using a phone is simpler if all you have on you is your
| phone, which was my use case when my bank hadn't offloaded
| their wallet app to gpay. That, and having the phone
| already in hand for customer/loyalty cards.
|
| So yes, it's handy. Jot handy enough to use gpay for it, of
| course, but handy nonetheless.
| hedora wrote:
| Thanks for doing that. I tried GrapheneOS a few years ago in
| the states, and the bank thing wasn't a huge problem (just
| carry rfid cards because there's no google pay/apple pay).
|
| The bigger problem came from apps that threw null point
| exceptions on startup when probing for google play crap.
|
| The following failed for at least one week over a two month
| period: parkmobile, multiple ev charging networks, uber, lyft,
| yelp.
|
| Is this still an issue, or are things more reliable these days?
| (Ignoring the Google integrity stuff.)
|
| I noticed that GrapheneOS got more than 2x Google's advertised
| battery life until I installed Google Play Services in a
| sandbox. Then it dropped to advertised. You might want to add
| that to your complaint. Halving everyone's battery life is
| easily quantified economic damage. (Privacy is more important
| than bundling $50 of battery, then wasting it, but easier for
| Google to wave away with big words and doublespeak.)
| hellcow wrote:
| The app crashes I found were always due to the additional
| security hardening features in GrapheneOS. You can toggle
| these individually for each app.
| strcat wrote:
| You can use Curve Pay for tap-to-pay on GrapheneOS in most of
| Europe including in the Netherlands. It also works in the UK,
| not just the EU. It unfortunately hasn't launched in the US
| yet.
|
| Some of those banks may also still support using their own tap-
| to-pay. Europe has a standardized system for it and many banks
| support it. Check https://privsec.dev/posts/android/banking-
| applications-compa... for those banks. There was a major shift
| to using Google Pay to reduce their development costs but there
| may be a major shift away from it now.
|
| https://grapheneos.org/articles/attestation-compatibility-gu...
| should be sent to companies banning using GrapheneOS via the
| Play Integrity API. They can keep doing that while permitting
| GrapheneOS in a more secure way. Our users recently convinced
| several banks to implement it. Swissquote implemented it for
| their Yuh app and will hopefully do it for their main
| Swissquote app soon. It would be nicer if they didn't add Play
| Integrity API in the first place but progress can be made if
| users leave lots of reviews, support requests, etc. until they
| realize it's a big issue and either remove it or implement this
| as a replacement.
| pshirshov wrote:
| icard NFC payments also work fine
| ulrikrasmussen wrote:
| Thank you for doing that. Integrity API is fucking evil, and
| Google has somehow managed to sell it as a security measure
| even though it is all about taking control away from people and
| concentrating it at Google.
| raffael_de wrote:
| What is the current conventional UX with GrapheneOS?
|
| Especially regarding:
|
| - Usability of taxi apps like: Uber, Grab, Bolt
|
| - Camera quality versus stock ROM
| adikso wrote:
| Uber and Bolt apps works like normal. I don't know what is
| Grab. The default camera lacks post-processing tricks, but you
| can install Google Camera if you like (shouldn't be a privacy
| concern here with limited permissions).
| raffael_de wrote:
| Interesting. I used to have problems using such apps on
| LineageOS due to their dependence on this Google Push
| Messaging service (don't remember what it's called) and also
| dependence on Google Maps services.
|
| (Grab is like Uber/Bolt but used in different regions of the
| world.)
|
| Camera quality of LineageOS was really bad.
|
| A voyage was the catalyst for switching to iPhone as this
| seemed back then the best option to LineageOS and I couldn't
| risk not being able to use such logistically relevant apps.
|
| Especially in Asia you have to be ready to install and use
| whatever app is required and not being able to might be
| seriously handicapping.
| sureglymop wrote:
| On GrapheneOS, you can install Google play services in a
| sandboxed way (and if you want, in another user profile,
| work profile or private space) which can allow all these
| things to work seamlessly. Generally I've had way more
| problems with other custom roms and things like MicroG. I'd
| recommend to just try it out if you have an unused pixel
| phone. Imo it's very unlike any other custom rom in terms
| of the user experience.
| strcat wrote:
| GrapheneOS Camera does have HDR+ and Night mode on Pixels
| along with HDRnet and EIS for videos. Pixel Camera has more
| features and more aggressive HDR+.
| strcat wrote:
| The vast majority of Android apps including those can be used
| on GrapheneOS.
|
| Camera quality is the same within the same app on either.
|
| Pixel Camera can be used on GrapheneOS with full features and
| photo/video quality if you want it.
|
| GrapheneOS Camera has support for HDR+ on Pixels for regular
| photos and has Night mode too. It has EIS and HDRnet for video
| recording. It has a single exposure slider rather than their
| dual exposure sliders. It uses each of the cameras via zoom
| level / light level in the same way. More advanced features and
| configuration are being added to it over time.
|
| Pixel Camera has more features and the HDR+ it uses is more
| aggressive which makes the photos look higher contrast than a
| more natural look.
| tiborsaas wrote:
| We should normalize having a "sceenshot" menu in the navigation
| again. Not their social, website has any. Is this a text based
| operating system?
| codethief wrote:
| GrapheneOS looks almost exactly like AOSP and doesn't add any
| visual features, so screenshots would be somewhat pointless.
| tiborsaas wrote:
| It would answer my question properly if I'd seen that it
| looks just like the stock Android UI, so even though it's
| almost exactly the same, that's still quite valuable for me
| rather than pointless.
|
| I've also done some image search and it does change a bit
| with apps and they look quite good. So I'm still baffled why
| this aversion to images is decided. Or just overlooked maybe?
| codethief wrote:
| Probably just overlooked, yes.
|
| > it does change a bit with apps and they look quite good
|
| Hmm, I haven't noticed any difference. Which apps are you
| referring to?
| tiborsaas wrote:
| In this article there are a few screenshots with
| grayscale icons:
| https://9to5google.com/2024/04/16/grapheneos-review-de-
| googl...
|
| Is that the default?
| codethief wrote:
| No, the grayscale icons are for built-in GrapheneOS apps
| only. Non-GOS apps look as they would on any other phone.
| strcat wrote:
| Our own apps and the currently basic forks of Android
| Open Source Project sample apps use black, white and gray
| as their icon color scheme. It's similar to how other
| organizations choose a few colors for their apps. The
| icons aren't grayscale, those are just the current colors
| we use for our own.
| jeroenhd wrote:
| It's still a custom ROM and it's not uncommon for those to be
| reskinned in interesting or weird ways. Plus, their website
| already uses the outline of a phone with their logo inside of
| it, why not make that a screenshot of their ROM with their
| logo as a background?
|
| Furthermore, I'm interested in what their solution for email,
| calendars, and all the other Google services look like. If
| it's AOSP, that's a good reason not to use this ROM. I
| suspect it's not actually using AOSP's apps, though.
| codethief wrote:
| > Furthermore, I'm interested in what their solution for
| email, calendars, and all the other Google services look
| like.
|
| There are no built-in apps for that. The only custom apps
| GOS provides are Auditor (https://attestation.app/),
| Camera, Calculator1, Contacts1, Files1, Gallery1,
| Messaging1, a hardened PDF viewer, and Vanadium (a hardened
| version of Chromium). Everything else is up to you.
|
| 1) AOSP app or fork of the AOSP app.
| EffrafaxOfWug wrote:
| When installing graphene os I would consider very carefully if
| you want to relock the bootloader. In the past I have installed
| graphene os on my pixel 7a and a normal system update broke my
| system and made it unbootable. Because of the locked bootloader
| you can't reflash the os without wiping your data. It may be a
| very uncommon bug that may never happen to you, but honestly it
| shouldn't have happened to me either.
| sureglymop wrote:
| I'd be interested in more specifics here. I've been in a few
| bootloops with GrapheneOS early on but I've always been able to
| get out of them by keeping cool and not prematurely trying to
| reflash and wipe. Eventually the phone always booted (I think
| that it's due to the A/B partition system where eventually the
| phone will try to boot the other "working" partition again. But
| sometimes this would take a while).
|
| It hasn't happened in a year though and I've been happily
| upgrading lately. I'm not saying you couldn't have run into a
| unique bug but I'd find it surprising if your phone was really
| left completely bricked except for reflashing/wiping it.
| EffrafaxOfWug wrote:
| It was some time ago, so I unfortunately can't remember all
| the details. It occured during a normal system update that
| ran without problems at first, but when I rebooted the phone
| to finish the update it couldn't boot anymore (I can't
| remember the error messages). I don't know what exactly went
| wrong or was corrupted during the update. I definetly
| rebooted the phone multiple times and tried to fix the issue,
| but after some time I realized it was futile.
|
| Maybe there still was a way to salvage it, but I really can't
| tell in hindsight.
| sureglymop wrote:
| This has happened to me when the battery ran out during the
| reboot/upgrade. One time I had to let it charge and reboot
| for a good 30 minutes and eventually it booted again.
|
| I totally understand giving up there though as it sucks to
| not be able to use the phone for a while and is very
| inconvenient. Let alone if this happens at an inconvenient
| time/during a work day, etc.
| codethief wrote:
| I've been using GrapheneOS since the Pixel 3a and this is the
| first time I'm hearing of such an issue. To me, the ability to
| relock the bootloader and rely on verified boot is a big
| security advantage compared to other custom ROMs. I would not
| want to give that up lightly.
| strcat wrote:
| What you're describing is highly unusual and likely due to
| making changes to the OS. Hardly anyone has reported this kind
| of issue over the many years GrapheneOS has existed. A/B
| updates have automatic rollback if the OS doesn't boot to the
| home screen. If it doesn't boot all the way, then it's
| automatically completely undone by the firmware and all changes
| to OS data are undone because the data is initially mounted in
| a mode which only appends to the filesystem log and doesn't
| persist any of the changes. The update system is very robust
| and can handle an update not booting automatically. It's also
| very unlikely for updates not to boot properly considering that
| they're tested on each device model before reaching Alpha and
| then go through both public Alpha and Beta testing before the
| Stable channel.
|
| Leaving the device unlocked makes it far more likely something
| will go wrong and data will be lost. Disabling or revoking
| permissions from core system components which are not user-
| facing apps or making low-level changes with ADB to unsupported
| settings, etc. are other examples of how people can screw
| things up entirely on their own. If people disable something
| like the OS permission manager component and the OS can't boot
| anymore without a factory reset, that's not a bug. This is
| likely the kind of issue which happened to you.
|
| We recommend against using developer options on a production
| device, particularly making changes with ADB. We also recommend
| against disabling core system components or their permissions
| in the Settings app via the Show system menus. Android allows
| users to break the OS via developer options or disabling core
| system components. It may not happen until after a reboot or
| update. We don't think the Android Settings app should allow
| disabling as much as it does but we didn't design that and
| taking away options from people in the GUI would make a lot of
| people angry even if it can still be done via ADB.
|
| Not locking the device is an extremely poor security and
| robustness decision. It's not considered a completed GrapheneOS
| installation without locking.
|
| > but honestly it shouldn't have happened to me either
|
| It depends on what you changed. Android doesn't block power
| users from breaking the OS and needing a factory reset. That's
| not GrapheneOS specific. We did eliminate a few common ways
| people locked themselves out of their device like disabling the
| built-in keyboard if they use a different one which can then
| break or might not support running Before First Unlock via
| Direct Boot support.
| EffrafaxOfWug wrote:
| You are right, it may have been a unusual bug that hardly
| occurs, but it definitely happened to me. I also agree that
| having a unlocked bootloader is a security risk (how big of
| security risk depends on one's thread level I would say).
|
| I can't remember disabling any core system components,
| executing low level adb commands or any other unusual things
| which may have let to update breaking.
|
| I think the error message that I got was the "No valid
| operating system found" one. Maybe the issue would have
| resolved itself, if I had rebooted my phone a few times more,
| through the A/B slot mechanic. I honestly didn't know all
| this in that situation and only found some vague forum posts
| about it. I think it would have helped if there was a bit of
| official documentation about boot loops and what to do when
| one occurs on the graphene os website.
|
| The experience was for me a bit off putting because I lost
| some personal data (shame on me for not having proper
| backups), but after reading these comments I might try
| Graphene os again.
| gradeless wrote:
| Ive been using GrapheneOS for years and was in the chat rooms a
| fair bit, this isnt something common. Sounds like it may be
| hardware failing.
|
| Having bootloader locked you get verified boot, big security
| benefits and automatic healing of operating system files
| damaged by the drive degrading.
| sureglymop wrote:
| One cool thing about GrapheneOS when I recently got a new Pixel 9
| was how easy it was to install it with just my older Pixel phone.
| Because the installer is WebUSB based it works in the Vanadium
| browser. I just connected the two phones together with a USB
| cable and could install the OS on my new phone from the browser.
|
| One currently missing thing is a "transfer" or backup
| functionality otherwise. There's really no good solution other
| than to manually port over applications and use their built-in
| import/export features if available.
| strcat wrote:
| There's a built-in encrypted backup system in Settings > System
| > Backup. It works similarly to the Google Play device-to-
| device transfer system. It uses the same underlying device-to-
| device transfer mode for the Android backup infrastructure and
| should back up exactly the same data as the Google Play
| transfer system moves. It backs up a lot more than Google Play
| cloud backups because it uses device-to-device mode.
| NoImmatureAdHom wrote:
| I think GrapheneOS is one of the most important projects going.
| Many people walk around with all-purpose spying devices in their
| pocket, oblivious to how much power they are giving up. They have
| no control over these devices, and they don't even understand.
|
| GrapheneOS gives us a way to resist. The convenience of having a
| modern phone is hard to give up, and with GrapheneOS you can have
| 90% of that convenience while reducing much of the surveillance
| and attack surface. Now, we just need a pixel phone with two big
| hardware switches, sliders on each side of the phone: one kills
| the radios, and the other kills the sensors (cameras,
| microphones). When you want to take a call, just flip the big
| slider switch up to activate cameras and mics.
|
| Thank you to strcat and the rest of the team! If you don't use
| GrapheneOS, I would consider it. You can donate here:
| https://grapheneos.org/donate And if you have the right kind of
| programming skills, why not help out?
| strcat wrote:
| We plan to include a sensor kill switch on our own future
| hardware but the value is lower than most people believe on one
| of their primary computing devices. If it was successfully
| exploited, an attacker would get all of the data including
| documents, photos, videos, browser history, login sessions,
| passwords and much more. They'd also have control of the
| sensors whenever they're enabled including any calls, etc.
|
| A kill switch for all of the radios is much less useful for
| this threat model because even regular apps know how to queue
| up all their data for later usage. If the goal is preventing
| detection location detection, that really requires disabling
| all the radios and sensors rather than just radios. If the goal
| is dealing with an attacker able to exploit radio firmware but
| not the OS from there due to the IOMMU isolation and hardened
| kernel/userspace drivers in GrapheneOS, that could potentially
| be useful, but they'd already lose access on a reboot as long
| as it power cycled the radio as long as the radio doesn't have
| any significant persistent state due to verified boot.
| mystified5016 wrote:
| I really wanted to like Graphene, but it feels more locked down
| than stock android. The primary reason I want a custom OS in the
| first place is that I want to control the device I own.
|
| Graphene is just taking control of my phone from Google and
| giving it to whoever runs Graphene. I don't get any say in how my
| phone works.
|
| Graphene thinks you can't be trusted with your own device. But
| don't worry, they _definitely_ know what 's best for you and it's
| a _totally_ different kind of control from what Google has.
| Really, just trust them, it 's totally fine, promise.
|
| I switched to Lineage after a few months.
| gruez wrote:
| >I really wanted to like Graphene, but it feels more locked
| down than stock android. The primary reason I want a custom OS
| in the first place is that I want to control the device I own.
|
| What specific ways do you feel are "more locked down" than
| stock? It's not recommended, but you can install magisk + root
| if you really wanted to. It won't try to prevent you.
|
| >Graphene is just taking control of my phone from Google and
| giving it to whoever runs Graphene. I don't get any say in how
| my phone works.
|
| That's fine. The homepage of grapheneos says:
|
| "The private and secure mobile operating system with Android
| app compatibility"
|
| Surely you must understand that "security" and "giving users a
| say in how their phone works" are diametrically opposed? A
| phone can't be secure if its sandbox can be bypassed in one tap
| by the user. You might have a lot of say in how your linux
| system works, but don't kid yourself into thinking it's secure.
| It's only one `bash -c "$(curl -fsSL http://...` from getting
| pwned.
| NotPractical wrote:
| > "security" and "giving users a say in how their phone
| works" are diametrically opposed
|
| Try putting that sentence prominently on the front page of
| the GrapheneOS website and watch the monthly download count
| rapidly drop. It would not be out of place for an Apple press
| release, but it would be out of place there.
|
| I think the Graphene people sometimes forget that the vast
| majority of their users are nerds who aren't being targeted
| by APTs, don't want to be locked out of their own device, and
| really just want a trustworthy Google-free OS on their phone.
| They also probably use Linux on their computers and yet
| haven't been hacked by "fake sudo" or "evil maid" attacks and
| likely never will be.
|
| > It's not recommended, but you can install magisk + root if
| you really wanted to.
|
| Apps will then either detect that you're rooted, or use AOSP
| attestation APIs to cryptographically verify that you aren't
| using a known-good custom ROM, and block your access to basic
| features of modern society such as mobile banking. This isn't
| Graphene's fault, but it should be noted that you will start
| losing out on things as soon as you start customizing or
| rooting the OS. So it does matter what upstream does to some
| extent.
|
| FWIW I don't agree with the OP, just replying to your comment
| in particular.
| strcat wrote:
| > Try putting that sentence prominently on the front page
| of the GrapheneOS website and watch the monthly download
| count rapidly drop. It would not be out of place for an
| Apple press release, but it would be out of place there.
|
| We don't reduce the functionality or configuration of AOSP.
|
| > I think the Graphene people sometimes forget that the
| vast majority of their users are nerds who aren't being
| targeted by APTs
|
| The overall audience using it is not super technical. The
| community of people active in the chat rooms on Matrix and
| Discord really doesn't reflect the overall userbase. There
| are around 300k people using it, who largely went out of
| the way to purchase a phone for it and then installed it
| via the web installer. Many people also purchase devices
| with it preinstalled.
|
| It's easy to use and we're focused on making it easier
| including filling in gaps like the recently added network
| location support which will be added to the initial setup
| wizard.
|
| We also protect against a lot more than sophisticated
| targeted attacks against someone.
|
| > don't want to be locked out of their own device, and
| really just want a trustworthy Google-free OS on their
| phone.
|
| GrapheneOS exists to provide a high level of privacy and
| security while maintaining usability and app compatibility.
| It's working towards being as usable as the stock Pixel OS.
| It's meant to be an OS for everyone, we just don't have
| unlimited resources to quickly build most of the things we
| want. It has never been aimed at power users tinkering with
| and customizing their device. The level of functionality
| and usability we want to provide is the stock Pixel OS
| experience. Features unrelated to privacy or security which
| are not present in the stock Pixel OS are mostly out of
| scope.
|
| > They also probably use Linux on their computers and yet
| haven't been hacked by "fake sudo" or "evil maid" attacks
| and likely never will be.
|
| Software being open source doesn't mean it's trustworthy or
| privacy respecting. Running everything without basics like
| a strong app sandbox and permission model isn't a good idea
| on a desktop either. Linux doesn't imply not having a
| strong application security model.
|
| Supporting and normalizing applications depending on having
| incredibly invasive access where they can access all of the
| user's sensitive data, etc. is the opposite of what we want
| to do. We don't see apps being able to request more
| invasive permissions and refusing to work without them as
| user control. User control is being able to avoid that
| without the app knowing. Giving root access to a huge
| portion of the OS and to apps is the opposite of what we're
| building. You seem to want GrapheneOS to be something it's
| not for an audience that it's not targeting. We never said
| GrapheneOS is for power users who want to have a bunch of
| customization and to grant more invasive access to apps.
|
| GrapheneOS supports hardware-based virtualization across
| all the supported devices and that's the way people will be
| able to more freely do things like software development
| without compromising the security of the base OS.
|
| > Apps will then either detect that you're rooted, or use
| AOSP attestation APIs to cryptographically verify that you
| aren't using a known-good custom ROM, and block your access
| to basic features of modern society such as mobile banking.
| This isn't Graphene's fault, but it should be noted that
| you will start losing out on things as soon as you start
| customizing or rooting the OS. So it does matter what
| upstream does to some extent.
|
| Those apps wouldn't be willing to support GrapheneOS if we
| didn't maintain the standard security model. We're already
| going to be pushing the limits of what some apps will
| tolerate via our alternatives to permissions, etc. but we
| don't plan to eliminate parts of the security model. At the
| moment, nearly every app using the Play Integrity API would
| be willing to support GrapheneOS if they understood what it
| was and that they could verify it. It's an issue with lack
| of knowledge and unwillingness to do extra work for it
| rather than any apps actually wanting to ban GrapheneOS.
| It's something which can be addressed but it will get worse
| before it gets better as apps adopt the Play Integrity API.
| Growing the userbase by an order of magnitude or more will
| help solve this. Apps using the Play Integrity API are
| already feeling increasing pressure to permit using it and
| several have done so recently.
| NotPractical wrote:
| Thanks for your thought-provoking response. I agree with
| most of it.
|
| The vibe I generally get from Graphene users is that they
| feel that they are taking control over their device by
| installing Graphene onto it (which is almost always a
| manual process, at least for now). I probably exaggerated
| when I said the vast majority of users care deeply about
| this, but I think it's still a major selling point of
| Graphene for a lot of people.
|
| And yes, I do agree that sandboxing actually provides
| more control to the user, not less! I'd just hate to see
| Graphene become more like iOS over time and start
| intentionally omitting features that would otherwise
| empower the user, for security's sake. If "security" and
| "giving users a say in how their phone works" really are
| diametrically opposed, and user freedom isn't a concern,
| then it would probably make sense to start gutting out
| stuff like developer mode, adb, and sideloading for the
| user's own safety. But the project's track record has
| been pretty good so far from what I can tell, and I don't
| think this will happen.
| miramba wrote:
| I installed GrapheneOS on a spare Pixel 4a recently...through a
| browser window. I thought at first that I had to download a
| firmware flasher or something, but no, it updated the device from
| that webpage! That was impressive. The other thing I would like
| to mention: Chromium is installed, so PWAs can be installed
| instead of connecting to a sandboxed google play or something.
| The PWAs I tried looked just like on an iPhone or desktop. Yes,
| we are far, far away from PWAs being a complete replacement. But
| it is in theory possible:
|
| An independent mobile OS with platform-independent apps. No
| Apple/Google ID needed, no appstores. That was the point of this
| test install, and it worked.
| Hj8Rd2Qw wrote:
| Impressive to see GrapheneOS's strong app sandbox model
| preventing malicious apps from evading uninstallation. This kind
| of robust security architecture is what Android needs -
| protection that works even when apps have dangerous permissions
| or exploit security vulnerabilities.
___________________________________________________________________
(page generated 2025-04-13 23:00 UTC)