7 ms·

GrapheneOS is so far ahead in terms of security than anything else that it makes chosing anything but pixel hardware really questionable. But I REALLY want repl

by dtx1 3y ago

GrapheneOS is so far ahead in terms of security than anything else that it makes chosing anything but pixel hardware really questionable. But I REALLY want replaceable batteries. Why does everything have to suck nowadays?

master-lincoln 3y ago
[flagged]
wafflemaker 3y ago
Wouldn't ripping out the backplate make the battery replacable?* Never heard of Google making installation of non genuine components hard the way Apple does. *If your hands are too clumsy to reconnect battery wires when swapping batteries, get a swiss knife.
- dtx1 3y ago
  In newer pixel models, everything is glued together. The Backplate is glued to the front, the battery is glued in so hard you can barely remove it and on top of it there's a graphene pad glued ontop of it for cooling reasons. Look at this: https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacement/166180 https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem... That's not "swiss knife" replacement.
  - wafflemaker 3y ago
    Wow. I genuinely thought that the replacement process was maybe a little more complicated than on the Samsung Note from 8 years ago that I did myself. That if you just ripped out the backplate you could have an ugly phone (not water resistant either) with a replacable battery. This complicated, time consuming and requiring specialized equipment process is not what I expected. Especially the part where you have to replace the screen you've just broken. Now I concur with the original poster in his lament on lack of new and fancy, yet fully owned by the user, phones that can cooperate with Graphene OS
    - strcat 3y ago
      > GOS's limited device support is disappointing, but I understand their reasoning. Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking. > I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware. It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.). Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
- perlclutcher 3y ago
  It's not that easy. https://www.ifixit.com/repairability/smartphone-scores https://www.ifixit.com/repairability/smartphone-scores > The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced. You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.
Sytten 3y ago
Agreed but they do drop support for older pixel devices very very quickly which is kinda of PITA. At least the Pixel 8 is supposed to be supported 7 years.
- freedomben 3y ago
  Just a point of clarity, GrapheneOS has the same support window that Google does, so they're not dropping support earlier than the vendor. The reason they drop support is because the burden of supporting an EOL device is way, way higher, especially for a security-oriented OS.
  - SushiHippie 3y ago
    Though the pixel 4 still gets updates from GrapheneOS, which didn't receive updates since October 2022 from Google. So they support it even a bit longer than google officially does.
    - strcat 3y ago
      Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.
  - chasil 3y ago
    Taking the "vendor security patch level" into account, it is impossible in some situations. If a critical vulnerability is found in a Qualcomm modem, wifi, or bluetooth firmware, there may be scenarios where this cannot be fixed at the OS level.
    - 3y ago
perlclutcher 3y ago
GOS's limited device support is disappointing, but I understand their reasoning. I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware. As an alternative to replaceable batteries you could consider installing something like acc[1] to mitigate stress on your battery. My phone is 7 years old and the original battery still holds a charge like the day I bought it. [0]: https://github.com/uBlockOrigin/uBlock-issues/discussions/2261 https://github.com/uBlockOrigin/uBlock-issues/discussions/22... [1]: https://github.com/VR-25/acc https://github.com/VR-25/acc
- strcat 3y ago
  > GOS's limited device support is disappointing, but I understand their reasoning. Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking. > I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware. It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.). Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
IshKebab 3y ago
Well, maybe. But in this case I think the MTE work is in AOSP and they just turned it on.
- strcat 3y ago
  No, that's not at all the case. We made our own MTE implementation for our hardened_malloc project with significantly stronger security properties. We had to fix multiple bugs in the OS and with Chromium's MTE integration to enable it for Vanadium in PartitionAlloc. We do currently simply use the standard implementation in PartitionAlloc but we plan to improve that since it's missing security properties we have in hardened_malloc. We also had to implement a system for per-app MTE control and an MTE crash reporting system. The current kernel KASan MTE backend is inadequate for usage of MTE as a hardening feature so we either need to make our own implementation there too or convince others to do it and it's likely not going to be the latter. ARM did the work of designing it and integrating it into their standard ARM Cortex core/cache designs. Google/Samsung did the work of preserving standard ARM functionality, unlike Qualcomm which currently loses it. Google/Samsung also had to integrate it into the boot chain. They'd already previously done most of the bug fixing work via testing with HWASan. It is certainly true that Google paved the way to use MTE with HWASan and did a lot of the bug fixing work in the OS but external security researchers did a lot of this work too.
actionfromafar 3y ago
These phone cases with an integrated battery pack goes a long way towards replaceable batteries if you keep a stack of them. They probable put less strain and wear on the built-in battery too.
- dtx1 3y ago
  > They probable put less strain and wear on the built-in battery too. Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.
  - alex-robbins 3y ago
    This is false. It's true that staying at 100% is harder on lithium ion batteries than staying at 40%. However, the wear due to charge cycles is way, way more significant. Your battery will see much less wear if you keep it at 100% for some time vs discharging and recharging it a few times between (e.g.) 40% and 80% during that same time.
  - actionfromafar 3y ago
    I don't know how they do it, but some of these cases keep the phone at below 100%.
  - worewood 3y ago
    My S20 has an option to limit charge to 85%. It's already a reality.
Tijdreiziger 3y ago
They seem to have long-standing problems with emergency services, though. https://www.reddit.com/r/GooglePixel/search/?q=emergency https://www.reddit.com/r/GooglePixel/search/?q=emergency
- izacus 3y ago
  Those posts are mostly more than a year old and many of those end up being VoLTE misconfiguration on carrier side which sadly affects many more phones than just pixels, e.g. iPhones too: https://www.reddit.com/r/iphone/comments/ynuu6c/newer_iphone_cant_call_911/ https://www.reddit.com/r/iphone/comments/ynuu6c/newer_iphone... VoLTE in general is quite the trash fire.
nelblu 3y ago
Not exaxtly grapheneOS but close enough CalyxOs has started supporting Fairphone 5 and it has replaceable batteries AFAIK: https://calyxos.org/news/2024/03/05/fp5/ https://calyxos.org/news/2024/03/05/fp5/
- dtx1 3y ago
  Looking into that as an alternative for my dying pixel 3a but CalyxOS is to GrapheneOS what OpenBSD is to fedora when it comes to security. Both are good for updates and common security features but grapheneos has implemented security features that are a decade ahead of other Androids. Hardened Malloc, Playstore Sandbox instead of MicroG, Memory Tagging extensions, Selinux, bootloader Security, etc.
  - deleted 3y ago
    [deleted]
- strcat 3y ago
  GrapheneOS and CalyxOS are very different. GrapheneOS is a hardened OS with substantial privacy/security improvements: https://grapheneos.org/features https://grapheneos.org/features CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches. CalyxOS does not have features like this. It does the opposite of this. Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer: https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach. https://eylenburg.github.io/android_comparison.htm https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point. https://privsec.dev/posts/android/choosing-your-android-based-operating-system/ https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
- acqbu 3y ago
  CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.
strcat 3y ago
Pixels are currently the only devices meeting our security requirements. Other Android devices don't even come close. Hardware memory tagging support is one of many major security advantages of Pixels. Our official list of hardware requirements is available here: https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. These requirements are fully provided by 8th generation Pixels. 6th/7th generation Pixels are only missing MTE, BTI and PAC but MTE is the most valuable feature on the list of hardware requirements. Proper security patches are even more important, which are not available in the same way outside Pixels. Android has monthly, quarterly and yearly releases. Other Android OEMs only ship the monthly security backports with only all of the Critical/High severity fixes, not most of the Moderate/Low severity fixes including most privacy fixes. This is PARTLY addressed by using an alternate OS shipping these patches, but every alternate OS available for those devices rolls back security in a lot of ways. Firmware and a lot of the device support code comes from the OEM in practice. Running Android 14 QPR2 on top of Android 12 kernel / drivers is possible but will be missing the security improvements for a huge portion of the OS. The batteries in Pixels aren't trivial to replace without damaging the device, but it's officially supported and there are official parts available: https://www.ifixit.com/Device/Google_Pixel https://www.ifixit.com/Device/Google_Pixel We simply can't support insecure devices without the basics. Our hardware requirement list includes very basic things not provided by most Android OEMs along with more advanced features such as MTE which we now consider basic requirements for decent security. We want to support other devices, but those devices must meet these requirements. Memory tagging is a baseline feature supported by standard Cortex ARMv9 cores. It's unfortunate that Qualcomm is not implementing support for it and that OEMs using an SoC supporting it are not bothering to set it up. It's sad having a feature available in the CPU architecture that's not usable due to the SoC or OEM.
- dtx1 3y ago
  Thanks for the detailed explanation and i totally agree, it's not something i expect from graphene os, it's something that annoys me from googles pixels. I hope the new EU requirements to make reasonable battery swaps a thing means i get the best of both worlds.
craftkiller 3y ago
Don't worry, GrapheneOS will drop support for your device before you need a battery replacement. (They support devices for slightly longer than the devices are supported upstream)
- oynqr 3y ago
  Are you telling me my battery is going to last more than seven years?
resource_waste 3y ago
I have a super expensive secret on my phone and... I bend the knee to Google. Def can't trust Apple, can't trust Samsung. Google has managed to be the best. (Go ahead and @ me some cases that basically never hit the wild)
- ForHackernews 3y ago
  I can't imagine the threat model that leads you to trust Google but not Apple, but you do you: Maybe you're a Google hardware engineer and the expensive secret is blueprints for the next generation of Google Glass.
  - resource_waste 3y ago
    Buddy, 1000+ people got their iPhones cracked by pegasus, at least 1 person was killed and bezos had his noods leaked. Yeah google does a better job.
    - ForHackernews 3y ago
      I'm not worried about being targeted by Pegasus, but I am worried about getting targeted for adshit by Google, or them selling all my info to databrokers, or having them disable all my accounts for arbitrary reasons. I think we have different threat models. Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.
      - resource_waste 3y ago
        Yes, my super expensive secret is way more valuable than getting ads about my hemorrhoids.
        ForHackernews 3y ago
        You know they have secure drives, right? I wouldn't carry anything I really cared about around on my phone. ... oh this is some cryptocurrency thing, isn't it?

by dtx1 3y ago

master-lincoln 3y ago

[flagged]

wafflemaker 3y ago

Wouldn't ripping out the backplate make the battery replacable?* Never heard of Google making installation of non genuine components hard the way Apple does. *If your hands are too clumsy to reconnect battery wires when swapping batteries, get a swiss knife.

dtx1 3y ago
In newer pixel models, everything is glued together. The Backplate is glued to the front, the battery is glued in so hard you can barely remove it and on top of it there's a graphene pad glued ontop of it for cooling reasons. Look at this: https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacement/166180 https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem... That's not "swiss knife" replacement.
- wafflemaker 3y ago
  Wow. I genuinely thought that the replacement process was maybe a little more complicated than on the Samsung Note from 8 years ago that I did myself. That if you just ripped out the backplate you could have an ugly phone (not water resistant either) with a replacable battery. This complicated, time consuming and requiring specialized equipment process is not what I expected. Especially the part where you have to replace the screen you've just broken. Now I concur with the original poster in his lament on lack of new and fancy, yet fully owned by the user, phones that can cooperate with Graphene OS
  - strcat 3y ago
    > GOS's limited device support is disappointing, but I understand their reasoning. Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking. > I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware. It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.). Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
perlclutcher 3y ago
It's not that easy. https://www.ifixit.com/repairability/smartphone-scores https://www.ifixit.com/repairability/smartphone-scores > The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced. You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.

Sytten 3y ago

Agreed but they do drop support for older pixel devices very very quickly which is kinda of PITA. At least the Pixel 8 is supposed to be supported 7 years.

freedomben 3y ago
Just a point of clarity, GrapheneOS has the same support window that Google does, so they're not dropping support earlier than the vendor. The reason they drop support is because the burden of supporting an EOL device is way, way higher, especially for a security-oriented OS.
- SushiHippie 3y ago
  Though the pixel 4 still gets updates from GrapheneOS, which didn't receive updates since October 2022 from Google. So they support it even a bit longer than google officially does.
  - strcat 3y ago
    Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.
- chasil 3y ago
  Taking the "vendor security patch level" into account, it is impossible in some situations. If a critical vulnerability is found in a Qualcomm modem, wifi, or bluetooth firmware, there may be scenarios where this cannot be fixed at the OS level.
  - 3y ago

perlclutcher 3y ago

GOS's limited device support is disappointing, but I understand their reasoning. I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware. As an alternative to replaceable batteries you could consider installing something like acc[1] to mitigate stress on your battery. My phone is 7 years old and the original battery still holds a charge like the day I bought it. [0]: https://github.com/uBlockOrigin/uBlock-issues/discussions/2261 https://github.com/uBlockOrigin/uBlock-issues/discussions/22... [1]: https://github.com/VR-25/acc https://github.com/VR-25/acc

strcat 3y ago
> GOS's limited device support is disappointing, but I understand their reasoning. Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking. > I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware. It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.). Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.

IshKebab 3y ago

Well, maybe. But in this case I think the MTE work is in AOSP and they just turned it on.

strcat 3y ago
No, that's not at all the case. We made our own MTE implementation for our hardened_malloc project with significantly stronger security properties. We had to fix multiple bugs in the OS and with Chromium's MTE integration to enable it for Vanadium in PartitionAlloc. We do currently simply use the standard implementation in PartitionAlloc but we plan to improve that since it's missing security properties we have in hardened_malloc. We also had to implement a system for per-app MTE control and an MTE crash reporting system. The current kernel KASan MTE backend is inadequate for usage of MTE as a hardening feature so we either need to make our own implementation there too or convince others to do it and it's likely not going to be the latter. ARM did the work of designing it and integrating it into their standard ARM Cortex core/cache designs. Google/Samsung did the work of preserving standard ARM functionality, unlike Qualcomm which currently loses it. Google/Samsung also had to integrate it into the boot chain. They'd already previously done most of the bug fixing work via testing with HWASan. It is certainly true that Google paved the way to use MTE with HWASan and did a lot of the bug fixing work in the OS but external security researchers did a lot of this work too.

actionfromafar 3y ago

These phone cases with an integrated battery pack goes a long way towards replaceable batteries if you keep a stack of them. They probable put less strain and wear on the built-in battery too.

dtx1 3y ago
> They probable put less strain and wear on the built-in battery too. Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.
- alex-robbins 3y ago
  This is false. It's true that staying at 100% is harder on lithium ion batteries than staying at 40%. However, the wear due to charge cycles is way, way more significant. Your battery will see much less wear if you keep it at 100% for some time vs discharging and recharging it a few times between (e.g.) 40% and 80% during that same time.
- actionfromafar 3y ago
  I don't know how they do it, but some of these cases keep the phone at below 100%.
- worewood 3y ago
  My S20 has an option to limit charge to 85%. It's already a reality.

Tijdreiziger 3y ago

They seem to have long-standing problems with emergency services, though. https://www.reddit.com/r/GooglePixel/search/?q=emergency https://www.reddit.com/r/GooglePixel/search/?q=emergency

izacus 3y ago
Those posts are mostly more than a year old and many of those end up being VoLTE misconfiguration on carrier side which sadly affects many more phones than just pixels, e.g. iPhones too: https://www.reddit.com/r/iphone/comments/ynuu6c/newer_iphone_cant_call_911/ https://www.reddit.com/r/iphone/comments/ynuu6c/newer_iphone... VoLTE in general is quite the trash fire.

nelblu 3y ago

Not exaxtly grapheneOS but close enough CalyxOs has started supporting Fairphone 5 and it has replaceable batteries AFAIK: https://calyxos.org/news/2024/03/05/fp5/ https://calyxos.org/news/2024/03/05/fp5/

dtx1 3y ago
Looking into that as an alternative for my dying pixel 3a but CalyxOS is to GrapheneOS what OpenBSD is to fedora when it comes to security. Both are good for updates and common security features but grapheneos has implemented security features that are a decade ahead of other Androids. Hardened Malloc, Playstore Sandbox instead of MicroG, Memory Tagging extensions, Selinux, bootloader Security, etc.
- deleted 3y ago
  [deleted]
strcat 3y ago
GrapheneOS and CalyxOS are very different. GrapheneOS is a hardened OS with substantial privacy/security improvements: https://grapheneos.org/features https://grapheneos.org/features CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches. CalyxOS does not have features like this. It does the opposite of this. Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer: https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach. https://eylenburg.github.io/android_comparison.htm https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point. https://privsec.dev/posts/android/choosing-your-android-based-operating-system/ https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
acqbu 3y ago
CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.

strcat 3y ago

Pixels are currently the only devices meeting our security requirements. Other Android devices don't even come close. Hardware memory tagging support is one of many major security advantages of Pixels. Our official list of hardware requirements is available here: https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. These requirements are fully provided by 8th generation Pixels. 6th/7th generation Pixels are only missing MTE, BTI and PAC but MTE is the most valuable feature on the list of hardware requirements. Proper security patches are even more important, which are not available in the same way outside Pixels. Android has monthly, quarterly and yearly releases. Other Android OEMs only ship the monthly security backports with only all of the Critical/High severity fixes, not most of the Moderate/Low severity fixes including most privacy fixes. This is PARTLY addressed by using an alternate OS shipping these patches, but every alternate OS available for those devices rolls back security in a lot of ways. Firmware and a lot of the device support code comes from the OEM in practice. Running Android 14 QPR2 on top of Android 12 kernel / drivers is possible but will be missing the security improvements for a huge portion of the OS. The batteries in Pixels aren't trivial to replace without damaging the device, but it's officially supported and there are official parts available: https://www.ifixit.com/Device/Google_Pixel https://www.ifixit.com/Device/Google_Pixel We simply can't support insecure devices without the basics. Our hardware requirement list includes very basic things not provided by most Android OEMs along with more advanced features such as MTE which we now consider basic requirements for decent security. We want to support other devices, but those devices must meet these requirements. Memory tagging is a baseline feature supported by standard Cortex ARMv9 cores. It's unfortunate that Qualcomm is not implementing support for it and that OEMs using an SoC supporting it are not bothering to set it up. It's sad having a feature available in the CPU architecture that's not usable due to the SoC or OEM.

dtx1 3y ago
Thanks for the detailed explanation and i totally agree, it's not something i expect from graphene os, it's something that annoys me from googles pixels. I hope the new EU requirements to make reasonable battery swaps a thing means i get the best of both worlds.

craftkiller 3y ago

Don't worry, GrapheneOS will drop support for your device before you need a battery replacement. (They support devices for slightly longer than the devices are supported upstream)

oynqr 3y ago
Are you telling me my battery is going to last more than seven years?

resource_waste 3y ago

I have a super expensive secret on my phone and... I bend the knee to Google. Def can't trust Apple, can't trust Samsung. Google has managed to be the best. (Go ahead and @ me some cases that basically never hit the wild)

ForHackernews 3y ago
I can't imagine the threat model that leads you to trust Google but not Apple, but you do you: Maybe you're a Google hardware engineer and the expensive secret is blueprints for the next generation of Google Glass.
- resource_waste 3y ago
  Buddy, 1000+ people got their iPhones cracked by pegasus, at least 1 person was killed and bezos had his noods leaked. Yeah google does a better job.
  - ForHackernews 3y ago
    I'm not worried about being targeted by Pegasus, but I am worried about getting targeted for adshit by Google, or them selling all my info to databrokers, or having them disable all my accounts for arbitrary reasons. I think we have different threat models. Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.
    - resource_waste 3y ago
      Yes, my super expensive secret is way more valuable than getting ads about my hemorrhoids.
      - ForHackernews 3y ago
        You know they have secure drives, right? I wouldn't carry anything I really cared about around on my phone. ... oh this is some cryptocurrency thing, isn't it?