[HN Gopher] Graphene OS: a security-enhanced Android build
___________________________________________________________________
Graphene OS: a security-enhanced Android build
Author : madars
Score : 671 points
Date : 2025-07-24 21:48 UTC (1 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| ranger_danger wrote:
| Maybe my tinfoil hat is on too tight, but I always thought it was
| interesting that Graphene OS places so much blind trust in a
| proprietary black box security chip from Google that they pinky-
| promised to open source but never did.
| sigmar wrote:
| Are you referring to the titan M2? why do you describe Graphene
| OS putting "so much blind trust in" it? I don't think they put
| much trust in it besides using it for storing keys and for
| their "Auditor" app
| TheCraiggers wrote:
| > I don't think they put much trust in it besides using it
| for storing keys
|
| Ummm. Was this sarcasm that went over my head? Because if
| not, I have a hard time thinking of anything that requires as
| much trust as your private key storage.
| bjackman wrote:
| If you think the org that produced the hardware might have
| backdoored it, architecting your software to avoid the TPM or
| whatever is dumb. Targeting Google HW at all is an unavoidable
| act of complete trust so you might as well use the HW properly.
|
| Also, why would Google bother backdooring their special HW when
| 99.999% of its users are anyway gonna be running a totally
| Google-controlled proprietary SW stack?
| perching_aix wrote:
| > Targeting Google HW at all is an unavoidable act of
| _complete_ trust
|
| Doesn't the existence of FHE downgrade that to _just_
| "complete practical trust" at least? Not that I know of it
| being employed, but that it could be, and that it may be
| worth shouting out exactly cause of how niche and impractical
| it is.
| bjackman wrote:
| We are talking about hardware here so ultimately you need
| to trust some manufacturer, software algorithms don't help.
|
| With SEV-SNP and Intel TDX I think it's possible to build a
| hardware platform that doesn't require the user to trust
| the OEM although they still need to trust at least one
| large American tech company that controls the root of
| trust.
|
| But I don't think this is ever gonna happen for consumer
| devices. AFAIK it's only sorta kinda happened for any real-
| world platforms at all (but maybe someone can correct me).
|
| Ultimately if your threat model includes Google as a
| potential adversary, and you are not in control of nuclear
| weapons, you are gonna have to make some serious sacrifices
| to achieve security IMO. Smartphones are out. (Actually, I
| guess if you trust China you have a way forward).
| XMPPwocky wrote:
| How is it a black box? You can get the firmware trivially.
| TheCraiggers wrote:
| Because they are a software project. When you're only
| concerning yourself with software, you have to pick some
| hardware and move on.
|
| Going down the rabbit hole of secure hardware leads you down a
| slippery slope of eventually needing to create your own chips.
| And that's basically impossible these days for anybody smaller
| than Google or Samsung. So you do some research, pick the best
| you can, and hope for the best.
|
| Perfect is the enemy of good.
| transpute wrote:
| OpenTitan has open silicon (RISC-V) and is capable of open
| firmware (based on Rust TockOS) and is coming to 2025
| Chromebooks, https://news.ycombinator.com/item?id=44416304.
| Hopefully a derivative of OpenTitan will ship in future Pixel
| devices.
|
| Google Pixel hardware provides nested virtualization, enabling
| a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of
| Debian package repos.
| JacobThreeThree wrote:
| You're worried about Google hardware but your requirement for a
| phone is that it must have Google Pay? Bizarre.
| z3c0 wrote:
| I think Graphene gets posted here yearly. Having tested a variety
| of ROMs dedicated to different elements of security, I can attest
| that Graphene allows the most "normal" phone usage compared to
| many others. The biggest factor is the sandboxed Google Play
| Services, which allow you to use a lot of apps that you wouldn't
| be able to otherwise.
|
| I've used Lineage without MicroG, as a comparison, and that's
| becoming more-and-more unusable every day some lousy Android
| developer tethers their company's app to some feature exclusive
| to Play Services.
| ranger_danger wrote:
| unfortunately it doesn't support google pay, which is a
| dealbreaker for me
| mbananasynergy wrote:
| Google Pay is not available on any alternative OS due to
| Google blocking it. It's unfortunately their choice, rather
| than a lack of support on our end.
|
| Depending on where you are in the world, there might be other
| NFC payment options for you.
|
| In the EEA and UK, Curve pay works. Paypal made their own
| solution and is rolling it out, starting with Germany. Both
| work with GrapheneOS. Many banks also have their own
| solutions.
| DANmode wrote:
| Phone-wallet case.
| nicman23 wrote:
| yeah but lineageos with mg is quite good.
| SchwKatze wrote:
| My only problem with Graphene is the ridiculous low number of
| supported devices, i know I know, security reasons and so on. But
| I would accept an lower security hardened version but at least
| have Graphene instead of Google's junk
| metalman wrote:
| https://calyxos.org/ does a few other devices, seems aimed
| strait at true privacy
| mbananasynergy wrote:
| GrapheneOS community manager here.
|
| I would recommend checking out
| https://eylenburg.github.io/android_comparison.htm for a
| third-party comparison of these projects. They're not really
| similar.
|
| CalyxOS downgrades security compared to the Android Open
| Source Project, often falls significantly behind on standard
| Android privacy and security patches as is the case right now
| (they still haven't ported to Android 16 which is required to
| have the latest patches) and doesn't provide similar privacy
| or security features.
|
| Features like Contact Scopes, Storage Scopes and our Sensors
| permission toggle are some of the privacy features includes
| in GrapheneOS.
|
| Privacy necessitates security. The security provided by
| GrapheneOS is in order to be able to protect privacy.
| spaqin wrote:
| According to the link you provided, it does seem to be
| ahead of stock Android (assuming AOSP) and LineageOS,
| disproving your point that it's falling behind.
|
| The point of the OP is not that it would be better than
| your solution anyway; rather, if you have a device
| unsupported by GrapheneOS, Calyx would be better than
| nothing.
| rfoo wrote:
| > Calyx would be better than nothing.
|
| Depends on your threat model. If Google, low-effort scam
| apps or being profiled by apps are your only adversary,
| then that's true. If random threats on Internet or APTs
| pwning your phone, or being forensic-proof are part of
| your threat model, then Calyx is strictly _worse_ than
| stock.
| strcat wrote:
| > According to the link you provided, it does seem to be
| ahead of stock Android (assuming AOSP) and LineageOS,
| disproving your point that it's falling behind.
|
| The table shows CalyxOS has substantial delays for
| important privacy and security patches. It currently
| doesn't provide the 2025-06-05 patch level. It's better
| than LineageOS and /e/OS in that regard but still reduces
| privacy and security through significantly delayed
| patches. CalyxOS also weakens parts of the privacy and
| security model through the privileged functionality
| that's added, which simply isn't covered by the
| comparison table.
|
| > The point of the OP is not that it would be better than
| your solution anyway; rather, if you have a device
| unsupported by GrapheneOS, Calyx would be better than
| nothing.
|
| On Pixels, CalyxOS is missing current Android
| privacy/security patches. GrapheneOS doesn't support
| those other devices due to lack of a reasonable level of
| security. Each of those extra devices has significantly
| delayed privacy/security patches and lacks important
| hardware-based security features. Despite all the
| marketing about long term support, Fairphone 5 uses Linux
| 5.4 which is end-of-life in December 2025 with no plans
| on their part to move to a supported kernel branch
| afterwards. Earlier Fairphones are stuck on older end-of-
| life kernel branches. Those devices are missing basic
| updates and security protections. Those don't provide
| proper long term support, so if someone does have one it
| won't be long before it's time to buy another device.
| pshirshov wrote:
| > The security provided by GrapheneOS is in order to be
| able to protect privacy.
|
| But there is still no way to reset/spoof android device
| ids, and the apps can reliably identify the user after
| reinstalls.
| strcat wrote:
| Hardware identifiers aren't accessible to user installed
| apps. ANDROID_ID is a per-app-per-profile random ID. Apps
| don't need ANDROID_ID to identify that it's the same
| install due to immense fingerprint surface. If you
| installed the app in another profile, it would have a
| different ANDROID_ID, but it would still potentially be
| able to fingerprint it as the same device based on many
| things like settings. GrapheneOS does have planned
| features to improve these things but it's not nearly as
| simple as making ANDROID_ID per-app-install or making the
| MediaDRM ID more randomized than the current per-app
| random value (it was meant to be like ANDROID_ID but they
| make a mistake that's hard to fix without breaking
| compatibility so we need a toggle).
| bubblethink wrote:
| What's ridiculous about it ? There are now 4-5 gens of Pixels
| with their major/minor bumps too (A series, pro, etc.). There's
| enough variety at different price points for everyone there.
| konstantinua00 wrote:
| 4-5 versions of the same phone in the gigantic sea of
| possible devices
| bubblethink wrote:
| The other devices don't meet the criteria. Be happy that
| Pixels are supported, for Google seems to closing down
| Pixel OS too, making this whole effort rather difficult.
| konstantinua00 wrote:
| > The other devices don't meet the criteria
|
| you got it wrong way around
|
| the CONSUMER criteria is "we want better independent
| security ON DEVICES WE ALREADY OWN"
|
| complaints like in this thread are symptoms of
| unfullfilled demand - and they can't be solved by saying
| "oh gosh, what a stupid demand that doesn't agree with
| our supply"
| cwillu wrote:
| Nobody said it was stupid, but you wanting something
| doesn't make it a requirement for a project with
| different goals.
| homarp wrote:
| car analogy: I want my gazoline car to have hybrid
| engine. For free.
|
| vendor: not possible
|
| you: unfulfilled demand
|
| me: the way I see it, you get a product for free if you
| fulfill certain conditions. If not, you buy these
| conditions.
| Attrecomet wrote:
| What a bad analogy, acting as if the extra security could
| only be an all-in.
| palata wrote:
| There are hardware requirements.
| rambambram wrote:
| I was going to type something, but upon a second read I
| see you say 'consumer' instead of 'customer'. Fair
| enough.
| mbananasynergy wrote:
| GrapheneOS community manager here. Google's devices are
| currently the only ones that meet our requirements
| (https://grapheneos.org/faq#future-devices).
|
| However, we're currently working with another OEM and are
| hoping to have a device of theirs meet our requirements that
| can be launched in 2026 or 2027. Nothing set in stone, but
| we're optimistic thus far.
| zvmaz wrote:
| If it's a repairable phone like the Fairphone, that would be
| fantastic. Otherwise, I'm already very satisfied with what
| you offer. Thanks for you work.
| mbananasynergy wrote:
| Fairphone do not meet our requirements and haven't really
| been trending towards meeting them generation-by-
| generation. It doesn't seem to be something that interests
| them.
|
| The unfortunate thing is that they make security promises
| which aren't upheld in practice (such as shipping security
| updates on time), so it doesn't inspire confidence as an
| OEM you could trust to properly support a device for
| multiple years.
|
| We're hoping that there will be people who will enjoy a
| device from the OEM we're in talks with - we know that
| there are many people who for various reasons don't want a
| device from Google, so this will at least offer an option
| for people who want to use GrapheneOS on a non-Google
| device.
| hsbauauvhabzb wrote:
| I got curious and found this:
| https://discuss.grapheneos.org/d/7208-8y-security-
| updates-on...
|
| At the risk of doing their work for them, that seems like
| a near ideal partnership opportunity for graphene, so
| it's extra sad to see.
| mbananasynergy wrote:
| It's important to note that these "8 years" aren't
| actually that in practice due to the delays. The latest
| generations of Pixels (starting with the 8th) have 7
| years of actual security updates, which is one year less,
| but is proper support. Hopefully the industry trends
| towards that as a whole - buying devices that only get
| 2-3 years of updates should be a thing of the past.
| rjzzleep wrote:
| Isn't that related to how expensive it is to get licenses
| from MTK and Qualcomm for updates? Given that Pixels run
| on their "own" chip, driver support is probably much
| easier.
| strcat wrote:
| Fairphone devices have 1-2 month delays for partial
| security patches. They have a year or more of delays for
| new major releases. Their recent Fairphone 5 uses the
| Linux 5.4 LTS branch going end-of-life in December 2025
| with no plan to port to a new LTS branch. Their past
| devices use end-of-life Linux kernel branches. They do
| not provide the expected security patches even shortly
| after release. They aren't doing the bare minimum and
| aren't even compliant with recent EU regulations for
| device updates.
|
| Google provided resources for the Linux kernel to extent
| LTS support for 6 years for their 5 year guarantee with
| the Pixel 6. It ended up not being needed since Pixels
| began moving to newer Linux LTS branches. The official
| Linux kernel LTS support is back down to 2 years. The 6
| years was meant to benefit all Android devices but it
| proved to be too difficult to do well and it makes more
| sense to invest a far smaller amount of resources moving
| to new LTS branches.
|
| Fairphone presents providing an Android OS release 3
| years after it was released as providing 3 more years of
| extra support compared to an OEM releasing it in the
| month it was launched as their final update. That doesn't
| make sense.
|
| They've repeatedly had blatant security flaws such as
| using publicly available private keys for signing the OS
| on the Fairphone 4. These issues are downplayed rather
| than being acknowledged.
|
| There are important security features missing, but the
| main issues are the lack of proper updates and their
| approach to security flaws being reported and discussed.
|
| Many Android OEMs are a better fit for a partnership with
| us and we're working with one.
|
| https://discuss.grapheneos.org/d/24134-devices-lacking-
| stand... is a better thread about this than the one you
| linked.
| hsbauauvhabzb wrote:
| That looks like a real shame and granted not the fault of
| graphene.
| mixmastamyk wrote:
| Why would their OS patches effect your different OS? It
| would be hardware you're supporting, no?
| benreesman wrote:
| Extremely happy GrapheneOS user here. Thank you so much for
| the work you and your colleagues do. Speaking for myself, the
| adoption of a mobile communication and computing choice that
| both put me in control of what information I interact with
| and respects my agency enough to present me with the hard
| choices about what I do and don't want for myself has been a
| life-altering upgrade in something midway between "peace of
| mind" and "outright mental health".
|
| Much like you don't hear the sound of a busy city until you
| go somewhere truly quiet, you don't remember owning your own
| brain until you evict all of the entities who have been
| living rent free in it.
|
| Keep doing the great work you're doing: it's making people's
| lives better in dramatically more significant ways than most
| software.
| mbananasynergy wrote:
| We really appreciate the kind words!
| _blk wrote:
| I can only attest to that. Been using it for 3 years on a
| Pixel 6a. The only thing I'd wish for, is a scrolling PDF
| viewer.
|
| In any case, thank you for all the work so far!
| shlip wrote:
| Librera Reader has a scroll mode : https://f-droid.org/en
| /packages/com.foobnix.pro.pdf.reader/
| orbisvicis wrote:
| I'm working my way down your requirements.
|
| > Hardware memory tagging
|
| I had to Google this. Is this like a fine-grained version of
| mprotect, i.e. associated permissions with each tag? Or are
| you only interested in the memory safety benefits?
| Regardless, why target requirements that even most desktop
| computers don't meet?
| transpute wrote:
| MTE is an Arm v9 feature subset of CHERI,
| https://news.ycombinator.com/item?id=30007474 |
| https://armor.ch/mte/hw
|
| https://discuss.grapheneos.org/d/8439-mte-support-status-
| for...
|
| _> Hardware memory tagging is going to provide a massive
| increase to protection against remote exploitation for
| GrapheneOS users. It 's the biggest security feature we'll
| be shipping since we started in 2014._
| strcat wrote:
| > Is this like a fine-grained version of mprotect, i.e.
| associated permissions with each tag?
|
| It provides the ability to tag 16 byte granules of memory
| with 4-bit tags where only pointers with the correct tag
| can access the memory. This provides an approximation of
| memory safety very useful for security.
|
| As an example of how it gets used, our implementation of
| the system allocators via hardened_malloc tags each
| allocation with a randomly generated tag excluding the
| adjacent random tag values and previous random tag value
| for the slot. It has the standard setup of a single
| statically reserved tag (zero) used for free memory but
| adds 3 more dynamic exclusions. This provides deterministic
| detection of small overflows, linear overflows, many forms
| of use-after-free and fallback to probabilistic detection
| of other spatial (bounds) or temporal (use-after-free)
| memory safety issues. We use a lightly modified variant of
| the standard MTE integration for PartitionAlloc in our
| Vanadium browser, but we plan to improve it to match
| hardened_malloc. We use the standard Linux kernel
| implementation for the internal Linux kernel allocators
| which needs a lot of improvement.
|
| > why target requirements that even most desktop computers
| don't meet?
|
| Desktop computers are far less secure than an iPhone or a
| Pixel with the stock OS. GrapheneOS exists to provide a
| higher level of privacy and security than those. GrapheneOS
| is primarily aimed at mobile devices which are almost
| entirely 64-bit ARM. Hardware memory tagging (MTE) is a
| standard ARMv8.5 / ARMv9 feature provided by every standard
| ARMv9 Cortex core. MTE is only missing with custom CPU
| cores or cache while cutting this corner.
|
| Pixels are not the only devices providing MTE. Exynos and
| MediaTek have provided it and Snapdragon should be
| providing MTE starting at the end of this year. The only
| reason Snapdragon is late to the party is due to their
| custom cores/cache.
|
| We're currently working with a major Android OEM towards
| multiple of their future devices meeting all of our
| requirements and providing official GrapheneOS support.
| They view all of our officially listed requirements as
| completely reasonable and a target they can meet for their
| next generation of devices.
|
| The purpose of GrapheneOS is providing a high level of
| privacy and security, not making security less bad for
| devices people already have. Hardware and firmware security
| matters quite a lot and software security depends heavily
| on hardware-based security features including MTE. Nearly
| all GrapheneOS users buy a device to use GrapheneOS and
| that would still be the case if we supported several other
| devices. The vast majority of Android devices lack proper
| security patches for drivers/firmware, are missing
| important hardware-based security features and don't
| provide serious support for using another OS where the
| security features can be kept intact. Samsung's flagships
| are closest to meeting our requirements after Pixels but do
| not allow another OS to use verified boot, important secure
| element features and more. Samsung permanently cripples
| their devices if they're unlocked and voids the warranty,
| unlike Pixels.
|
| The reason we're working with an Android OEM is because
| existing non-Pixel devices don't provide a base we can use
| to provide what GrapheneOS offers. It would be missing huge
| parts of the core features elsewhere and would be worse in
| significant ways than the stock OS. It would go against
| what we're trying to achieve to have people buy devices we
| can't properly secure. Long term support for drivers and
| firmware is also important because people use devices more
| than 3 years from launch in practice. Pixels get 7 years of
| proper support from launch, which is unique. A couple OEMs
| market their devices as having similarly long support but
| the updates are significantly delayed and far less
| complete.
|
| We've had numerous opportunities to work with OEMs where
| they weren't able to provide our requirements. We simply
| aren't interested in having a far less secure device with
| GrapheneOS as the stock OS. We expect our requirements to
| be met, and we think the OEM we're currently working with
| is fully capable of providing what we need. It will
| hopefully be available in 2026 or 2027. The initial goal is
| not doing better than Pixels, just providing a competitive
| alternative for people who want to use GrapheneOS on
| another brand of device.
| cromka wrote:
| I really hope it's the Nothing Phone you're talking to.
| nicman23 wrote:
| that is great but i hope it is not a small run with a 200+
| price as happens with the various linux phones.
| tenthirtyam wrote:
| I can understand the GOS' rationale in choosing only the most
| secure phones. However, I'm more concerned about privacy, and
| not so much about security. It'd be great to have something
| like a "GOS-Lite" which accepts some security compromises in
| order to bring privacy to more people. (And yes, I understand
| that lower security means less privacy from targeted attacks
| but even GOS depends on OEM blobs, right?)
| beefnugs wrote:
| Sounds like google is going hostile to the project, so if
| enough of us miss it i guess we will have to work on new
| hardware support
| mbananasynergy wrote:
| GrapheneOS community manager here. Google did make it harder
| to support Pixels, but we're still doing it and plan to
| continue supporting new Pixels provided they keep meeting our
| requirements.
|
| At the same time, we're in communication with an OEM to have
| some of their devices have official GrapheneOS support, so
| we're moving towards redundancy.
| crossroadsguy wrote:
| I actually like Graphene's focus in Pixel. It is available in a
| lot of countries unlike Fairphone - via Pixel of course.
|
| So Graphene is actually not limited to the developed/western
| world. As for not supporting other devices, I believe the
| reason could be the team size and the fact that the fragmented
| Android world is known for unique shenanigans of every OEM.
| Besides Google's update/upgrade cycle is another reason it is
| an appropriate choice.
| beeflet wrote:
| por que no los dos?
| gf000 wrote:
| Because as mentioned, Fairphone has lackluster hardware
| security.
|
| You can have the best alarm system in the word, if you
| leave the back door open and anyone can just walk in from
| the street.
| bornfreddy wrote:
| Meh. Not all people have the strictest security (and
| privacy!) requirements. While it is admirable that GOS
| strives for perfection, I would be more than happy with a
| less secure, but _repairable_ phone, such as Fairphone.
|
| So just give me that alarm system for my tent, please. It
| will do fine for my case.
| mbananasynergy wrote:
| We don't really strive for perfection. Pixels aren't
| really perfect and there are numerous suggestions we
| could make today for Pixels to drastically improve their
| hardware. Our requirements are in some way below what
| even Pixels provide today.
|
| Our requirements are not at all exotic or outlandish, the
| fact that most OEMs don't meet them says more about how
| far behind most OEMs are, rather than our standards being
| unrealistic. We've also been told that they're not
| unrealistic in practice from numerous OEMs who want to
| build a device that meets our requirements.
|
| It is also important to note for Pixels specifically that
| since the 8th gen Pixels, they receive 7 years of
| support. Additionally, they partner with iFixIt to
| provide official replacement parts for the duration of
| the device's life. I'd say that's pretty sustainable,
| especially when you consider that the Fairphone doesn't
| actually provide proper support for the amount of years
| they claim, since they have consistent delays in
| providing patches.
| beeflet wrote:
| Okay, but the danger of vendor lockout is very great
| because gOS only supports one brand of phone. The
| justification for limiting support to pixels is that it
| has trusted computing features, but these are made
| unnecessary by having a long password.
|
| You could just have some disclaimer on the grapheneOS
| site that says something like "Works best with pixel
| phones" or have some long password requirement on non-
| pixel phones
| gf000 wrote:
| > but these are made unnecessary by having a long
| password.
|
| Yeah, that's completely how security works...
| const_cast wrote:
| The maintenance burden would be wayyy higher and the
| satisfaction with the project would plummet.
|
| It's a catch 22. Support other devices, the software won't work
| as well or reliably or maybe buggy - users get pissed off.
|
| Spent the time to make it not buggy on other devices = now
| you're doing mor dev work than even Google.
| perching_aix wrote:
| That project background reads suspicious as all hell, but then
| the thing does do what it says on the tin from all the news I
| see, so go figure.
| mbananasynergy wrote:
| Hi, GrapheneOS community manager here.
|
| There are some corrections that we have contacted the author
| about regarding the history of the project. They initially
| e-mailed us to ask a few questions but seems to have maybe
| misunderstood something.
|
| For clarity, GrapheneOS is the continuation of CopperheadOS,
| not a new project that spun off from it.
|
| As an example, it can be seen that our repositories and legacy
| bugtrackers are ours:
|
| -https://github.com/GrapheneOS/platform_manifest/forks?includ..
| .
|
| -https://github.com/GrapheneOS/platform_bionic/forks?include=..
| .
|
| -https://github.com/GrapheneOS-
| Archive/legacy_bugtracker/issu...
|
| It's a direct continuation, but was renamed to GrapheneOS post
| the failed takeover attempt. GrapheneOS has persevered and is
| all the stronger for it. Over a decade now. :)
| onli wrote:
| That is not correct, or at best a very questionable
| interpretation. Graphene is a continuation of the open source
| side of copperhead, but the copperhead project continued to
| exist even though the Graphene dev sabotaged it by deleting
| the cryptographic keys. Copperhead is the continuation of
| copperhead is my reading, Graphene is just also a
| continuation in a different project.
|
| Why lie about something so easy to disprove by a bit of
| research? There were a bunch of articles about this back
| then, even wikipedia states it clearly.
| other8026 wrote:
| Did you look at the links?
|
| > Fuzion24 / platform_manifest Created 10 years ago Updated
| 10 years ago
| perching_aix wrote:
| Ah sorry, might have been unclear: by background, I meant the
| current governance and contributions situation they describe
| in the post.
| usuallymatt wrote:
| I was tempted to use this but when I looked into the team behind
| it there seemed to be some issues as exposed by Louis Rossman
| here: https://youtu.be/Dl1x1Dy-ej4.
|
| Instead, I installed CalyxOS and have been using it over a year
| now and I'm very happy with it. Check it out.
| Scrubbed4426 wrote:
| This a video where he openly bullies someone, live streams
| their private messages where they're getting upset with him
| bullying them and repeatedly, blatantly lies about them
| including falsely claiming they're insane, etc.
|
| Rossman lied about stopping using GrapheneOS and has continued
| using it after that point.
|
| The video was made to direct harassment towards the project and
| founder after the project refused to work with Rossman.
|
| He has done similar things to others, labeling them as insane
| and delusional.
| bernoufakis wrote:
| > This a video where he openly bullies someone, live streams
| their private messages where they're getting upset with him
| bullying them and repeatedly, blatantly lies about them
| including falsely claiming they're insane, etc.
|
| That is the most disingeneous take on the video. The claim
| this kind of commenters that freely carry water for the toxic
| GOS (ex-?) lead developer is the exact reason why Rossmann
| made the video. The evidence is all there for the public to
| see. Daniel does not get to essentially harass people he
| disagrees with after they have been asked to not contact
| them, threaten them to "publicly expose them" and get away
| scott free.
|
| Being a genius at cyber security or autistic does not give
| one a free pass to treat other like garbage.
|
| > The video was made to direct harassment towards the project
| and founder after the project refused to work with Rossman.
|
| The video was made to expose the harassment of the project
| founder toward Rossmann, when the former contacted him out of
| the blue with frivolous accusations after they parted way a
| year earlier due to un-reconciliable disagreements.
|
| > He has done similar things to others, labeling them as
| insane and delusional.
|
| No evidence provided, as usual.
| mbananasynergy wrote:
| >No evidence provided, as usual.
|
| You should watch Rossmann's video on Linus - he has a habit
| of doing these hit pieces.
| bernoufakis wrote:
| Yes, I have watched them all. As I mentioned somewhere
| before I am a fan of both channels.
|
| He never called Linus "insane" or "delusional" as the
| parent post claims, hence the request for evidence.
|
| He (rightfully IMO) criticized some of his business
| practices (Honey, BilletLabs, "Trust me bro"), and quite
| a few more controversies which LTT was embroilled in.
|
| He criticized Linus' behavior and lack of accountability
| based on his personal interaction with him, as well as
| publicly available evidence. At worst, called him a
| narcissit. If anything, he is vindicated by all the LTT
| apologies videos (one of which Linus and other staff even
| make puns and sponsor placements ...) that follow up each
| controversies.
|
| Any more specific evidence you think show that "Rossmann
| has the habit of calling random people insane and
| delusional". I am willing to bet you have none.
| mbananasynergy wrote:
| Hi there. GrapheneOS community manager here. It's a weird video
| to bring up without any context. Louis Rossmann made that video
| and leaked private conversations that were had fairly soon
| after the person in question was repeatedly swatted by someone
| who has a fan of the person Rossmann was voicing support for.
|
| Unfortunately, Rossmann turned out to be very dishonest, which
| in retrospect makes sense, seeing as he has no issues with
| using Kiwi Farms. He's verified account there is named
| "larossmann". I suggest you look into it.
|
| It's not just something he's done with GrapheneOS and the
| founder of the project. There are many videos, such as the one
| he did on Linus from Linus Tech Tips where he similarly
| misrepresented things and ascribed mental health labels on
| them.
|
| Regarding CalyxOS, I would recommend people check out
| https://eylenburg.github.io/android_comparison.htm as a third-
| party comparison for various projects, including GrapheneOS and
| CalyxOS. They're not similar projects.
| nicman23 wrote:
| that comparison you are pasting in multiple replies has
| lineageos without micro-g.
| icar wrote:
| MicroG is extremely insecure. Does nobody remember that
| they used to print your Google password in plain text in
| the logs?
| nicman23 wrote:
| k but i do not care about an account that i do not have.
| i only use it for the gms or whatever is called now
| onli wrote:
| > _Louis Rossmann made that video and leaked private
| conversations that were had fairly soon after the person in
| question was repeatedly swatted by someone who has a fan of
| the person Rossmann was voicing support for._
|
| I am sure you have proof for such a justiciable acccussation?
| The perpetrator is in jail and you can link to the court
| proceedings for example? You are surely not just
| regurgitating another hallucination by the Graphene
| developer, right?
| bernoufakis wrote:
| Unfortunately I don't think they do.
|
| Disclaimer, I am a GrapheneOS user. I was introduced to GOS
| by Louis Rossmann initial 2 or 3 videos talking about
| giving them a FUTO grant, as well as praising GOS and
| showing how it easy it was to install, and how it gave back
| control to the user, and all the good things that GOS
| genuinely provides.
|
| I have (unfortunately) followed this saga and went down the
| rabbit hole since the very beginning. To my understanding
| based on publicly available data, the key "evidence" put
| forward by GOS developer(s) / community manager would be:
|
| 1. Louis Rossmann leaving the now pinned comment
| "Informative but unfortunate" on TechLore's video on the
| leadership of GOS. They claim this is Rossmann showing
| support for Techlore and his community to (allegedly)
| harassed the (at the time) lead developer of GOS.
|
| 2. Louis Rossmann having KiwiFarm account. Yes, KW is a
| cesspit. However, all of Rossmann's message on the board
| mostly focus on either addressing misconceptions about
| himself, or promoting right to repair and similar topic.
| This can be easily checked, and at no point there is any
| public evidence of him supporting harassment toward the GOS
| developers.
|
| 3. Louis Rossmann being acquainted with leadership of other
| de-googling Android OSes (CalyxOS mainly I think) and also
| giving them a FUTO grant.
|
| Essentially, "guilt by association". I know this because I
| have asked the community manager (goes by mbananasynergy on
| HN, and similar aliases on other platforms), and that is
| what they provided as "evidence" for Rossmann being guilty
| of harassing or promoting harassment against them (along
| with mentions of having 2 millions of USD worth of backing
| and ready to sue Rossmann, which has not materialized as
| far as know since ~1.5 years ago).
|
| I want to preface by saying that GOS is really a good
| software, I have been using it for 2 or 3 years since then,
| and no complaints on that side. My biggest gripe however,
| is indeed with the leadership and management of the
| community.
|
| I created a new account instead of posting this with my
| main because the leadership is in my experience very
| abrasive, to say the least. I have been banned without
| appeal from their Mastodon for leaving "thumbs up" smiley
| on : 1) messages suggesting the GOS devs to do an interview
| with Rossmann (as he did with other projects that received
| a FUTO grant) to further spread the word, or 2) messages
| suggesting to clear up the misunderstanding between the
| devs and Rossmann.
|
| Any disagreement on their official narrative, or contrary
| opinion (even in good faith) leads to bans if they are in
| control of the platform, and accusations of collaborating
| with groups that harass the developers. Even here, anything
| contrary to that narrative will receive the usual wall of
| text describing the poster as sockpuppets, harassers
| directed by Rossmann, Techlore, CalyxOS, or any other
| projects GOS developers are beefing with.
|
| I am disappointed by the situation, because I think GOS
| could have a larger presence and contribute to raising
| awareness about the importance of data security, but their
| leadership seems to be a considerable roadblock on that
| direction.
| gtsop wrote:
| This is a very interesting summary indeed, however I
| think matters are simpler and noone needs to dive that
| deep.
|
| Unfortunatelly, EVERYONE, from all parties, fire shots
| for the wrong reasons, which perverts the discussion.
|
| When you say to people to not use GOS because the lead
| dev is paranoid or the community is hostile you are
| throwing out the baby with the bathwater. The value GOS
| brings is undisputable. The quirkiness of the leadership
| is also undisputable. Let's decouple the two. If you wish
| for the community to get better, become yourself the
| better contact point amd generally focus on suggestion on
| that matter. Don't say to people to not use arguably the
| most secure android rom!
|
| I used to respect Rossmann a lot, but he fell in my eyes
| both for the LTT and the GOS incident. I have been
| watching LTT since a kid and I know that his has grown to
| be a jerk without looking at his private communications,
| but his competitors fired shots at him for the wrong
| reasons (honey case) and so did Rossmann, riding the
| wave.
|
| If you want to criticize someone for being a jerk do it,
| but do it for the right reasons, don't muddy the waters
| by injecting other stuff in the discussion.
| bernoufakis wrote:
| > When you say to people to not use GOS because the lead
| dev is paranoid or the community is hostile you are
| throwing out the baby with the bathwater. The value GOS
| brings is undisputable. The quirkiness of the leadership
| is also undisputable. Let's decouple the two. If you wish
| for the community to get better, become yourself the
| better contact point amd generally focus on suggestion on
| that matter. Don't say to people to not use arguably the
| most secure android rom!
|
| It's one thing to separate the artist from the art, but I
| think that analogy does not apply when it comes to e.g.
| an operating system which essentially handles all of your
| private data. If anything, not being able to separate the
| art from the artist is the exact reason why GOS exists,
| the artist being "Google" and all their controversial
| practices. (Edit: or a simpler analogy, would you trust
| the food (art) of a cook (artist) that threatens to ruin
| your life ?)
|
| The OOP is entitled to express his informed opinion and
| even provided what he based it upon. As a user, I think
| that is important context when it comes to picking
| something as sensitive as an OS.
|
| > I used to respect Rossmann a lot, but he fell in my
| eyes both for the LTT and the GOS incident. I have been
| watching LTT since a kid and I know that his has grown to
| be a jerk without looking at his private communications,
| but his competitors fired shots at him for the wrong
| reasons (honey case) and so did Rossmann, riding the
| wave.
|
| I happen to have a similar background as far as LTT
| (weekly WAN show and what not) and Rossmann are concerned
| As I mentioned before I (unfortunately) went into the GOS
| incident rabbit hole and overall still think Rossmann was
| principled. As far as Rossmann's criticism of Linus about
| the LTT Honey case, perhaps he could have had a more
| nuanced approach, yes. Regarding the BilletLabs cooling
| block, or the "Trust Me Bro", his criticism was
| substantive, and came from his own business background on
| dealing with customers (although you can argue that
| Rossmann has high standards). I don't think Rossmann
| "fired shots for the wrong reasons", namely since LTT has
| publicly acknowledge the issues.
|
| > If you want to criticize someone for being a jerk do
| it, but do it for the right reasons, don't muddy the
| waters by injecting other stuff in the discussion.
|
| Just curious, but who is muddying waters, and how ?
| gtsop wrote:
| > Just curious, but who is muddying waters, and how ?
|
| In the context of this whole rabbit hole, pretty much all
| of the parties.
|
| When you bring someone's dirt put in the public, not to
| support an argument but just to attack them because you
| don't like them, uou are muddying the waters.
|
| MegaLag did it for Linus
|
| Steve did for Linus
|
| Luis did for Linus
|
| Linus did for Steve
|
| Linus did for Luis
|
| Henry did for Daniel
|
| Luis did for Daniel
|
| And of course Daniel pretty much does for anyone :p
|
| These were not conversations based on logic, each had a
| reason to dislike the other and dag up dirt for clicks
| and for leverage.
| bernoufakis wrote:
| > When you bring someone's dirt put in the public, not to
| support an argument but just to attack them because you
| don't like them, uou are muddying the waters.
|
| To take the specific case of Rossmann, how is he muddying
| the water ? If anything, he is clarifying his position on
| stopping using GOS. It is important context, not
| "muddying the waters".
|
| You yourself say that: > And of course Daniel pretty much
| does for anyone :p
|
| And Rossmann brought up the receipt to corroborate the
| GOS developer hostile behavior toward him, which was his
| argument. And even if you take it further back to origin,
| the "Informative but unfortunate" comment, this was not
| targeting GOS's quality and claim of security. The
| argument in that specific case was the questionable
| behavior of the leadership, which you seem to agree was
| not a "conversation based on logic". If some people can't
| be reasoned with, what is Rossmann supposed to do ? He
| "agreed to disagreed" and cut contact with the dev, kept
| the GOS situation under the lid as it was still a project
| he liked, but that was apparently not enough to keep that
| developer at bay ...
| gtsop wrote:
| > If some people can't be reasoned with, what is Rossmann
| supposed to do ?
|
| Just stop interacting? When you have an argument with
| your colleague, do you go on twitter and post all your
| conversations and tell everyone how irrational he is?
| When you argue with a relative do you make an 1hour long
| video detailing how they missbehaved? Why did Luis felt
| the need to make content on his popular channel to expose
| someone with problematic behavior?
|
| Clicks. Money.
|
| And on top of that he is attacking his work which is
| actually very valuable.
|
| I don't care if Luis is on the right side of the
| argument. If he was chatting me up on the bus and told me
| about it, i would be glad to know. Attacking a person on
| public for money and leverage is bs.
|
| Edit: Especially in the case of Daniel, if you have made
| the conclusion that a person is trully paranoid, this is
| a clinical situation, do you expect to "fix" them by
| exposing them? Or are you throwing more gas to the fire?
| bernoufakis wrote:
| > > If some people can't be reasoned with, what is
| Rossmann supposed to do ? Just stop interacting? When you
| have an argument with your colleague, do you go on
| twitter and post all your conversations and tell everyone
| how irrational he is? When you argue with a relative do
| you make an 1hour long video detailing how they
| missbehaved? Why did Luis felt the need to make content
| on his popular channel to expose someone with problematic
| behavior?
|
| Rossmann did exactly in September 2022. If you actually
| bothered going through the document, would could see that
| they had an initial interaction that did not pan out.
| Rossmann wished Daniel best of luck and said he would not
| be further involved because of the disagreement.
|
| On his social media and other platforms, Daniel did not
| stop talking about how Rossmann was allegedly attacking
| (without any concrete evidence). Daniel himself contact
| Rossmann again out of the blue with borderline threats
| blackmail umprompted, as can be seen in Rossmann's video
| on "Why I deleted Graphene OS". Asking nicely did not
| work, and Daniel threatened to "publicly expose him", so
| he went public. What was he supposed to do ?
|
| > Clicks. Money.
|
| Rossmann channel is not making him money. It is not
| monetized. His business is about repairing Macbooks and
| data recovery. This drama does not generate him money. He
| does not get paid for people using CalyxOS etc... over
| Graphene OS. There is simply no incentive
|
| > And on top of that he is attacking his work which is
| actually very valuable.
|
| What "attack" ? Is a comment "Informative but
| unfortunate" on a video criticizing Daniel's behavior an
| attack ? Is giving the project a 40K USD grant no string
| attached an "attack" ? Is proposing an to do interviews
| to further promote the project an "attack" ? Is making
| videos to actually dispel misconceptions about GOS and
| praising how good it is on his channel and "attack" ?
| None of you who carry water for Daniel and his toxic
| behavior have any evidence of Rossmann directing attack
| at GOS, and even loss so Daniel himself.
|
| > I don't care if Luis is on the right side of the
| argument. If he was chatting me up on the bus and told me
| about it, i would be glad to know. Attacking a person on
| public for money and leverage is bs.
|
| Again, no evidence it is about money and leverage.
|
| > Edit: Especially in the case of Daniel, if you have
| made the conclusion that a person is trully paranoid,
| this is a clinical situation, do you expect to "fix" them
| by exposing them? Or are you throwing more gas to the
| fire?
|
| Keeping it private the first few time did not seem to
| work, might as well try. If Daniel himself is beyond
| help, at least make it so other people know what kind of
| person they are entrusting they phone security and
| privacy to.
|
| By the way, I managed to find their archived conversation
| which are not available anymore in the video description.
| Curious about your opinion on it: <https://www.swisstrans
| fer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
| tholdem wrote:
| Your logic seems to fall apart here.
|
| > an operating system which essentially handles all of
| your private data.
|
| This is exactly why one should continue using GrapheneOS
| as it is by far the best, most secure and private option.
| If you do not agree with one project member about
| something that is not related to the technical features
| of the project, it does not matter, since you can not be
| targeted with any GOS updates. Same updates would have to
| go to all GOS users and as stated before, the previous
| project leader has a stellar reputation when it comes to
| their work and prior actions regarding users security and
| privacy.
|
| > the artist being "Google" and all their controversial
| practices
|
| You believing this is a problem, you should then be using
| an iPhone anyway.
|
| You are worrying GOS devs might push a malicious update,
| even when there are no proofs of that happening? What
| prevents the same from happening with other projects that
| are already inferior in every way? You are implying
| people should switch to less secure options because of
| this one thing that also applies to all other options? It
| does not make any sense and seems dishonest.
| bernoufakis wrote:
| > Your logic seems to fall apart here. >> an operating
| system which essentially handles all of your private
| data.
|
| I will concede that my statement is not the most
| accurate. However it is not a matter of logic, but
| description. What I meant to say is that the OS is the
| substrate of all applications running on the phone, and
| all the relevant data. Having privileged access to the OS
| opens the user to the most critical vulnerability.
|
| > This is exactly why one should continue using
| GrapheneOS as it is by far the best, most secure and
| private option. Rationally speaking yes. When the
| developer of the OS threatens to "public expose you" and
| accuses you of directing harassment / swatting against
| them without evidence however, a layman (that has no
| obligation to understand how GOS updates work) is
| justified in feeling unsafe or uncomfortable using said
| software. A determined enough (hostile) developer could
| find a way to target him personally. Even if you
| personally feel it is unlikely, the probability is
| ultimately non-nil.
|
| The GOS x Rossmann matter was never a technical issue, it
| was about the (in my opinion) toxic approach of that lead
| GOS dev to Rossmann. A huge misunderstanding I dare say.
| But the damage was done and Rossmann is within his right
| to criticize his approach and stop using his software.
|
| > Same updates would have to go to all GOS users and as
| stated before, This is a irrelevant point. Stuxnet was
| harmless to most systems, while still targeting very
| specific Iranian systems. All GOS user, (me included)
| don't audit the code every time there is an update.
|
| > the previous project leader has a stellar reputation
| when it comes to their work and prior actions regarding
| users security and privacy. Stellar reputation is quite
| the exaggeration. That lead GOS dev has an indeniable
| controversial and abrasive reputation. Imagine the
| ingenuity and persitence that you perceive about his
| "work and prior actions regarding users security and
| privacy", and imagine it being deployed toward someone
| that dev does not deem as a "simple user", but a personal
| enemy / enemy of the project ? Nobody would want to be on
| the receiving side of whatever such person is capable,
| and neither does Rossmann, understandably.
|
| > > the artist being "Google" and all their controversial
| practices > You believing this is a problem, you should
| then be using an iPhone anyway.
|
| I will assume you are good faith, and just misread what I
| wrote. My point was that in the same way we cannot trust
| Google software (at least privacy wise) because of the
| profit incentive of its leaders, another OS like Graphene
| OS can also inspire distrust if their leadership
| demonstrate hostile behavior (even if just toward a
| single specific user).
|
| > You are worrying GOS devs might push a malicious
| update. Me personally, no. I am not worried. I know
| enough about software to know that it is unlikely. And I
| am a nobody. Rossmann is, because he is a layman, and the
| lead dev was clearly hostile against him. We don't get to
| deny his perspective.
|
| > even when there are no proofs of that happening ? Not
| having proof of it never happening so far, is not a proof
| that it will never happen in the future.
|
| > What prevents the same from happening with other
| projects [...] Nothing prevents it, and no one involved
| either in this discussion, nor in the original incident
| stated this.
|
| > You are implying people should switch to less secure
| options because of this one thing that also applies to
| all other options? Again, nobody implied that. I
| personally never said it. My argument was that I found
| the leadership lacking, and to a certain extent, the
| community (examplified by this kind of "water carrying"
| arguments you have presented). Even Rossmann himself
| never said it. He only made public his reasons for not
| mainly using GOS since the altercation, and still
| recommends it whenever he discuss phone privacy. The
| grandparent however did bring up this issue with GOS
| leadership as a data point, which would still be good to
| have for prospective GOS users.
|
| > It does not make any sense and seems dishonest. If
| anything, you moving the goal post with such strawmen
| arguments is what seems dishonest...
| other8026 wrote:
| The swatting attacks are public record, and can be
| confirmed through Toronto police records.
|
| > another hallucination by the Graphene developer
|
| I'm going to assume that by you saying "another" you mean
| that there were hallucinations before this one.
|
| What you are doing here is repeating baseless claims that
| they're crazy, which is complete nonsense. This is exactly
| the kind of problematic stuff that shows up on Kiwi Farms.
| Again, Rossmann has an account there and some of his videos
| seem to be made to appeal to Kiwi Farms users.
| bernoufakis wrote:
| Is having an account on Kiwifarms evidence that Rossmann
| is either directly or indirectly responsible for
| harassment against the GOS developer(s) ?
| onli wrote:
| > _The swatting attacks are public record, and can be
| confirmed through Toronto police records._
|
| Which is not what I'm talking about. You claim you know
| who did it. Where is the proof?
|
| Though I never doubted that the swatting attacks
| occurred, I am noticing now that you mention police
| reports without linking them. Let me guess, there is
| nothing online, no police press release, nothing?
|
| > _I 'm going to assume that by you saying "another" you
| mean that there were hallucinations before this one._
|
| Yes. Like the attacks he hallucinates from project like
| Calyx and from the Techlore Youtube channel, and the
| documented way he turned on Rossman. Always claiming
| there is proof he already provided for the evil
| machinations of the others, with references going to
| other claims of having provided proof before, with none
| to be found anywhere down that chain. That is pretty easy
| to categorize behaviour. I personally would not call him
| crazy (who the fuck is "they"?), that seems to be
| hurtful, but I am confident in seeing signs of a mental
| disorder there and stating that publicly.
|
| > _Again, Rossmann has an account there and some of his
| videos seem to be made to appeal to Kiwi Farms users._
|
| Complete Bullshit. Provide links to the videos, otherwise
| that is another evidenceless attack and just confirms
| your pattern.
| other8026 wrote:
| > You claim you know who did it.
|
| No. Nobody claimed to know the actual identity of the
| person.
|
| > Like the attacks he hallucinates from project
|
| They're not hallucinations.
|
| > I am confident in seeing signs of a mental disorder
| there and stating that publicly.
|
| Not a doctor, but is confident in their diagnosis of
| someone they don't actually know after watching some
| YouTube videos.
|
| > Complete Bullshit.
|
| I mean that these kinds of videos where he portrays
| people as crazy appeals to Kiwi Farmers. His verified
| account there, him participating there, and him making
| videos that do appeal to them all add up to me coming to
| the conclusion that they _SEEM_ to be made with the
| _intent_ to appeal to Kiwi Farms members.
| onli wrote:
| > _No. Nobody claimed to know the actual identity of the
| person._
|
| Your founder sure did, in https://grapheneos.social/@Dani
| elMicay/110267918805461751.
|
| > _They 're not hallucinations_
|
| Sure buddy. And you will present proof any day now.
| bernoufakis wrote:
| Do you happen to have a backup of the Matrix / Element
| export from Rossmann's video ? It was Google drive link
| that seems to be unavailable now.
| onli wrote:
| Yes, I do. Surprised myself. Email me, address is in my
| HN profile.
| mbananasynergy wrote:
| It is genuinely very strange that you're relying on
| people simply not clicking the link you're providing.
|
| The person who swatted Daniel spent days raiding our
| Matrix chat rooms, posting gore and CSAM. We know it was
| them who did it, because they bragged about it during
| their raids before we had made any public comments about
| it happening.
|
| We don't know who the person is, and neither does the
| police. The details we have about what was said during
| the calls was provided to Daniel via the police,
| especially since it happened 3 times, not just once.
| Thankfully after the first time the responders were
| somewhat aware of what was happening so it wasn't as
| scary.
|
| Your deflection is genuinely concerning.
| mbananasynergy wrote:
| >Complete Bullshit. Provide links to the videos,
| otherwise that is another evidenceless attack and just
| confirms your pattern.
|
| I assume you're not disputing that Rossmann has a
| verified Kiwi Farms account, that much is well
| documented.
|
| https://youtu.be/wgF92Wi8J7o
|
| The above video refers to a video by Destiny
| (https://youtu.be/ba383Zux0Mo) where he spends a bunch of
| time defending Kiwi Farms. Rossmann making a video about
| it and joking about "lolcows" is what has contributed to
| people at Kiwi Farms worshipping him, and his fan
| starting a thread about Daniel there where people tell
| him to kill himself.
|
| Stop defending this stuff and finding every opportunity
| you can to try and gaslight others - it's weird.
| BLKNSLVR wrote:
| "Never meet your heroes". Also, the opening monologue to Tool's
| Third Eye[0].
|
| The older I get the more examples I've come across of a person
| destroying their reputation by either self-over-exposure
| (social media) or just basic exposure via news of some
| outrageous or illegal behavior.
|
| I don't have a problem with whatever line you choose to not
| cross, and I was once much more self-righteous, but I've more
| recently pretty much made the conscious decision to separate
| product from producer, art from artist, etc.
|
| Theo Lengyel was recently arrested for murdering his
| girlfriend, and yet I will still listen to and enjoy Mr.
| Bungle's music.
|
| Gary Glitter... I still like the song Rock n Roll Part Two.
|
| J.K. Rowling has some controversial views on transsexual women,
| but that doesn't mean that the Harry Potter series is any less
| worthwhile reading than it was before.
|
| ReiserFS
|
| I still buy Nestle Quik occasionally
|
| Steve Jobs, Bill Gates, Mark Zuckerberg, name almost any tech
| bro... (but not Steve Wozniak, he's a treasure)
|
| Sports stars.
|
| Musicians.
|
| I wonder how many other things are worthy of protest if we knew
| all the facts about all the people who were involved in it's
| creation.
|
| (I'm attempting to respond to the general concept of
| "he/she/they bad = it bad", not commenting on GrapheneOS vs
| CalyxOS or anyone's personal choice over where / what they
| choose to apply "he/she/they bad = it bad" to, other than
| saying that it should be a conscious decision not a reflexive
| reaction)
|
| [0]: https://genius.com/Tool-third-eye-lyrics
| onli wrote:
| You are exactly right. To summarise for those who do not want
| to watch a video, the video shows communications with Graphenes
| lead developer in which he was extremely hostile and threatened
| Rossman. It also goes into how said developers hallucinates
| being attacked by specific other sites, like a Linux YouTube
| channel that obviously did nothing to him. His goons then
| attack those projects.
|
| You have to be aware that you give that person root when you
| use Graphene. All possible technical improvements aside this is
| a very big risk. He claimed he would step back after the video
| released, then called that a lie and continued with everything.
|
| Calyx seems to be the best alternative right now without such a
| risk factor.
| gtsop wrote:
| Can you elaborate on why this is a risk factor? What do you
| mean by saying we're giving him root? If a person is paranoid
| of being chased i would expect them to put even more effort
| into the security of the OS he develops, not to add
| backdoors. But please expand your own reasoning.
| onli wrote:
| Well, he can do everything to your phone, software and data
| by pushing software updates. When there was a dispute in
| the former project copperhead he deleted the cryptographic
| keys, blocking software updates. Paranoia could result in
| just making the system more secure, but why not add a
| backdoor to find the spies in your userbases that
| communicate with the black suited men that secretly run our
| government? After all it is easy, they all play a specific
| game where they communicate via secret messages in chat.
|
| You just don't know what will happen is what I'm saying.
|
| The "he has root" is also a reference to ubuntus
| shuttleworth.
| gf000 wrote:
| > when there was a dispute in the former project
| copperhead
|
| You mean who tried to hijack the project in a very
| questionable direction, harming their users, he rather
| lighted the project on fire then let the users' security
| be compromised?
|
| If anything, that is the greatest compliment you could
| give him.
|
| Also, this is fud that he can push any kind of code, like
| you can easily check any part of the pipeline.
| bernoufakis wrote:
| > You mean who tried to hijack the project in a very
| questionable direction, harming their users, he rather
| lighted the project on fire then let the users' security
| be compromised? > If anything, that is the greatest
| compliment you could give him.
|
| On one hand, sure it can be a compliment. On the other
| hand, it only increases the perception that he is could
| enact significant harm if he ever comes after you.
|
| > Also, this is fud that he can push any kind of code,
| like you can easily check any part of the pipeline.
|
| Who is "you" ? Neither Rossmann, neither me (software dev
| albeit not in cybersecurity), and even less so the
| average GOS user, and I would venture to guess that
| neither you can audit GOS code with enough confidence to
| declare that the risk of an exploit or backdoor being
| introduced is zero. Open-source is not a guarantee that
| code or software is secure (for e.g. CVE in xz utils and
| many such cases).
|
| Edit: some clarifications.
| other8026 wrote:
| > On the other hand, it only increases the perception
| that he is could enact significant harm if he ever comes
| after you.
|
| But that would be incorrect. It's not possible for anyone
| from the GrapheneOS project to target a GrapheneOS user
| that way. Look into how updates and the update servers
| work.
|
| > neither you can audit GOS code with enough confidence
| to declare that the risk of an exploit or backdoor being
| introduced is zero.
|
| The updater app is pretty easy to read through. I think a
| software developer would be able to understand it. The
| update servers' setups are also very easy to understand.
| It doesn't take a software developer genius to figure
| these things out.
| bernoufakis wrote:
| > But that would be incorrect. It's not possible for
| anyone from the GrapheneOS project to target a GrapheneOS
| user that way. Look into how updates and the update
| servers work.
|
| My point is that from Rossmann's perspective, being
| target of the lead GOS software dev hostile behavior as
| per his "Why I deleted Graphene OS" induces Rossmann's
| --> perception <-- that the GOS could go after him if he
| really wanted to. First, everyone is busy and has their
| life, suggesting that his spend hours going through code
| and documentation he is not familiar with to make sure he
| is not target is moot. Most people don't read TOS, and
| same goes for Licences and docs of OSS. Between doing
| that and stop using it as it's main device OS, the easier
| choice is the latter. As a software dev myself, your
| expectation of layman being able to navigate something
| like a code review, or even an investigating an exploit
| is hardly reasonable.
|
| So it is not "incorrect". I am not even saying Rossmann
| could be targeted. I cannot even make this claim as I
| have not gone through the docs nor understand the build
| and update pipeline, which is kind of my point: I can't
| be bothered neither for GOS, nor for the most of the FOSS
| software I use. The majority of OSS user rely on the
| vague concept that motivated and honest people audit the
| code, but hardly anyone is going deep dive into how an
| arbitrary piece of software works.
|
| The main issue is the attitude of that GOS developer,
| whether they like it or not, taints the confidence in the
| project. it does not matter if Rossmann can or cannot be
| targeted technically.
|
| The issue here is not technical but a reputation issue.
|
| > The updater app is pretty easy to read through. I think
| a software developer would be able to understand it. The
| update servers' setups are also very easy to understand.
| It doesn't take a software developer genius to figure
| these things out.
|
| Even then, it could be argued that the rules in place
| could be changed to introduce malicious exploit if the
| lead dev(s) were motivated enough. Especially given GOS
| relatively top-down structure, relying essentially on a
| benevolent dictator. Even if I made the effort, then
| ascertain there was no vector attack, now I have to stay
| on alert every commit / release version and spend as much
| time looking for a targeted exploit ? etc... Update
| server setup might be clean, but an admin could SSH or
| gain access in some way or another and do rogue changes,
| were they determined enough. The probability is not zero.
|
| Again, the problem is eroding the trust of the specific
| user (Rossmann in this case).
| other8026 wrote:
| Wow. Reading and responding to your comments in this
| thread, I can see you are very motivated to trash
| GrapheneOS and its founder.
|
| > Well, he can do everything to your phone, software and
| data by pushing software updates.
|
| Other developers are doing the bulk of development work
| these days, so this is nonsense.
|
| > Paranoia could result in just making the system more
| secure, but why not add a backdoor to find the spies in
| your userbases that communicate with the black suited men
| that secretly run our government?
|
| Again with the baseless claims that he's crazy. Your
| argument here is that "he is crazy, so maybe this happens
| too." It's nonsense. There are no backdoors, and if there
| ever were any backdoors, they would be found. GrapheneOS
| isn't some small project that nobody knows about. It's
| famous for being very secure, even famous people have
| said publicly that they use it or others should use it.
| Cellebrite cannot even hack into it. Backdoors wouldn't
| go unnoticed. This is also nonsense.
| onli wrote:
| Yeah, I'm probably all part of that big evil conspiracy
| that is after you
| gf000 wrote:
| This is on a level of "5G causes autism" understanding of
| the topic. Maybe learn how reproducible builds and
| cryptographic signatures work.
| Andromxda wrote:
| > This is on a level of "5G causes autism" understanding
| of the topic
|
| That sums it up perfectly
| bernoufakis wrote:
| To put it simply, the (at the time) lead developer of GOS
| and Rossmann had some disagreements.
|
| At the time, Rossmann was mainly using GOS, but due to what
| he perceived as hostile behavior from GOS toward him
| through their communication, he opted to stop using GOS (at
| least on his main device, as he claims).
|
| His rationale was that the behavior of said lead developer
| was not "rational" and "scary", and since the developer has
| not only edit access to GOS code but also update publishing
| infrastructure, Rossmann's data or himself could be
| targeted through malicious code pushed via an update, for
| example. While GOS is opensource and malicious code or
| exploits could be detected by the community, he himself did
| not have confidence to audit the source code to make sure
| it was safe, hence his decision to stop using.
|
| By risk factor, I think the grandparent suggests that
| something similar could happen to someone else using GOS,
| the risk factor being essentially at the mercy of GOS
| developer, would they wish to harm said user.
| gtsop wrote:
| So rossmann literally feared of a patch that was like
| this getting into graphene
|
| if (user is rossmann) { // do bad things
|
| }
|
| makes me think who is paranoid here.
| bernoufakis wrote:
| Your example is a strawman, as a determined enough actor,
| especially a security expert(s) like GOS developers could
| pull it off and get such patch / exploit. The probability
| is not zero. It will probably not be obvious to spot,
| would be spread over multiple files of code that don't
| necessarily relate to each other at first glance, as many
| documented CVE illustrated (one that comes to mind given
| HN context is the XZ utils backdoor from last year for
| e.g.)
|
| Rossmann himself has no confidence to audit the code, so
| why take the risk ? Good enough reason to be "paranoid",
| or at least feel uneasy about it if you ask me.
| gtsop wrote:
| Is it really a strawman? At some point, the code would
| need to identify rossmann. Please elaborate on the
| techniques required to do it and how it could be
| obfuscated.
|
| GOS doesn't use an account, so the code would have to
| perform very targeted heuristics in order to verify this
| is Luis' phone. It would have to compare his sim number
| against a known one, or dig into application data to find
| his logins and compare them against known emails. So the
| only way to not write `if (user is rossmann)` would be to
| send various diagnostics over the wire, to a service that
| contains these identifiers and perform the comparison
| onlinr, meaning he would introduce an imense security
| whole into everyone's phone, and everyone would see there
| is a home calling.
|
| So it's either a patch of if user == rossmann, or a home
| calling patch.
| bernoufakis wrote:
| > Is it really a strawman? At some point, the code would
| need to identify rossmann. Please elaborate on the
| techniques required to do it and how it could be
| obfuscated.
|
| I don't have to elaborate techniques. If a determined
| (and potentially mentally unstable) developer decides to
| leverage their full control over the OS to make it happen
| can. I don't have to elaborate on the techniques which
| might or might not exist yet. Stuxnet only targeted
| specific Iranian systems, a needle in a hay stack, was
| spread did not harm random devices across the globe, and
| stayed mostly undetected. And this was done without
| "developer access" to the software itself. Is it hard ?
| Yes. Is it likely (especially given the knowledge of how
| GOS works) ? Perhaps not. Is it impossible ? Definitely
| not.
|
| When the lead dev of the OS you use daily threatens to
| "publicly expose you" as a user, I won't blame said user
| to stop using the software. And even less, to provide
| such data point regarding the behavior of that developer.
| fph wrote:
| Note that this patch would have to be sent out to _all_
| users though, since I don 't think there is an
| authentication mechanism that lets them send out
| different upgrades to different users.
|
| And if your whole business is a secure OS, it's a very
| risky proposition: you get caught doing this _once_ , and
| your reputation is gone forever.
| other8026 wrote:
| > Rossmann's data or himself could be targeted through
| malicious code pushed via an update, for example. While
| GOS is opensource and malicious code or exploits could be
| detected by the community, he himself did not have
| confidence to audit the source code to make sure it was
| safe, hence his decision to stop using.
|
| This isn't even possible given how updates on GrapheneOS
| work. The update client doesn't send identifiers to the
| update server, and the update server only hosts static
| files.
|
| Rossmann either doesn't understand this, or he made it up
| to get more views, or possibly to entertain fellow Kiwi
| Farms members.
|
| To be honest, I don't think that he didn't understand
| that he couldn't be targeted. He continued using
| GrapheneOS for months after the video. As I understand
| it, it was clear in a few videos months after the initial
| video was published.
| bernoufakis wrote:
| > This isn't even possible given how updates on
| GrapheneOS work. The update client doesn't send
| identifiers to the update server, and the update server
| only hosts static files.
|
| > Rossmann either doesn't understand this, or he made it
| up to get more views, or possibly to entertain fellow
| Kiwi Farms members.
|
| Expecting a layman to know that is not reasonable. The
| argument is not about the GOS updates work in practice.
| It is about the "perpection", from Rossmann's perspective
| that the lead dev of the OS is hostile against him.
| Humans are not purely rational machines, and given the
| choice of either 1) spend hours auditing source code and
| updates pipelines (every release ?) and 2) stop using it
| for critical purpose, the latter is the easier choice,
| especially for a busy person like him.
|
| > To be honest, I don't think that he didn't understand
| that he couldn't be targeted. He continued using
| GrapheneOS for months after the video. As I understand
| it, it was clear in a few videos months after the initial
| video was published.
|
| For all we know, he is using it on his secondary device
| where he has removed what he deems critical. Again,
| Rossmann NEVER said "don't use Graphene OS", or "Graphene
| OS lack security" or anything of the sort. If anything,
| even after that video, he kept recommending GOS whenever
| he talked about privacy.
|
| His argument is that he did not feel safe knowing using
| software from a hostile developer; and that he can't be
| bothered / not qualified to audit the code well enough to
| make it worth it (which is reasonable if you ask me, and
| I dare say most people).
|
| Edit: > Rossmann either doesn't understand this Again, I
| agree with you here. He does not understand. He trusted
| the developer(s) to know what they are doing, but they
| broke that trust by being unreasonable, to say the least.
| He is under no obligation to understand. As for what you
| stated after that, I won't comment on it as I don't read
| minds, and pretty sure neither do you.
| bernoufakis wrote:
| I second this opinion, with some additional nuance.
|
| While I don't think the developers necessarily hallucinates
| being attacked (i.e. given the nature of the project, I would
| expect them to be persons of interest, be it from
| surveillance agencies, or even state actors), the main issue
| with Rossmann is their claim that he is either personally
| directing harassment against GOS, or colluding with and
| encouraging other communities to harass (mainly Kiwifarms,
| Techlore, CalyxOS, and other Android related FOSS projects).
| This claim seems to originate then cascade from Rossmann
| leaving the comment "Informative, but unfortunate" on
| TechLore's video criticizing GOS's leadership. This is taken
| as explicit support of TechLore community's / KiwiFarms
| alleged harrassement on the lead GOS developer, and this has
| somehow been cascaded and blown out of proportions, and
| considered by GOS developers as evidence of Rossmann's wrong
| doing against them.
|
| As mentioned somewhere else, I am using GrapheneOS since 2 or
| 3 years now, based on Rossmann recommendations. The software
| is very good, pretty much native Android experience, but
| without the extra alleged Google snooping / root access.
| Rossmann himself seemed to have stopped using it as his main
| device because of fear of retaliation given that the GOS devs
| could potentially target him. Better safe than sorry. I still
| use it because I am not that high profile of a person, and
| generally will use throwaway when it comes to discussing
| anything GOS related at this point. The overall leadership
| however, based on Rossmann's and later my personal
| interactions with them however, did leave a bad after taste.
| other8026 wrote:
| > Rossmann himself seemed to have stopped using it as his
| main device because of fear of retaliation given that the
| GOS devs could potentially target him.
|
| But he didn't. It's clear in his later videos that he was
| still using GrapheneOS, I believe even for months after the
| video.
|
| > Better safe than sorry.
|
| People who are familiar with how GrapheneOS updates work
| wouldn't agree. No identifiers are sent to the update
| server, so targeted updates aren't possible that way. Also,
| update servers only host static files. If Rossmann was
| really that worried, all he'd have to do is use a VPN. But
| that was all just a huge dramatic act so his video would
| get more views, and possibly to entertain his fellow Kiwi
| Farms members.
| bernoufakis wrote:
| > But he didn't. It's clear in his later videos that he
| was still using Graphene OS, I believe even for months
| after the video.
|
| Emphasis on "seemed to have stopped using it as his main
| device". For all we know, he kept it as secondary device
| (its just that good) after removing anything he deemed
| critical. Again, he never said "don't use GOS", or "GOS
| is not secure". He said he was did not feel safe enough
| because of the hostility from the lead dev.
|
| > People who are familiar with how GrapheneOS updates
| work wouldn't agree. No identifiers are sent to the
| update server, so targeted updates aren't possible that
| way. Also, update servers only host static files. If
| Rossmann was really that worried, all he'd have to do is
| use a VPN. But that was all just a huge dramatic act so
| his video would get more views, and possibly to entertain
| his fellow Kiwi Farms members.
|
| Does it matter ? Rossmann is a layman when it comes to
| software. What he perceives is that "lead GOS dev is
| hostile against me and has essentially full control over
| the project". First, he is under no obligation to spend
| hours learning how GOS updates work and audit the code
| every release, whether or not some identifier is being
| tracked or not (and by the way, you can still get
| identified and tracked even if you use a VPN). The damage
| was done once that lead GOS dev persist in toxic
| behavior, for the lack of a better word.
|
| > But that was all just a huge dramatic act so his video
| would get more views, and possibly to entertain his
| fellow Kiwi Farms members.
|
| Unsubstantiated claims. We cannot read his mind, and I
| have yet to see any evidence that would support these.
| Andromxda wrote:
| > you can still get identified and tracked even if you
| use a VPN
|
| Sure, but that requires additional data about the user,
| which the GrapheneOS update server doesn't get. Both the
| update client and the update server are open source, so
| you can verify any of what I'm saying. The server only
| sees the user's IP address, which device model they're
| requesting an update for, and which update channel
| (alpha/beta/stable) they are using. The HTTP headers,
| etc. for the request would be identical across any
| GrapheneOS device, as they use the exact same updater
| app.
|
| https://github.com/GrapheneOS/releases.grapheneos.org htt
| ps://github.com/GrapheneOS/platform_packages_apps_Updater
|
| > First, he is under no obligation to spend hours
| learning how GOS updates
|
| That literally takes a few minutes to look up, it's all
| really well documented on the official website.
| https://grapheneos.org/faq#default-connections
|
| But yes, I do believe that he's obliged to do some
| research before putting out such absurd claims entirely
| based on speculation with no technical knowledge or
| understanding.
| bernoufakis wrote:
| > That literally takes a few minutes to look up, it's all
| really well documented on the official website.
| https://grapheneos.org/faq#default-connections
|
| Again, that is beyond the point. The developer going
| rogue (for arbitrary reason) and turning the code
| malicious is not impossible.
|
| > That literally takes a few minutes to look up, it's all
| really well documented on the official website.
| https://grapheneos.org/faq#default-connections
|
| All of you who keep commenting "But it's so easy, just
| look it up" are lacking consideration and empathy. Other
| people don't think like you, they don't have to think
| like you. Just the documentation you have linked has so
| many technical terms, someone not familiar with
| networking and system design will barely make any sense
| of it.
|
| It is a also a matter of trust. After the developer
| express their hostility multiple time, even if someone
| was willing to go through it, what if the documentation
| is not forth coming ? It is within the devs control after
| all. How does one even make sure that the software does
| what the documentation says it does ? etc...
|
| > But yes, I do believe that he's obliged to do some
| research before putting out such absurd claims entirely
| based on speculation with no technical knowledge or
| understanding.
|
| What "absurd" claim did he put out exactly ? His issue
| was never about the technical aspects of GOS. It was
| about the broken trust and the perception that using
| software from a hostile developer was a risk factor,
| hence his stopping using it (at least on his devices with
| sensitive info).
| Andromxda wrote:
| > Other people don't think like you, they don't have to
| think like you.
|
| I'm quite certain that there are more people than just
| me, who think that someone with close to two million
| subscribers on YouTube should fulfill due diligence by
| doing some basic research and at least read the extensive
| official documentation that's provided, before putting
| out a video with serious allegations and a very high
| potential of harming someone's reputation. I would go
| further and say that it was his intention of harming the
| project's reputation, but that's just my personal
| opinion. It's objectively clear though, that this is a
| very low quality video full of baseless speculation, and
| severely lacking any technical understanding and
| knowledge.
|
| > What "absurd" claim did he put out exactly ?
|
| His speculation about targeted malware in the OS.
|
| This is exactly the same as going to a restaurant, having
| an argument with the owner, and then claiming that they
| might be putting poison in the food, even though there's
| absolutely zero evidence or anything that might indicate
| that, solely because you had a disagreement with someone
| and now want to harm their reputation.
| bernoufakis wrote:
| > It's objectively clear though, that this is a very low
| quality video full of baseless speculation, and severely
| lacking any technical understanding and knowledge.
|
| "Baseless" could not be further away from the truth. You
| literally have the GOS developer messages coming in live
| while he rehashes frivolous accusations and threatening
| to exposing him. To claim objectivity, when you seem to
| cherry pick the parts of the video that would (loosely)
| fit your narrative. Where is your evidence that Rossmann
| is in anyway associated to harassment campaign against
| the project ?
|
| > This is exactly the same as going to a restaurant,
| having an argument with the owner, and then claiming that
| they might be putting poison in the food, even though
| there's absolutely zero evidence or anything that might
| indicate that, solely because you had a disagreement with
| someone and now want to harm their reputation.
|
| Damn, so close, you were almost there. A more accurate
| analogy you could have come up with, had you actually
| critically listened to Rossmann's argument in his video.
| Yes, it's like going to a restaurant and having a
| disagreement with the cook, for the latter to explicitly
| threaten to harm onto you. At that point, is it that far
| fetched to think he might poison the food ? When you know
| he has full control over the kitchen ?
|
| You can disagree with Rossmann perception of the actual
| threat, but you should at least admit that it is not
| absurd for Rossmann to think that someone who
| demonstrated such irrational behavior might attempt to
| harm in through the means at their disposal, among which
| introducing malicious code. It might be unlikely given
| what we know about software dev, but it is not
| impossible, and for Rossmann, that is the only thing that
| matters at the end of the day.
|
| Moreover, the GOS dev himself clearly stated he would
| "publicly expose him" (At 2:14 in
| https://youtu.be/4To-F6W1NT0?t=134 "and there will be
| information published about your (Rossmann) attacks on me
| in support of an abusive person). Why the double standard
| ? That GOS dev can go around dishing out "reputational
| harm" but his targets doing the same is not fair game ?
|
| At this point, Rossmann did him a service by publishing
| everything himself. As far as any reputational harm is
| concerned, the GOS developer essentially brought it on
| himself. Could have dropped back when they had the
| fallout in September 2022, as per the chat logs (<https:/
| /www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
| ) ...
|
| > I would go further and say that it was his intention of
| harming the project's reputation, but that's just my
| personal opinion.
|
| Sure, "harm the reputation of the project" when he was
| proactively giving them no string attached grants,
| spreading the word, and giving them an opportunities to
| tell their side of the story ...
|
| > I'm quite certain that there are more people than just
| me, who think that someone with close to two million
| subscribers on YouTube should fulfill due diligence by
| doing some basic research and at least read the extensive
| official documentation that's provided, before putting
| out a video with serious allegations and a very high
| potential of harming someone's reputation.
|
| Then in the first place, perhaps the cyber security
| geniuses who built a privacy and security oriented OS for
| smartphone could do the due diligence of gathering and
| presenting actual evidence of Rossmann implication in the
| alleged harassment campaign before before posting
| multiple accusatory statements across their socials media
| "with serious allegations and a very high potential of
| harming someone's reputation" ?
| bornfreddy wrote:
| > > Better safe than sorry.
|
| > People who are familiar with how GrapheneOS updates
| work wouldn't agree. No identifiers are sent to the
| update server, so targeted updates aren't possible that
| way. Also, update servers only host static files...
|
| We are literally talking about an OS here. It has an
| almost total control over your phone - what does it
| matter if the updates can be targeted? The GOS could
| snoop on their users and turn into malware only if it
| figures out that this is Rossmann's phone.
|
| This is what is keeping me from installing GOS too.
| Interaction from the developers seems very aggressive
| towards the competing OSs, which doesn't inspire much
| trust. Who is reviewing the GOS changes? Are they really
| all benign? In the end you need to trust someone, but I'm
| not sure GOS is more trustworthy than LineageOS (which
| has a bigger community, more developers and /e/os
| building on top of them).
|
| Happy to be convinced otherwise.
| gf000 wrote:
| Calyx has lackluster security practices, and even removes
| signature checking so they can sell microG as Google Play
| Store to apps. This is an objective statement, graphene OS is
| leagues ahead of anything on the market in terms of security,
| while calyx is basically just a custom ROM to tinker with.
|
| As for the personal aspect, the lead developer is definitely
| not the best representative of the project from a
| communication perspective as he might not have that kind of
| social skills (based on his posts). [1]
|
| But he (Micay) is an excellent security researcher, and has
| an excellent track record when it comes to prioritizing his
| users. There was a sponsorship in the beginning, where the
| legal entity, CopperheadOS tried to hijack the whole project.
| But Micay rather kill the project, than let the users'
| security suffer and revoked the signing keys. And I'm sure
| such a betrayal would cause anyone to lose a lot of faith in
| others' actions.
|
| > Give that person root
|
| Complete bullshit, what root?! And if anything, you are the
| one who are trying to discredit a project here, by sharing
| some dumb clickbait video.
|
| [1] I see that there is now a project manager doing most of
| the communication, which is an excellent solution!
| onli wrote:
| Do I have to explain what root is, or what are you not
| understanding about the concept of the software provider
| having complete control of the software on your phone and
| thus having root rights?
|
| Your CopperheadOS description is one perspective, one that
| does not look all that believable now after his mental
| illness became clear.
|
| I did not share the video, but I would and it is not
| clickbait.
|
| I will not further respond to you, I don't think this would
| lead to a fruitful discussion. Kindly think about what kind
| of trust is necessary to trust in the proper functioning of
| a device as personal as a modern phone, and think about
| attack scenarios that could occur when the main developer
| of your OS is not trustworthy in the slightest.
| other8026 wrote:
| > after his mental illness became clear.
|
| Here you are again in yet another comment repeating these
| baseless claims about mental illness.
|
| > think about attack scenarios that could occur when the
| main developer of your OS is not trustworthy in the
| slightest.
|
| First of all, he's not the main developer. There are
| multiple developers. The other developers do most of the
| development work these days.
|
| But to say that the OS is untrustworthy is completely
| false. You say GrapheneOS's founder has a mental illness
| based on watching a video where someone turned malicious
| toward the project recorded a conversation where the
| founder was extremely upset after being swatted multiple
| times.
|
| The update client doesn't send identifiers when checking
| for updates, and the update servers only have static
| files saved to them. You're making stuff up here, and
| clearly trying to turn people off of using GrapheneOS by
| repeating baseless claims that the founder is crazy and
| fake worries of being targeted by them.
| other8026 wrote:
| There's way much more to it than what you said here.
|
| > extremely hostile and threatened Rossman
|
| At the time, he was very upset. You know, because he was
| swatted multiple times. Of course he was upset when Rossmann
| showed his true colors and was trying to talk to him.
| Rossmann saw this as an opportunity and recorded it as it was
| happening. He tries to portray Daniel as crazy and people who
| attack the project and his friends on Kiwi Farms lap that
| stuff up.
|
| It's not true that he stopped using GrapheneOS, though. He
| continued using GrapheneOS for months after that video, which
| you can see by watching his later videos.
|
| > hallucinates
|
| Repeating baseless claims that he's crazy.
|
| > You have to be aware that you give that person root when
| you use Graphene.
|
| What? This is a very strange way to say it. Either way, it's
| literally impossible for someone on the GrapheneOS team to
| target someone like what was claimed in the video. GrapheneOS
| devices don't send identifiers when they contact the update
| server. The update servers also only host static files.
|
| > Calyx seems to be the best alternative right now without
| such a risk factor.
|
| The "risk factor" is completely false. It's all made up to
| attack GrapheneOS, making the founder look like a crazy
| person, then people are scared of using the OS. CalyxOS is
| not a hardened OS and rolls back security in some ways. It's
| not the next best alternative for people who care about these
| things.
| onli wrote:
| Nothing I said is baseless and contrary to you, I do
| provide sources.
|
| > _Of course he was upset when Rossmann showed his true
| colors_
|
| I saw the chats. You lie. Showing his true colors = not
| accepting that there is an evil conspiracy and asking for
| proof. You are completely brainwashed and I will not
| continue this discussion.
|
| If Calyx is not the next best alternative be invited to
| link to what you think is the best alternative. I still
| think it's Calyx.
| other8026 wrote:
| > I do provide sources.
|
| You provided exactly 0 sources in all of the comments
| I've seen posted by you so far.
|
| > Showing his true colors = not accepting that there is
| an evil conspiracy and asking for proof.
|
| "Evil conspiracy"? You say that someone else is paranoid
| and yet you are saying things like this? It's kind of
| ironic.
|
| > You are completely brainwashed
|
| Okay. If you say so.
| bernoufakis wrote:
| The main source is the video, where you can see the GOS
| developer writing him live. For more context, there was a
| Google Drive link that is unfortunately not available
| anymore, but I found and uploaded it here: <https://www.s
| wisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
|
| It has they initial conversation and disagreement in
| September 2022, after the GOS developer in question
| accuses Rossmann of being complicit with harassment
| campaigns again said dev., because he also gave the same
| 40K USD FUTO grant to other similar project and had some
| interview with their developers.
|
| The second set of files are the text messages that
| feature in the video, after said GOS developer contacted
| Rossmann umprompted on May 2023 with the same type of
| accusation.
|
| Feel free to peruse and make you own opinion.
| Klonoar wrote:
| ...you haven't provided any sources at all.
| onli wrote:
| I'm responding to it directly, the main source is the
| video linked in parent of this thread. Its description
| contains further links. I also did link to a relevant
| statement from the developer in a subthread here.
|
| All I said is sourced.
| bernoufakis wrote:
| The main source is the video, where you can see the GOS
| developer writing him live.
|
| For more context, there was a Google Drive link that is
| unfortunately not available anymore, but I found and
| uploaded it here: <https://www.swisstransfer.com/d/d75ff7
| 82-4a7d-4497-b04e-edd1...>
|
| It has they initial conversation and disagreement in
| September 2022, after the GOS developer in question
| accuses Rossmann of being complicit with harassment
| campaigns again said dev., because he also gave the same
| 40K USD FUTO grant to other similar project and had some
| interview with their developers.
|
| The second set of files are the text messages that
| feature in the video, after said GOS developer contacted
| Rossmann umprompted on May 2023 with the same type of
| accusation.
|
| Feel free to peruse and make you own opinion.
| aussieguy1234 wrote:
| The one thing that prevents me from switching my Pixel over is
| the lack of support for emergency services to see your location
| if you call the emergency number. I know this because I called
| twice while having GrapheneOS installed.
|
| I do some watersports and always take my phone with me, so
| letting emergency services see my location is good for my safety
| in case I ever got into trouble on the water. I also have a PLB,
| but I like to have two devices for redundancy, as is best
| practice.
| cromka wrote:
| This should be higher up.
| strcat wrote:
| GrapheneOS supports E911. It doesn't have Google's
| proprietary Emergency Location Services implemented as part
| of Google Play services which some countries depend on. We
| plan to implement the same standard it does for regions
| without support for a variant of E911:
|
| https://github.com/GrapheneOS/os-issue-tracker/issues/1174
| aussieguy1234 wrote:
| It the Australian emergency number (000). Not sure if
| they're using the Google Play services implementation of
| Emergency Location Services.
| strcat wrote:
| It sounds like you're in a region not supporting E911 but
| rather depending on Google's proprietary Emergency Location
| Service. We plan to make our own implementation of what that
| provides:
|
| https://github.com/GrapheneOS/os-issue-tracker/issues/1174
|
| GrapheneOS supports E911 and has our own network location
| implementation you can enable which gets used by it. Unlike
| Google's implementation, our network location is based on
| location position estimation similarly to iOS. Unlike iOS,
| we'll be providing full offline support for it.
| gf000 wrote:
| Thank you very much for your work here!
| bugsMarathon88 wrote:
| Counter-point: Pixel 9 with GrapheneOS, location services off,
| Netguard installed and active; I engage with emergency services
| on a regular basis for work and always receive the public
| record which tracks the incident. The reported coordinates are
| almost always within 100' of my actual location, so YMMV.
| mjbale116 wrote:
| While a big proponent of this, to my mind, it seems a bit
| counterintuitive to place your trust in a community who will
| probably cannot be held into account once some bad actor slips
| into their ranks, creates a bad patch and empties my bank
| account.
| gruez wrote:
| >counterintuitive to place your trust in a community who will
| probably cannot be held into account once some bad actor slips
| into their ranks
|
| Open source software is everywhere. Do you think Microsoft or
| Redhat going to be held to account if they accidentally added
| some backdoored OSS code? Moreover all of the development
| happens in the open and you can build it yourself. I'm not sure
| what the alternative is. Just trust Apple has their shit
| together with iOS?
| rtkwe wrote:
| You say the same thing about Linux? This feels like old open
| source FUD, the only case I know of off hand is the xz util
| backdoor and that was found and patched before the malicious
| patch had made it into the main distribution channels.
| mbananasynergy wrote:
| Hi there. GrapheneOS community manager here.
|
| It's important to note that GrapheneOS is not some niche
| barely-used project. It has existed since 2014 and is used by
| multiple hundreds of thousands of people at this point. There
| are also many eyes on the project through people forking it to
| make their own products, people maintaining their own builds
| etc. GrapheneOS is also reproducible in addition being open
| source.
|
| On our side, we are very particular about accepting outside
| contributions if they don't need meet our standards, and code
| is heavily reviewed within our team before being merged.
|
| I'd also recommend giving https://grapheneos.org/faq#audit a
| read through.
|
| All in all, your concern, while valid, isn't something that's
| likely to happen precisely because we're very aware of
| situations where it has (see xz) and are therefore very
| vigilant. The kind of thing you're worried about isn't likely
| to come from a big project like GrapheneOS that has many eyes
| on it, but rather something small that's used everywhere and
| barely has a couple of devs working on it, if that (again, see
| xz).
| chasil wrote:
| However, do you consider yourselves as able to resist a
| nation-state level adversary with resources dedicated to
| compromising you?
|
| I think of two things, the Solar Winds build corruption, and
| putty's mishandling of e521 keys.
|
| What is your vulnerability to a similar disaster, exploited
| or not?
| Attrecomet wrote:
| Funny how your mayer example is actually proprietary
| closed-source software. So being an open source project
| carried by a large community doesn't seem to be an actual
| drawback -- if at all, a Solarwinds-like attack is far more
| improbably to succeed in a popular and well run open source
| project than in the darkness of closed source.
| Crontab wrote:
| > it seems a bit counterintuitive to place your trust in a
| community who will probably cannot be held into account once
| some bad actor slips into their ranks, creates a bad patch and
| empties my bank account
|
| From what I have observed, nobody is held to account when there
| is a software issue, commercial or open source.
| bugsMarathon88 wrote:
| This take demonstrates most people's inability to rationally
| threat-model: you would rather trust a known-abusive authority
| than an unknown-good samaritan, because of a false notion your
| bank balance is actually significant enough to warrant such an
| attack.
| nullc wrote:
| Google also cannot be held to account, its legal team out
| resources countries and if you attempt to litigate at best they
| will just keep you busy until you're bankrupt.
|
| At least graphene wouldn't be expected to shield the
| perpetrator.
| throwaway-0001 wrote:
| The main missing feature is password under duress that would open
| a different "user". So even if you're forced to give away your
| password they won't get to the real account (some hidden profile
| or similar).
|
| At least hidden profiles would be good enough for basic
| protection.
|
| They have this which wipes your device, but you can get killed
| under duress. https://discuss.grapheneos.org/d/14722-using-
| duress-password...
| OsrsNeedsf2P wrote:
| I've seen this be requested for years from various mod users.
| Is it too difficult to implement or something?
| throwaway-0001 wrote:
| They say a hidden profile is not secure enough so not worth
| implementing.
|
| I rather have this hidden profile that would stop 99% of
| criminals than what they have now.
|
| I think their approach to this project is to deliver real
| security at the cost of features.
| mbananasynergy wrote:
| GrapheneOS community manager here. The problem with something
| like this is that it cannot be reasonably hidden when it would
| be exposed by someone using basic tools. Our Duress
| PIN/Password feature doesn't make any attempts to mask itself,
| precisely because we think doing that only gives people a false
| sense of security.
|
| We think there's a good chance a motivated adversary is going
| to be familiar with GrapheneOS and its features, and the more
| mainstream it becomes, the more this can mean "your abusive
| significant other" rather than someone at the border.
|
| The moment people know this feature exists, it can become
| dangerous even if you don't use it. You can be threatened to
| unlock, and even if you do, the adversary can choose to not
| believe you since they can think you're just hiding it. That
| puts you in a dangerous situation where they think you can
| provide something that's literally not there.
|
| It's a very difficult problem to solve, and we don't think that
| proposal can solve it.
| throwaway-0001 wrote:
| Tbh I'd say 99% of the criminals won't know about this.
|
| Let's say someone have you at gunpoint, you can just give
| your mains profile pass.
|
| If they don't even know there is a secret profile you're good
| to go.
|
| You're right, they might assume you're hiding, but I'd say
| 99% won't know what's even graphene and from those who know
| I'd say they might force you and you can have 3 sets of bank
| accounts:
|
| Main profile: 100 Secondary: 1000 Terriary: $$$
|
| Also if you hide all traces of grapheneos would be safer too.
| Nobody even knows is graphene, so they can't even check what
| features you have. Again we are talking about 99% of the
| criminals, not the tech savvy 1%.
|
| I'd prefer plausible deniability like Vera crypt than what we
| have now.
| mbananasynergy wrote:
| You can argue most bad people won't know about it - but I
| would say we can't really know.
|
| I think the main problem is that people can be affected
| that aren't even using it, which is why it is such a big
| problem. You can't really hide it's GrapheneOS either, even
| just by virtue of the features available on the device,
| you'll be able to deduce what it is.
|
| I understand the idea behind it but it simply isn't
| realistic to provide and can put people in danger - the
| very thing it's meant to prevent.
| throwaway-0001 wrote:
| But also in your case criminals can threaten you to give
| access to bank accounts you don't have.
|
| When I say hide, again for 99% of the people. Splash
| screen, setting spoofing. Sometimes good enough is better
| than perfect.
|
| And even if the attacker can see the other profile you
| can just say was your friend's profile and it's lost.
|
| Or better, not sure if possible: export the profile in a
| file like veracrypt. Then when you need the profile
| import from this file and would restore the secret
| profile.
| AndyMcConachie wrote:
| > Tbh I'd say 99% of the criminals won't know about this.
|
| It's not about criminals. It's about the police, government
| spy agencies, and other knowledgeable threat actors.
| cromka wrote:
| I think this feature nowadays would be mostly for the border
| control checks, especially in the US. Basically to avoid
| being sent back over a JD Vance meme found at a glance, as
| opposed to actually being held hostage.
| YoumuChan wrote:
| I hate to say this but I don't foresee Graphene being
| "mainstream". Most users will stick to the stock ROM. The
| most "mainstream" custom ROM Lineage is only installed on
| 0.04% of Android devices as of 2023 [1]. Even if Graphene
| appears in some mainstream news, I highly doubt any ordinary
| person can recognize it when they see one.
|
| If the threat model is hiding from random people, I think a
| hidden profile works very well.
|
| Now let's talk about motivated adversary as you put it.
| Hidden profile and wiping are not either-or, they can
| coexist. If one is really targeted by a motivated adversary,
| it should be apparent in most cases, and the targeted person
| can choose to enter the wiping PIN instead of the secondary
| profile PIN.
|
| Now if one is targeted by a really motivated and threatening
| adversary, I don't think wiping PIN is any better than
| secondary profile PIN. The moment one chooses to wipe the
| phone, the adversary could be triggered by the action and
| harm the victim anyway.
|
| [1] https://9to5google.com/2023/11/20/lineageos-number-of-
| device...
| mbananasynergy wrote:
| GrapheneOS isn't a project that plans to be an aftermarket
| OS forever. In fact, we're currently working with an OEM to
| have their devices have official GrapheneOS support. This
| can mean devices being sold with GrapheneOS without someone
| even having to install it.
|
| We're of the opinion that there's a growing portion of the
| population that is becoming more security and privacy
| conscious, and that's reflected in our userbase, which has
| been growing consistently over the last few years.
|
| We're not saying we're going to have iPhone's marketshare,
| but we're constantly growing.
|
| >Now if one is targeted by a really motivated and
| threatening adversary, I don't think wiping PIN is any
| better than secondary profile PIN. The moment one chooses
| to wipe the phone, the adversary could be triggered by the
| action and harm the victim anyway.
|
| Yes, but at that point, the data is irreversibly rendered
| inaccessible. There are situations where the data itself is
| the most important factor, and where the owner of the
| device being hurt doesn't benefit the adversary now that
| the data is gone. Of course, as with everything, it depends
| on one's situation, but the duress PIN feature doesn't
| involve trickery. It's a way to reliably and quickly do a
| very specific thing.
| crossroadsguy wrote:
| > In fact, we're currently working with an OEM to have
| their devices have official GrapheneOS support
|
| Oh god, yes. Please! I can't wait to leave the walled
| fruit garden, but can't tolerate Google sniffing
| everything I do or do not do on my phone either.
|
| PS. I just hope it's an OEM that sells devices to a lot
| of countries including developing ones and not something
| like Fairphone.
| ThePowerOfFuet wrote:
| Google has no access to anything you do on a Pixel with
| GrapheneOS installed just because it's their hardware.
| CommenterPerson wrote:
| Explain this please. With enough detail for the HN gurus.
| YoumuChan wrote:
| I think it is all about audience. There is no one-size-
| fit-all. Different audience have different threat models
| and different requirements.
|
| For a corporate using an OS in work phones. The threat
| model is state/corp-sponsored actors. Trade secret leak
| is unacceptable. When in doubt, data should be wiped. Now
| wiping PIN makes total sense and is the only sensible
| option.
|
| An ordinary person, on the other hand, often deals with
| non tech-savvy ordinary people. The threat model is
| different. Most likely plausible deniability is enough.
| The threat level is low. Those users may accept to trade
| some data security for a more friendly feature.
|
| The ultimate question is whether Graphene envisions
| itself an opinionated OS that always follows the "best
| practice" or a generic OS that allows users to define
| their own threat models.
| dotancohen wrote:
| > we're currently working with an OEM to have their
| devices have official GrapheneOS support.
|
| It's a long shot, but please see if you can get this
| vendor to include an EMS stylus like the Samsung Note
| devices and S Ultra devices. That is what is keeping me
| on Samsung, and I will be one of their first customers if
| they have an integrated EMS pen.
| bogwog wrote:
| These are ridiculous scenarios to try and optimize for. A
| smartphone feature isn't going to save someone from an
| abusive spouse or a serial killer, and if it does, it'll be
| an exceptional situation.
|
| There was a youtuber who got kidnapped in Haiti a while
| back, and his kidnappers demanded to search the photo
| gallery on his phone for something. So what he did was
| delete the pictures, but not empty the trash, hoping they
| wouldn't know about that feature. They didnt, and he got
| away with it. Did Apple envision a kidnapping scenario when
| they were designing that feature? Probably not. Is there a
| design lesson that can be taken from that situation? Also
| probably not, because it just as easily could have gone the
| other way.
| jrexilius wrote:
| There are certain threat/risk models where having multiple
| profiles might be helpful (non-forensic examination by an
| offical at a securtiy screening kinda scenario). But you're
| right, it's nuanced, requires know-how by the user, and
| possibly a foot-gun for some caught unawares. NOT an easy
| problem to solve. Personally, as a user, I'd like the ability
| to be able to choose that option in the instances where I
| needed it, but it's likey a TON of work for a very small
| actual user community who needs it.
| rendx wrote:
| I remember a conversation with a political activist refugee.
| They were in a group of people who got checked at the border,
| and were asked to unlock their laptops. The border security
| personnel then proceeded to do a short inspection of the
| visible systems. They all used Veracrypt's Hidden Operating
| System functionality, and while it would be trivially
| detectable, the border security did not, so they got through
| without problems. If they had refused to "unlock", or used a
| duress passphrase that wiped the system without presenting a
| dummy version, they would have been held, possibly for a very
| long time, and definitely not allowed to exit.
|
| Moral of the story: Different contexts allow for different
| solutions. It is a sign of false privilege to make
| assumptions, and not let the user decide. An argument can be
| made in terms of priority of implementation, but not in terms
| of "pointlessness". The often used argument of "false
| security" can be addressed by warnings; yes, some people may
| not understand the implications, but you do not need to make
| _their own_ (bad /good) choices for them; that's paternalism,
| not care.
|
| In the real world, where thanks to my political work I am in
| contact with many people who had to endure real-world
| security checks, police raids, investigations, and so on, in
| all the cases no proper (imaginary) forensic analysis was
| performed. People make mistakes and remain uneducated -- on
| both sides. The "But NSA!" argument brought forward typically
| by white techbros kills a lot of useful technology before it
| even exists, which is unfortunate for those that would
| actually benefit from it, and when asked would tell you so.
| It's also not either/or in reality: In many situations, it
| will buy you time (while e.g. your lawyer may try to get you
| and your devices out of the situation), and even if they find
| out you were trying to fool them, they may give you another
| chance, and then you can still opt for the wipe code. It
| makes a huge psychological difference to have multiple
| options and feel in control.
| bugsMarathon88 wrote:
| This hyperbole is extreme, and unnecessary. If your life
| depends on the ability to simulate a fake user on a phone,
| there are more significant problems than a lack of operating
| system features, and a general failure to defend in depth.
| kragen wrote:
| This is a fully general argument against any single thing
| your life might depend on: seat belts, defibrillators,
| bulletproof vests, etc.
|
| If the only thing protecting you from getting shot to death
| is a bulletproof vest, clearly a lot has already gone very
| wrong, and you're likely to die today anyway. But that kind
| of thinking is exactly what leads to a failure to defend in
| depth.
| Ros23 wrote:
| GrapheneOS Discussion Forum: "This site is best viewed in a
| modern browser with JavaScript enabled. " Security my ass ...
| To "GrapheneOS community manager" - please fix this. Where is
| .onion site?
| progval wrote:
| You can read it just fine with Javascript disabled, though.
| gf000 wrote:
| Security doesn't mean you have to go feed the cows and leave
| behind everything.
|
| In fact, a core aspect of security is having access to a
| feature in the very first place.
|
| A forum, being hosted on the web has absolutely no reason to
| stay away from the de facto scripting language of the
| platform. What would be your threat model for that forum? A
| zero day that would break the whole world?
| ThePowerOfFuet wrote:
| It's Discourse.
| mbananasynergy wrote:
| We use Flarum for our forum, but Discourse similarly only
| allows one to view forum posts without JavaScript enabled.
| mbananasynergy wrote:
| It is possible to view the forum without JavaScript being
| enabled, but not sign in and post. We use Flarum for our
| forum, and that's a limitation of the platform.
| anthk wrote:
| Join usenet: https://www.eternal-september.org
|
| Subscribe to comp.mobile.android. Sadly there's no libre
| client yet, but Mozilla might release a Thunderbird version
| with NNTP support.
| strcat wrote:
| We use Flarum as our forum software for
| https://discuss.grapheneos.org/. Flarum supports viewing all
| of the content without JavaScript via an HTML fallback mode
| using pagination. Flarum simply informs people they'll have a
| better experience with JavaScript enabled.
| ChrisArchitect wrote:
| Related:
|
| _Cops say criminals use a Google Pixel with GrapheneOS - I say
| that 's freedom_
|
| https://news.ycombinator.com/item?id=44658908
|
| _Cops in [Spain] think everyone using a Google Pixel must be a
| drug dealer_
|
| https://news.ycombinator.com/item?id=44473694
|
| _ICEBlock, an iOS Exclusive_
|
| https://news.ycombinator.com/item?id=44672521
| minimalist wrote:
| Last I heard, Google discontinued publishing device trees and
| driver binaries for Pixel devices with their recent changes to
| their stewardship of the AOSP [0]. Was it something definitive or
| are they merely delayed? If the practice is being discontinued,
| what would be the reason why? Doesn't publishing these artifacts
| create a business case for customer demand for the Pixel devices?
| Or is there some cost that outweighs the benefits? Is it
| maintainer overhead?
|
| I didn't bring this up when it was a news story last month
| because there was a lot of cynicism in the thread, but I am
| genuinely curious. I am really grateful for both GrapheneOS and
| Google for creating a phone platform that Just Works for the
| essential stuff and that I can reasonably recommend to non-
| technical people!
|
| [0]: https://news.ycombinator.com/item?id=44259921
| NewJazz wrote:
| I heard unsubstantiated rumors that it was somehow antitrust-
| related. If they are selling off their device business (again),
| then it makes sense that the device drivers would not be part
| of AOSP...
| strcat wrote:
| > If they are selling off their device business
|
| Android and Chrome are potentially going to be split from
| Google:
|
| https://www.nytimes.com/2024/11/20/technology/google-
| search-... (https://archive.ph/egRL4)
|
| Pixels are no longer the Android reference devices. An
| Android company ending up with the OS, Google Play and
| Google's OEM partners wouldn't need Pixels. That's a possible
| reason for the change. However, the simplest explanation is
| that they're continuing to take cost cutting to an extreme
| where it negatively impacts their long term revenue far more
| than the money it saves. A lot of Pixels were sold due to
| first class support for using other operating systems
| including it not voiding the warranty.
| strcat wrote:
| Android 16 no longer provides device trees for Pixels as part
| of the Android Open Source Project. It's important to note it
| doesn't provide those for any other devices. There are no other
| OEMs providing similar AOSP support. A few OEMs publish more
| basic device trees for older Android versions. This was Pixels
| losing one of their advantages compared to non-Pixels but it
| was never one of our hardware requirements, which are listed at
| https://grapheneos.org/faq#future-devices. It isn't part of why
| Pixels are the only devices meeting our requirements. We're
| working with a major Android OEM to change that though,
| hopefully for 2026 or at least 2027.
|
| GrapheneOS typically ports to new yearly Android releases in a
| couple days and tends to have it reach the Stable channel in
| under 2 weeks. We completed our initial port to Android 16 in a
| similar time period after the release on 2025-06-10. However,
| we then had to reimplement device support in a similar way to
| how we would support a non-Pixel device. Our initial production
| release based on Android 16 was published on June 30th. As
| usual, we had to spend around a week making a series of
| releases fixing regressions reported by users. It reached our
| Stable channel on July 8th.
|
| Since our port to Android 16 took significantly longer than
| usual, we backported most of the Android 16 firmware, all of
| the kernel drivers and parts of the userspace device support to
| our now obsolete Android 15 QPR2 branch and did a few more
| releases based on Android 15 QPR2 where we were able to provide
| the full 2025-06-05 patch level which also turned out to be the
| full 2025-07-05 patch level due to no vulnerability fixes in
| the July 2025 Android Security Bulletin or Pixel Update
| Bulletin. This was an unusual approach and not generally a
| reasonable way of doing things. We were able to do it
| successfully.
|
| It won't be nearly as much of an issue going forward since we
| dealt with building the new automation we needed. Our port to
| Android 16 QPR1, Android 16 QPR2, Android 16 QPR3, Android 17,
| etc. shouldn't be nearly as difficult and we should get back to
| our typical porting time for major releases.
| minimalist wrote:
| I suppose this means that supporting future Pixel devices
| will be more difficult? If someone has the ear of anyone at
| Google, especially someone who works with Android, please
| share this cause with them!
| poisonborz wrote:
| The comment above was describing in great detail how this
| is not the case and after some initial effort should prove
| no difference at all.
| fifteen1506 wrote:
| Generic power-user here: I am going to guess without the
| backing of Google going forcefully open-source, "niche"
| hardware such as Google's Tensor will lose their
| attractiveness.
|
| However one must note also that for now not even Snapdragon
| fulfills GOS requirements. If/when that changes, Snapdragon
| devices may have more open-source community momentum than
| Google's Tensor. Plus all the economy of scale, etc..
|
| In terms of security, Microtek is even more far behind
| Snapdragon.
|
| Again, not an Android dev here, take the text above with a
| grain of salt, YMMV, etc..
| 71bw wrote:
| Is it now possible to build a custom release of graphene for
| any of my non-Pixel devices or will that, again, bring
| graphene ninjas to my abode?
| notachatbot123 wrote:
| > We're working with a major Android OEM to change that
| though, hopefully for 2026 or at least 2027.
|
| Is there any chance that you fabulous guys could lobby for a
| smaller <5 inch phone with that OEM? (reference
| https://news.ycombinator.com/item?id=44586723)
| backscratches wrote:
| Seconded! Need a smaller phone! and video out means i can
| make screen biggger if i want!
| LMYahooTFY wrote:
| The Sony Xperia XZ1 Compact was the perfect size phone and
| I hate the world for not having successors of the same
| size.
| johnisgood wrote:
| The phone I am currently using has the following
| dimensions: 165.2 x 75.7 x 9.1 mm (6.50 x 2.98 x 0.36
| in). I think it is a sweet spot for me. I would not go
| for larger than this.
| preisschild wrote:
| Do you guys all have that small pockets? I have a 6.7"
| Smartphone and never had an issue with its size
| DanHulton wrote:
| Oh it's not pockets. I just have tiny raccoon paws for
| hands.
|
| I like being able to reach across the keyboard one-handed
| (to shift, etc) and I can't do that on modern, larger
| phones.
| strcat wrote:
| It will start out being their regular phones with security
| and updates improved to meet the requirements of
| GrapheneOS. When we demonstrate there's a huge demand for
| it after the products launch, we can have more influence.
| Our focus would be adding some security features not
| available on Pixels. The current aim is preserving the
| security we get from Pixels, but the future goals are more
| ambitious.
| wishfish wrote:
| As you're working with the OEM, I hope you'll consider a
| model which will come with either an IPS screen or is
| compatible with a 3rd party IPS replacement.
|
| I bought a Pixel 9 Pro Xl specifically to use with
| GrapheneOS. Unfortunately, its OLED and my eyes were
| incompatible. The PWM on the screen was terrible and I had to
| return it after some headaches.
|
| Of course, none of that was the fault of GrapheneOS. I
| absolutely loved using it and think your project is vital.
| backscratches wrote:
| Agreed, pixel oled (and iphone oled) make my eyes blurry
| and achy and ia ssume its the pwm. ips laptop, other phones
| never have this effect
| preisschild wrote:
| for me a non-OLED screen would be a non starter. I love
| reading text (white text with black background) and
| watching HDR videos on OLED screens
| spankibalt wrote:
| > "As you're working with the OEM, I hope you'll consider a
| model which will come with either an IPS screen or is
| compatible with a 3rd party IPS replacement."
|
| Ahaha, don't get your hopes up, friend. The possibility of
| an adequate, degoogled Android with picky requirements as
| GOS on good, ultramobile hardware (matte DCI-P3 IPS, 3.5 mm
| audio, USB-C 3.2 or better, dedicated, ideally quick-access
| mSD card slot, IP68 rating, good cameras, EMR pen
| compatibility, changeable battery, non-plastic case) is
| virtually _nil_. That would essentially be a modern hybrid
| between a Samsung XCover Pro 6 and one of the older Samsung
| Note phones, e. g. the Note 9. Days long gone... :(
| ranguna wrote:
| Quite a lot of detail on this comment, thanks for that!
|
| But I'm still left a bit confused about the future devices
| GraphaneOS will support:
|
| Because you said discussion are being done with an OEM, will
| GraphaneOS switch from pixels to a different device?
|
| You also said that not having the device tree won't be a
| major hurdle in building GraphaneOS for the future, does that
| mean we can expect the pixel 10 to have GraphaneOS or it's
| too early to know ?
|
| Thanks again!
| mbananasynergy wrote:
| Pixel 10 will be supported by GrapheneOS provided it
| continues to meet our requirements - we'll know when it's
| out. It'll definitely take us longer than it has before.
|
| A collaboration with an OEM doesn't mean we'll stop
| providing existing or future Pixels if they continue to
| meet our requirements.
| strcat wrote:
| > Because you said discussion are being done with an OEM,
| will GraphaneOS switch from pixels to a different device?
|
| Pixels will be supported until end-of-life. Future Pixels
| will be supported if they continue meeting our
| requirements.
|
| > You also said that not having the device tree won't be a
| major hurdle in building GraphaneOS for the future, does
| that mean we can expect the pixel 10 to have GraphaneOS or
| it's too early to know ?
|
| We expect 10th gen Pixels to meet our requirements and we
| should be able to add support for them. It's not going to
| happen in 12 to 48 hours from the official launch of the
| devices as we did for around the Pixel 6a and later. It
| will be more work. We've automated most of the device
| support for existing Pixels now and have removed nearly all
| of the Android 15 QPR2 device trees rather than manually
| updating them. We're continuing to automate more and will
| use that approach for supporting new Pixels.
|
| The devices with an OEM partner are further in the future
| than the Pixel 10. We need Qualcomm's new SoC with hardware
| memory tagging support to launch because a flagship
| Snapdragon is the best fit other than the current lack of
| hardware memory tagging. Some things need to be addressed
| by the OEM including licensing extra things like Qualcomm
| and filling in some missing features. There needs to be a
| clear, workable plan for updates including Linux kernel LTS
| branches.
| ulrikrasmussen wrote:
| I am so excited about the thought of a GrapheneOS native
| phone!
| ysnp wrote:
| It may be permanent and I think this was the official indirect
| response:
|
| "AOSP needs a reference target that is flexible, configurable,
| and affordable -- independent of any particular hardware,
| including those from Google." [0]
|
| Emphasis on independent of any particular hardware.
|
| Current speculation/inference suggests it is because of the
| antitrust case against them, preparing for the possibility that
| they may be divested of Android (or at least to decouple in
| meaningful ways [1]).
|
| [0]: https://www.androidauthority.com/google-not-killing-
| aosp-356...
|
| [1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-
| will-...
| VladVladikoff wrote:
| This is almost enough to make an Apple fanboy switch to android.
| Maybe I'll get a second phone just to try it out. Which model
| would be best?
| BLKNSLVR wrote:
| If it's just for trying out, then go for the cheapest second
| hand Pixel that's still supported by GrapheneOS and still has a
| battery that can hold charge for as long as you need it to for
| testing.
|
| I bought a second hand Pixel 7a for my recent migration.
| Battery isn't great, but it's good enough to get me through a
| day.
| strcat wrote:
| Battery life improved a lot with the 9th gen Pixels other
| than the Pixel 9a due to the dramatically more efficient
| cellular radio. Set it to "4G" or the GrapheneOS added "4G
| only" as the cellular network mode and you should save a lot
| of battery life compared to having 5G enabled all the time.
| Battery life heavily depends on the apps, network and overall
| configuration. It's easy to end up with bad battery life with
| lots of apps doing their own push, etc.
|
| GrapheneOS users tend to avoid using Google services when
| possible and this has a battery life cost when using apps
| like Signal with their own push systems. In the case of
| Signal, Molly is a fork with UnifiedPush support that's more
| efficient but it requires running a server to convert FCM to
| UnifiedPush since Signal doesn't support it.
| mbananasynergy wrote:
| Anything 8th gen and later would be best, as those models
| support MTE which is a huge security feature not present on 6th
| or 7th gen hardware.
|
| Our recommended devices can be found here:
|
| https://grapheneos.org/faq#recommended-devices
| h4kunamata wrote:
| It is insane the amount of "news" about GOS that somehow get
| things wrong. It cannot be coincidence but misinformation on
| purpose. On Twitter, GOS team have to often reply with the actual
| correct information, it is insane man.
|
| Reading some comments here regarding hidden profile, security
| through obscurity doesn't and will never work. Add to that the
| fact that GOS is well known now, those people think that if they
| were forced to give their phone away, they won't have to disclose
| the hidden profile??? Newbies!!
|
| I don't wonder why GOS team never bothered to prioritise this.
|
| I have been using GOS for a few years now, it is perfect, full
| control over everything, the teams support is like no other and
| full transparency about everything, the release notes are like no
| other.
|
| I really hope this project will never die.
| throwaway-0001 wrote:
| I know you talking about my hidden profile. But let say you
| have a banking account you don't want people to find out.
|
| Currently you can only keep it on the main profile or any other
| secondary, which are easily visible.
|
| With my approach you can minimise 99% of the risks for most
| users.
|
| And even so, you can have 2 hidden profiles. So you can always
| show the decoy hidden profile.
| bugsMarathon88 wrote:
| Graphene is a fantastic operating system for Pixel devices.
| Simple, reliable and with plenty of security and privacy features
| to make you feel warm and fuzzy. System updates are automatic,
| actual phone functionality is flawless, perhaps the only
| complaint to be had is the quality of camera, which probably
| lacks proprietary drivers. Signal works fairly well - even
| without abusive Google Services installed, making this a perfect
| daily mobile driver. Much gratitude to the developers of this
| project.
| gf000 wrote:
| Didn't try it in a long while, but I remember being able to run
| the proprietary pixel camera app just fine.
| mbananasynergy wrote:
| GrapheneOS does not degrade the camera quality at all. The
| quality will depend on the app being used. If you use Pixel
| Camera on GrapheneOS, you'd be getting the experience you'd get
| on stock OS using that same app. Similar for our built-in
| camera app.
| jrexilius wrote:
| I just installed Graphene on a new pixel. I've only used it for
| two days, but I got that same feeling of "finding buried treasure
| in your backyard" I got when I first installed Linux in 1999. I
| can't believe this amazing software is free in all senses of the
| word. It is a TON of work and they got so much right. The
| security and usability settings give all the grainular control
| I've known was possible and wanted for a long time.
|
| I see some core team on this thread, so just wanted to say THANK
| YOU! Awesome job! Keep fighting for the users!
|
| I'm totally the wrong person to offer recommendations on mobile,
| but so far it works very well for me, but then, I use almost no
| third party apps, and none of them are Play store only. My only
| complaint is the hardware (outside of their control).
| 1024core wrote:
| Where do you get the apps from? Google's App Store?
| robmusial wrote:
| F-Droid app store. https://f-droid.org
| morserer wrote:
| Aurora Store on F-Droid is a FOSS frontend for the Google
| Play Store that is a seamless drop-in. Requires no Play
| Services, nor an account.
| bboygravity wrote:
| But than the apps you download (your banking app) require
| play services right?
|
| So then what's the point of having a Play Store without
| Google Play services?
| ThePowerOfFuet wrote:
| Many apps claim to require Play Services, but all my
| (several) bank apps work perfectly on GrapheneOS. No
| notifications because they rely on Google, but that is
| more feature than bug in my books.
|
| Signal brings its own notifications, so they work
| perfectly.
|
| The only app which was broken to the point of unusability
| was Too Good To Go, which demands that you pick locations
| on a map which relies on Play Services; the manual city
| entry is broken.
|
| I use Google Maps only in Firefox Focus, but I've heard
| that builds of Google Maps up to about a year or so ago
| didn't rely on Play Services, and with Aurora Store you
| can manually enter a build number to install.
|
| tl;dr: 10/10, fabulous experience.
| anthk wrote:
| Uh GF uses TooGoodToGo, I might try if it works with
| MicroG and the companion app which appears at FDroid
| (can't recall now the name, but it appeared with Droidify
| and some repos). It must be a Play Services API
| placeholder out there too.
|
| Install Droidify, enable the repos, and install "microG
| Services" and "microG Companion".
| easyKL wrote:
| Need the Maps data, the satellite picture, or StreetView?
| All these past years this WebView wrapper have been
| working like a charm
| https://f-droid.org/packages/us.spotco.maps
| gf000 wrote:
| GrapheneOS managed to make Google play services into
| normal android services, without higher privileges that
| they have on other android systems.
|
| I am personally more than okay with using the official,
| proprietary GP services from time to time if they abide
| by the same rules, especially that I can make these rules
| as strict as _I_ want.
| unethical_ban wrote:
| Not all apps on play store require play services.
|
| And even if you install Google play on your graphene
| phone, it is still more isolated by default. Add that to
| the concept of storage scopes and more permissions
| control (apps have to ask for access to the network) and
| you have a more secure platform.
| homebrewer wrote:
| It doesn't work for everything; one of the banks I'm forced
| to use checks for how it was installed, and Android for
| some incomprehensible reason is happy to report that to any
| application that asks (along with lots of other information
| like bootloader status and developer mode -- you really
| have fewer rights to 'your' device than random
| applications).
|
| After opening the application, it complains about being
| installed through an "insecure method", and bails.
| Reinstalling through Google Play magically fixes that.
|
| These "security checks" are spreading like measles, so
| expect to see this sooner or later.
| mschuster91 wrote:
| > one of the banks I'm forced to use checks for how it
| was installed, and Android for some incomprehensible
| reason is happy to report that to any application that
| asks
|
| That's because apps that aren't published just on the
| Play Store but also on other stores or for direct
| sideloads (for users running Huawei for example which
| doesn't have Play Store) need to be able to detect the
| installation method to do updates on their own if there
| is no backing store.
| const_cast wrote:
| The use case makes some amount of sense, but I think once
| an API becomes predominantly used for fingerprinting and
| the real use case becomes a side effect you should just
| nuke the API.
|
| It's the responsible thing to do. Apple has done it a few
| times.
| mikae1 wrote:
| Obtanium[1], F-Droid[2], Aurora Store[3] and FFUpdater[4] are
| some options. Signal self updates from the APK download[6].
|
| I recommend putting proprietary Play Store apps grabbed with
| Aurora Store in the work profile with Shelter[5].
|
| [1] https://obtainium.imranr.dev/
|
| [2] https://f-droid.org/
|
| [3] https://f-droid.org/packages/com.aurora.store/
|
| [4] https://f-droid.org/packages/de.marmaro.krt.ffupdater/
|
| [5] https://f-droid.org/packages/net.typeblog.shelter/
|
| [6] https://signal.org/android/apk/
| tkel wrote:
| Work profiles are inferior to separate user profiles, which
| are built-in to GrapheneOS.
|
| Also "private space" is now available with Android 15 and
| can provide the same separation within a single user
| profile.
| Unroasted6154 wrote:
| Don't you have user profiles in Pixels? I can create
| another user an switch. Just not super convient. Work
| profiles are actually pretty good good... For work.
| piaste wrote:
| > Work profiles are inferior to separate user profiles,
| which are built-in to GrapheneOS.
|
| Different use cases. User profiles are only active when
| you manually switch to them, while work profiles are
| active _alongside_ your main profile.
|
| So for untrusted apps that you only use occasionally and
| on-demand (like the myriads of travel / shopping / random
| services apps), user profiles are great. For apps that
| you want to keep in the background, such as the
| proprietary messaging apps that all your friends use, a
| work profile is much nicer.
| strcat wrote:
| Private Space is very similar to a user profile but
| nested inside of another user. GrapheneOS adds shared
| clipboard control for Private Space which was the main
| disadvantage compared to a secondary user.
|
| GrapheneOS supports having a Private Space in secondary
| users instead of only a single one in Owner. Supporting
| multiple Private Spaces per user is a planned feature at
| which point work profiles will be fully obsolete. The
| remaining use case for work profiles is to have both a
| Private Space and work profile in the Owner user.
| shaky-carrousel wrote:
| I put them in the private space. Is there an advantage on
| putting them in the work profile?
| Happily2020 wrote:
| Private space is identical to work profile. In the past,
| private space didn't exist and people used work profile
| instead as a workaround, but now that's not needed.
| strcat wrote:
| Private Space has a superior approach to isolation and
| encryption matching user profiles. Work profiles have
| some compromises for historical reasons. Private Space
| should be preferred over a work profile and the only
| reason to use a work profile for your own local usage is
| to use both a work profile and Private Space at the same
| time. Once GrapheneOS has support for multiple Private
| Spaces within a user, the use case for work profiles will
| be limited to the intended Bring Your Own Device
| enterprise deployment purpose. The intended purpose of
| work profiles is companies not having to give their
| employees work phones but rather owning/controlling a
| specific profile on their device with some influence over
| the overall device via rules for lock method, etc.
| rkrisztian wrote:
| On the GrapheneOS forum you will see a lot of bad opinions
| about F-Droid, for example this:
|
| > It doesn't matter that the app is trustworthy, because
| F-Droid are extremely incompetent with security and the
| apps you install from F-Droid are signed by F-Droid rather
| than the developer.
|
| https://discuss.grapheneos.org/d/20212-f-droid-security-
| in-s... https://discuss.grapheneos.org/d/18731-f-droid-
| vulnerability...
|
| They also say, if you use F-Droid, at least use F-Droid
| Basic:
|
| > Dont use the main F-Droid client. Android is pretty
| strict about SDK versions and as F-Droid targets legacy
| devices, it is very outdated.
|
| https://discuss.grapheneos.org/d/11439-f-droid-vsor-droid-
| if...
|
| > If the app is only available on F-Droid / third party
| F-Droid repo, use F-Droid Basic and use the third party
| repo rather than the main repo if available. > > If the app
| is available on Github then install the APK first from
| Github then auto-update it using Obtanium. Be sure to check
| the hash using AppVerifier which can be installed from
| Accrescent (available on the GrapheneOS app store).
|
| https://discuss.grapheneos.org/d/16589-obtainium-f-droid-
| bas...
|
| By the way, while GrapheneOS recommends Accrescent, I don't
| use it anymore because they can't even add apps like
| CoMaps, while some of the apps they actually added are
| proprietary.
| prmoustache wrote:
| >the apps you install from F-Droid are signed by F-Droid
| rather than the developer.
|
| That doesn't seem like a con if you take into account the
| context: F-droid is not shipping pre-build binaries from
| the developper, it asks for a buildable project from the
| developper.
|
| If the source repo of the upstream dev are compromised,
| so will be hid own binaries anyway.
| indigane wrote:
| > [A]pps you install from F-Droid are signed by F-Droid
| rather than the developer.
|
| Having recently gone through the F-Droid release process,
| I learned that this is not necessarily the case anymore.
|
| F-Droid implements the reproducible builds concept. They
| re-build the developer's app, compare the resulting
| binary sans signature block, and if it matches they
| distribute the developer-signed binary instead of their
| re-built binary.
|
| This is opt-in for developers so not all apps do it this
| way. I'd sure like to know how common this is, I wonder
| if there are any statistics.
| rixed wrote:
| If the signatures are the same, what difference does it
| make which binary is distributed?
| strcat wrote:
| F-Droid only uses reproducible builds for a tiny portion
| of apps, and there are still significant disadvantages.
| It depends on the app developers always complying with
| F-Droid's rules otherwise users are left without updates.
| F-Droid only checks that the build matches, they do not
| review/audit the apps and will not catch hidden malicious
| behavior or simply non-compliance with their rules.
| WireGuard's app deliberately broke F-Droid's rules by
| including a self-updater which was not noticed by F-Droid
| and shipped by F-Droid. WireGuard used this to start
| taking over updates for itself to migrate their users
| away from F-Droid. F-Droid eventually found out when the
| WireGuard developer brought it up many months later and
| couldn't do anything beyond dropping the app. It had
| taken over updates for itself already and F-Droid wasn't
| in the picture anymore.
|
| The process adds a significant delay for updates but it
| does not actually protect users from developers in any
| meaningful way. This real world example with WireGuard
| demonstrates that.
| cf100clunk wrote:
| Also check out Neo Store: ''An F-Droid client with modern
| UI and an arsenal of extra features.''
|
| https://github.com/NeoApplications/Neo-Store
| Andromxda wrote:
| Just to add to that: Even some proprietary applications let
| you download their APK right from the website. WhatsApp is
| one such example (I don't recommend that you use it, Signal
| is much better, but if you require it, you don't have to
| use the Play Store).
| nicman23 wrote:
| have you used something like lineageOS before?
| sierra1011 wrote:
| GrapheneOS? On a Pixel? You must be one of those criminals /s
| haloboy777 wrote:
| Arrest this individual
| dgan wrote:
| do you need to access your mobile for bank accounts ? does that
| work ?
| gf000 wrote:
| As a single datapoint, revolut does not work unfortunately,
| so I moved back to the default pixel OS.
| cyanwave wrote:
| I can't recall the switch, I believe it's mem exploit
| protection. When disabled it typically fixes banking apps.
| You tried that?
| senorqa wrote:
| Revolut does work for me. They added support for GrapheneOS
| long time ago
| backscratches wrote:
| Did you have to turn off mem exploitation? And have
| google play services? Revolut did not work for me
| recently.
| gf000 wrote:
| Thanks, then I might have another go at graphene! That
| was the only reason I went back to vanilla "pixel OS".
| lollobomb wrote:
| Can you please clarify the Revolut part? Just to
| understand, you are saying that you are able to perform
| NFC payments via the Revolut app which you installed on
| your Graphene OS through the official Play Store? Where
| are you based? (asking because I start having the doubt
| that it might be geo-dependent)
| jcul wrote:
| Revolut works perfectly for me.
|
| What kind of issues did you have? I think it does require
| google play services (which can be installed easily).
|
| I have used GOS on a pixel 6 for the past two years with no
| issues. The phone finally died on me last weekend, so I'm
| in the market for a new pixel which will be getting GOS
| right away.
| lollobomb wrote:
| Can you please clarify the Revolut part? Just to
| understand, you are saying that you are able to perform
| NFC payments via the Revolut app which you installed on
| your Graphene OS through the official Play Store?
| Andromxda wrote:
| GrapheneOS published a workaround for that in an update in
| January. https://grapheneos.org/releases#2025012600
|
| https://grapheneos.social/@GrapheneOS/114772578787013282
| jakweg wrote:
| It depends what banking apps you use. Some are available.
| From my observation major banks in Poland work just fine. You
| can pay via NFC using the mBank app if you need to. Revolut
| also works fine. gPay just doesn't work however therefore you
| cannot pay with this via NFC. I use my Garmin watch to pay
| for all things in physical stores anyway, so no need for NFC
| payments anyway.
| lollobomb wrote:
| Can you please clarify the Revolut part? Just to
| understand, you are saying that you are able to perform NFC
| payments via the Revolut app which you installed on your
| Graphene OS through the official Play Store? And you are
| based in Poland?
| ZeWaren wrote:
| I have a rooted Graphene on a Pixel 9, and the only bank
| which isn't working is Revolut.
| rahen wrote:
| You shouldn't root Graphene, it breaks its security model
| and is certainly the reason why Revolut doesn't work on
| your phone. It works like a charm on mine.
| izacus wrote:
| Someone's keeping a list of banking apps known to currently
| work with GrapheneOS:
| https://privsec.dev/posts/android/banking-applications-
| compa...
|
| Check if yours is on the list.
| throw3827245 wrote:
| I'm always afraid of my phone getting stolen or losing it
| somewhere so I have a completely separate iPhone, which runs
| my banking apps. I keep that phone at home.
| dotancohen wrote:
| Depending on where you live, a burglary might be more
| common than a robbery. Why don't you just use the bank's
| website on your desktop computer (assuming you have a
| desktop computer)?
| spaqin wrote:
| Because in infinite banking sector's wisdom, logging into
| the website requires a confirmation with the mobile app.
| exe34 wrote:
| I've changed banks for less.
| bornfreddy wrote:
| I'm in a similar position and I hate it. They somehow
| managed to convince themselves that if you issue tokens
| for 2FA within the mobile app it is still "two" factor
| authentication. Of course since you already have mobile
| app now, you can just use it directly (and there is no
| way to disbale that). So while webapp is 2FA, there is
| now a mobile app which is not. Good thinking.
| ekianjo wrote:
| Are there banks without such requirement these days?
| bubblethink wrote:
| Schwab works with totp as 2fa.
| mixmastamyk wrote:
| Last time I looked they required some Symantec BS to
| intermediate. Has that ended?
| theandrewbailey wrote:
| I'm concerned about losing phones too, so I don't bank on
| any phone.
| lawn wrote:
| In Sweden all the banking apps I've tried works, including
| BankID.
| ibotty wrote:
| Can you use mobilepay? (Or is that not a thing in Sweden?)
| lawn wrote:
| I've never heard of it.
|
| In Sweden we typically use Swish, which again works
| great.
|
| "Tap to pay" things are problematic though but it's not
| something I personally use (even before I migrated away
| from stock Android).
| ulrikrasmussen wrote:
| I hate that many banking apps refuse to run on non-Google
| OSes. I can see that my banking app doesn't even work on
| GrapheneOS based on the link given in a sibling comment. It
| makes absolutely no sense from a security perspective since I
| am still able to log in using the browser, and the web app
| has the exact same UI and authorization flows as the actual
| app.
|
| It all seems like a security theater with the consequence
| that, ooops, we just vendor locked in all our customers to
| run a less secure OS by a company whose business it is to
| collect personal data and show ads that people don't want to
| see.
| mvieira38 wrote:
| Banking apps are spyware, that's why they avoid open source
| OSes, not because they want to vendor-lock you. Smartphone
| data collected by a banking app is basically the most
| valuable in the world for advertisers, as they get the
| telemetry instantly crossed with a full(ish) picture of
| your spending habits and all the KYC identifiers too.
| ruszki wrote:
| No, the reason is legal. Everything, and I mean
| everything else is secondary. They can tell in court that
| they did everything what they could. Of course:
|
| - it's a lie
|
| - not even a white lie, they know perfectly well, that
| they can do way more
|
| - most of the security "features" are completely useless
|
| - they also know this
|
| However, it's very difficult to prove these, and laymen
| don't and won't understand the details.
| mixmastamyk wrote:
| Is there a link that explains this for bank apps
| specifically?
| eks391 wrote:
| Have a second profile with fewer restrictions for those apps
| you think you need but don't want to compromise security for.
| My second profile has one app, which is my banking app with
| all the dependencies it rudely requires for functionality
| AndyMcConachie wrote:
| I agree. I love using Graphene OS. Came for the security,
| stayed for the lack of bullshit.
| lrvick wrote:
| > I can't believe this amazing software is free in all senses
| of the word.
|
| I wish that were true, but if you delete the 100s of binary
| blobs (many with effectively root access) copied from a stock
| donor vendor partition the phone won't function at all.
|
| There is no such thing as a fully open source and user
| controlled Android device today.
| rtpg wrote:
| Was there ever? And is the situation improving or worsening?
|
| I am alright with things that allow for improvement, at least
| in theory
| couscouspie wrote:
| Anyways, we as informed consumers are hopefully all
| agreeing on striving for an open mobile OS and open
| hardware. For those of us, who consider themselves
| democratic, that is even an imperative.
| bornfreddy wrote:
| Not sure what the situation is with Librem, Pine and
| Joola/SailfishOS, maybe those qualify?
| A4ET8a8uTh0_v2 wrote:
| I tried librem and pine a year or so ago. As long as it
| is basic phone use ( phone, text ), it is ok for daily
| use. That said, the experience is nowhere near ok
| experience in terms of speed or responsiveness, when
| compared to most basic android phones. I do not know if
| that changed since, but librem left a bad taste in my
| mouth based on how they seem to operate. Pine, by
| comparison, was a lot more honest about its limitations.
| strcat wrote:
| The Librem 5 and Pinephone are closed source hardware
| with closed source firmware. It's a misconception that
| they're open source. They have open source drivers, not
| hardware and firmware.
|
| SailfishOS is not open source itself. It's far less open
| source than Android which has the Android Open Source
| Project with the whole base OS.
| lrvick wrote:
| Open source drivers is a big step forward we must not
| discount, creating a separation between hardware trust
| and OS trust.
|
| That said, to your point, both are misrepresented as
| fully open frequently which is just not true, and
| obscures efforts by teams that are working on fully open
| hardware solutions the hard way.
| mixmastamyk wrote:
| Purism uses U-Boot on the Librem5 and modified coreboot
| (in other places) I believe.
|
| https://docs.u-boot.org/en/latest/board/purism/librem5.ht
| ml
| lrvick wrote:
| Replicant was the last time we had fully open Android
| devices. We have regressed.
| strcat wrote:
| All of those were closed source hardware with tons of
| closed source firmware. Not shipping firmware updates
| doesn't mean the firmware doesn't exist. There aren't
| open source devices in general. It's not specific to
| smartphones.
| lrvick wrote:
| The entire point of Replicant was replacing all mutable
| closed software, firmware, and blobs with open
| alternatives and they did to a large degree succeed at
| that isolated goal.
|
| Sadly this was, to your usual points, at the major
| expense of security making those devices purely research
| projects at best and not something anyone should ever
| actually use.
|
| When you are stuck on a platform that requires closed
| firmware you are kind of stuck blindly accepting updates
| from the vendor to patch security bugs, stuck hoping they
| are not actually introducing new backdoors.
|
| This is why I reject platforms that require closed
| firmware in the first place to the fullest extent I can.
| cherryteastain wrote:
| This is also the case with mainline linux though. Good luck
| using Nvidia graphics with only FOSS components.
|
| Even more FOSS friendly graphics vendors like AMD and Intel
| rely on binary firmware.
| bowsamic wrote:
| Indeed, mainline linux distros aren't free software either
| lrvick wrote:
| I have run nvidia cards without proprietary drivers for
| years. Nouveau.
|
| With the right hardware choices running blob-free linux
| is pretty straightforward.
| Andromxda wrote:
| > Nouveau.
|
| Which Nvidia card do you have, and at which clock speed
| does your GPU run?
|
| > With the right hardware choices running blob-free linux
| is pretty straightforward.
|
| Unfortunately no. Features like SSE are pretty amazing
| and have made CPUs really fast and efficient, but they're
| unfortunately also large attack vectors, so
| vulnerabilities like Spectre or Meltdown occur. You need
| proprietary microcode blobs to fix those security
| vulnerabilities in your CPU.
| lrvick wrote:
| An Nvidia GPU is never going to run at maximum clock
| speed etc on open drivers right now, but the point is if
| you prioritize security/privacy/freedom you have choices.
|
| If you are not running games (which you should not on a
| system you need to be able to trust) maximum clock speed
| from a modern GPU is not needed for most workstation
| applications.
|
| I generally choose AMD GPUs for the best experience with
| open drivers these days on systems I need high GPU
| performance from.
|
| > You need proprietary microcode blobs to fix those
| security vulnerabilities in your CPU.
|
| Really? Which blobs do I need on RISC-V FPGA enclaves or
| my PPC64le Talos II workstation which has a fully open
| hardware motherboard and open CPU architecture?
|
| I make different tradeoffs on different hardware to be
| sure depending on the threat model of the task I am
| working on. x86_64 is a bit of a shit show, but you still
| only have to trust your CPU vendor even there, as it is
| possible to have FOSS firmware/software for everything
| else.
| cherryteastain wrote:
| > generally choose AMD GPUs for the best experience with
| open drivers these days on systems I need high GPU
| performance from.
|
| Do you count binary firmware as 'open' or not? If not,
| AMD is not 'open' either. If you do, Nvidia now also has
| open kernel drivers. Mesa developers are exploring ways
| to get the new Mesa Nvidia Vulkan driver (NVK) to run on
| top of the open Nvidia kernel driver, which should
| eventually make Nvidia drivers as open as AMD.
| lrvick wrote:
| The binary firmware on an external module over a PCI bus
| should not have the ability to manipulate my current
| operating system and exfiltrate data without being
| noticed, but it is a non zero chance which is why on all
| my x86_64 workstations I run QubesOS so most hardware
| components are well isolated from each other with
| hypervisors, in addition to only open source code in my
| operating system and kernel layers, which is best effort
| today on such systems.
|
| I generally only run gaming graphics cards on dedicated
| gaming machines, not on workstations I need to be able to
| trust. You can't use accelerated graphics in qubes
| anyway, specifically because graphics cards are hard to
| trust.
|
| My requirements from a workstation are:
|
| 1. MUST have 100% open source code loaded in system
| memory
|
| 2. SHOULD have open source software in the boot trust
| path (coreboot/tpm2 secure boot, etc)
|
| 3. SHOULD have open hardware to the furthest extent
| possible that meets my use case
|
| 4. SHOULD be fully auditable and tamper evident using at-
| home tools and methods (like the Precursor)
| Andromxda wrote:
| > maximum clock speed from a modern GPU is not needed for
| most workstation applications
|
| Well at that point buying a GPU is definitely not worth
| your money. You're better off using a CPU's integrated
| graphics unit.
|
| > I generally choose AMD GPUs for the best experience
| with open drivers these days on systems I need high GPU
| performance from.
|
| Yeah I agree on that, I also purchase AMD cards
| exclusively now.
|
| > Which blobs do I need on RISC-V FPGA enclaves or my
| PPC64le Talos II workstation
|
| I assumed we were only talking about x86. But I also
| believe that POWER9 CPUs don't have SSE, prove me wrong.
| I guess you're running Linux? I'd be very interested in
| looking at the output of _lscpu_ from one of these
| machines.
|
| > x86_64 is a bit of a shit show
|
| I fully agree there
| strcat wrote:
| Laptops, desktops, smartphones or tablets are closed source
| hardware with closed source firmware in general. There are
| products marketed as if they're open source devices which
| are in fact closed source hardware with almost entirely
| closed source firmware. The software on top being open
| source is frequently misrepresented as the device itself
| being open source, which isn't the case. Not shipping
| important firmware updates in the OS provides assurance of
| insecurity while not changing the fact that the hardware
| and firmware is closed source. It has to do with a loophole
| defined in a certain ideology around software, not open
| hardware or privacy/security.
| morserer wrote:
| It's not all grim. GrapheneOS utilizes IOMMU to isolate the
| baseband and sandbox the wireless components. Even with
| binary blobs, the wireless radios cannot read encrypted
| traffic.
|
| https://grapheneos.org/faq#baseband-isolation
|
| Sure, it's not perfect, but it's still really, really good.
| Even with the binary blobs that are on it, Graphene phones
| have been impossible to unlock via commercial cracking tools
| _since 2022._
|
| https://osservatorionessuno.org/blog/2025/03/a-deep-dive-
| int...
| strcat wrote:
| Laptops, desktops, smartphones or tablets are closed source
| hardware with closed source firmware in general. There are
| products marketed as if they're open source devices which
| are in fact closed source hardware with almost entirely
| closed source firmware. The software on top being open
| source is frequently misrepresented as the device itself
| being open source, which isn't the case. Not shipping
| important firmware updates in the OS provides assurance of
| insecurity while not changing the fact that the hardware
| and firmware is closed source. It has to do with a loophole
| defined in a certain ideology around software, not open
| hardware or privacy/security.
| gf000 wrote:
| As opposed to using what, hand gestures? There is simply no
| production ready hardware with non-proprietary software at
| all.
| palata wrote:
| > As opposed to using what, hand gestures
|
| As opposed to "being free in all senses of the word", which
| is what the comment was talking about.
| rst wrote:
| People go through all sorts of weird mental gymnastics
| about this. The FSF at one point took the position that
| binary blobs were cool so long as _they could not be
| upgraded_ , because then you could pretend they weren't
| software at all, but just part of the wiring. I've seen
| this odd line of thought attributed to RMS himself, but
| here's an FSF statement, from when he was running it:
| https://www.fsf.org/blogs/community/task2-openmoko
| const_cast wrote:
| Yes, which is a huge problem. This is a big part of why
| Android phones suck so much ass - you're often stuck on old
| versions of android because the hardware vendors are too
| lazy to update their proprietary bullshit blobs that barely
| fucking work.
|
| And now you're running a two year old phone and it's
| effectively obsolete.
|
| If they would just upstream their firmware into the Linux
| kernel, you could upgrade these phones for years and years.
| Until the hardware is actually physically incapable of
| running the latest features.
|
| Some vendors, like Google, promise to provide updates for a
| long time. But it's just that - a promise. There's no
| technical guarantee or mechanism for this, it's purely
| based on trust.
| lrvick wrote:
| No production ready -mobile- hardware, I would agree.
|
| The Precursor is promising, but software is not there yet.
|
| I sit down at my desktop computer and send emails and type
| messages like this one. Then I get up from my desk and
| spend time with my family offline and present. It's pretty
| great.
| matheusmoreira wrote:
| Let's not allow the perfect to be the enemy of the good.
| GrapheneOS does what it can to isolate those things as much
| as possible. It even makes good use of hardware features such
| as the IOMMU. It's a huge improvement on the status quo, even
| though it's not going to pass FSF RYF certification.
| strcat wrote:
| FSF RYF certification is anti-freedom, anti-privacy and
| anti-security. Pretending hardware is open because there
| aren't closed source components which are / can be updated
| doesn't make sense. They certify closed source hardware
| with closed source firmware. In many cases, privacy and
| security has been crippled to obtain the certification by
| preventing important firmware upgrades. Not shipping
| firmware updates in the OS doesn't mean the firmware isn't
| there and doesn't make the hardware or firmware open
| source. GrapheneOS wants to have actual open source
| hardware and firmware, not what the FSF is peddling. We
| certainly don't want to block people getting important
| firmware upgrades needed to defend devices. FSF heavily
| misleads people about these topics for ideological reasons.
| matheusmoreira wrote:
| I agree with you. I think FSF RYF is a pointless
| certification since firmware isn't going away anytime
| soon. I'm not a fan of their "it's part of the wiring if
| you can't upgrade it" compromise either since it doesn't
| achieve their goals and makes the situation even worse.
|
| It would be nice if the firmware itself was free software
| so that it could be shipped alongside the Linux kernel,
| maintained indefinitely and we could customize it however
| we want. The hardware is supposed to do what we want it
| to do, not what the manufacturer lets us do.
|
| I don't like the fact every single device out there has
| entirely separate computers inside them running unknown
| proprietary software. It feels like our operating systems
| aren't operating the system anymore, it's like they're
| just some user app sandboxed away from the real system.
| This presentation explains what I mean:
|
| https://youtu.be/36myc8wQhLo
|
| It's an imperfect reality. Security by isolation of
| devices via IOMMU addresses real concerns such as devices
| being able to access RAM via DMA. It's great that
| GrapheneOS is doing this.
| strcat wrote:
| Laptops, desktops, smartphones or tablets are closed source
| hardware with closed source firmware in general. There are
| products marketed as if they're open source devices which are
| in fact closed source hardware with almost entirely closed
| source firmware. The software on top being open source is
| frequently misrepresented as the device itself being open
| source, which isn't the case. Not shipping important firmware
| updates in the OS provides assurance of insecurity while not
| changing the fact that the hardware and firmware is closed
| source. It has to do with a loophole defined in a certain
| ideology around software, not open hardware or
| privacy/security.
| lrvick wrote:
| Plenty of laptops exist you can get away with running fully
| open source and auditable firmware, and a few that are
| mostly open hardware too, by the MNT Reform team.
|
| The Precursor is the only pocket computer platform that is
| maximally open hardware, software, and firmware but you
| revert back to the 90s in terms of power as a consequence
| with alpha quality software today. If Bunnie is successful
| with his IRIS approach and making custom home-user-
| inspectable ASICS then maybe a middle ground path can be
| forged in the next few years.
|
| For now the only modern computing experience with fully
| open hardware and software I am aware of are the ppc64le
| based devices by Raptor Engineering, but at a very high
| cost due to low demand, with huge form factor and no power
| management. I still own one anyway because we have to start
| somewhere.
|
| For those that want this story to get better, please buy
| and promote the products of the few people trying to break
| us out of dependence on proprietary platforms.
| csmattryder wrote:
| I got it installed last weekend, really powerful mobile OS.
|
| I did do about three weeks of research, as I worried that maybe
| a number of apps wouldn't run on it or needed some form of deep
| attestation. Didn't find much, OpsGenie and other work apps are
| happy with the GOS level of attestation provided.
|
| Great to have Google kicked off the phone. So nice to shut off
| the network permission for any apps that only require an
| internet connection to serve ads.
|
| One tip from me, if you came from stock Pixel: You can download
| the default Pixel sounds and set them up like it was. Have a
| look for "Your New Adventure" online, the message sound is
| "Eureka".
| exe34 wrote:
| > So nice to shut off the network permission for any apps
| that only require an internet connection to serve ads.
|
| For those of us who aren't ready to cut the umbilical cord to
| the mothership, you can also root/firewall on normal android
| to stop this. In fact I choose to not be able to use banking
| apps in order to cut out the crappy ads.
| morserer wrote:
| Root, while more efficient, isn't strictly necessary.
| AdAway (FOSS, F-Droid) can run without root using the stock
| Android VPN backend.
| exe34 wrote:
| I use both adaway and AFWall+, as I don't like random
| apps making random connections, even if it's not for
| adverts. Once google play store ate my monthly data
| allowance, and it will never happen to me again.
| strcat wrote:
| RethinkDNS is implemented as a VPN service but it has
| support for local filtering combined with optionally
| using a WireGuard VPN or multiple chained WireGuard VPNs.
| You can have both via the VPN service API rather than
| choosing one or the other. No need for app accessible
| root access.
| Harvesterify wrote:
| For those who don't want to root the phone, you can still
| avoid most of the ads by using a filtering DNS server with
| the Private DNS functionality on stock Android ROMs (or
| only at browser level if your favorite browser support DNS
| over HTTPS).
|
| It comes with some minor usability issues with captive Wifi
| portals sometimes, but the trade-off of not having ads in
| app or while browsing is way worth it IMHO.
| strcat wrote:
| You can use RethinkDNS and avoid compatibility issues
| with captive portals. This is one of the options we
| recommend for GrapheneOS users. RethinkDNS is implemented
| as a VPN service but it has support for local filtering
| combined with optionally using a WireGuard VPN or
| multiple chained WireGuard VPNs. Android's captive portal
| handling works with a VPN and VPN leak blocking active
| since the connectivity checks are specially marked as not
| going through the VPN and so is the captive portal
| handling component opened by the captive portal
| notification. Private DNS is still missing support for
| this and also has the issue of causing DNS leaks for
| secondary profile VPNs.
| backscratches wrote:
| Graphene has a really great sandboxed google servicen
| implementation, so barring a handful of banking apps not
| working, switching to graphene is a very gentle cutting of
| the mothership. For me it was very subtle, with better
| battery life!
| jeroenhd wrote:
| Even without root, a VPN-style firewall will work against
| all non-system apps. The downside of this approach is that
| you can't combine one with another VPN app.
| username135 wrote:
| Are you referring to something like Karma on fdroid?
| jeroenhd wrote:
| Yes. I used to run NetGuard, but Karma seems to work very
| similarly.
|
| It looks like there's an app on F-Droid called "Rethink"
| that promises to do both firewalling, DNS blocking, and
| offers a WireGuard VPN. That seems promising, though I
| must add that I haven't tested it myself.
| DeepSeaTortoise wrote:
| Rethink isn't quite ready yet. Depending on your use case
| you can go without getting thrown off by a bug for weeks,
| but when it fails it can be quite annoying. And don't use
| the GPlay version, but the FDroid or GitHub one.
|
| On the other hand, the functionality is top notch. Easily
| the best integration of consumer level DNS + firewall
| blocking in any application on any platform. Just block
| everything of an application by default and then watch
| the connection logs for the app and start unblocking
| stuff via ips, domains or wildcards until the app starts
| working again.
| johnisgood wrote:
| I have been using Rethink, I think it is great.
| strcat wrote:
| RethinkDNS is implemented as a VPN service but it has
| support for local filtering combined with optionally
| using a WireGuard VPN or multiple chained WireGuard VPNs.
| You can have both via the VPN service API rather than
| choosing one or the other. No need for app accessible
| root access.
| jrexilius wrote:
| The Netguard app worked well for me for that on vanilla
| burners and such. No root, "VPN" that I had block pretty
| much everything but the browser and Signal.
| strcat wrote:
| > For those of us who aren't ready to cut the umbilical
| cord to the mothership
|
| You can use Google apps and apps depending on them on
| GrapheneOS via sandboxed Google Play. The vast majority of
| Android apps can be used. You don't need to stop using
| Google apps/services or other mainstream apps to use
| GrapheneOS. It's likely nearly all the apps you use or even
| all of them work on GrapheneOS. There's a per-app exploit
| protection compatibility mode toggle (and finer-grained
| toggles) to work around buggy apps with memory corruption
| bugs. We avoid turning on features breaking non-buggy apps
| by default and hardware memory tagging is temporarily opt-
| in for user installed apps not marked as compatible due to
| how many memory corruption bugs it finds.
|
| A small number of apps are unavailable due to checking for
| a Google certified device/OS via the Play Integrity API.
| These are mostly banking apps, but most banking apps do
| work on GrapheneOS. There are tap-to-pay implementations
| which can be used on GrapheneOS in the UK and European
| Economic Area. Several banking apps recently explicitly
| added support for GrapheneOS via hardware-based attestation
| as an alternative to the Play Integrity API. We're pushing
| for more apps to do this and for regulation disallowing
| Google from providing an API to app developers for
| enforcing devices licensing Google Mobile Services. Play
| Integrity API often portrayed as a security feature but
| Google chooses not to enforce a security patch level.
| They're permitting devices with years of missing important
| privacy and security patches but not a much more private
| and secure OS. Only their strong integrity level has a
| patch level check, but the check is only done for recent
| Android versions and only requires they aren't more than 12
| months behind on patches which serves no real purpose.
|
| > you can also root/firewall on normal android
|
| This is different from our Network permission which not
| only blocks direct access but also indirect access via APIs
| requiring Android's low-level INTERNET permission. Our
| Network permission also pretends the network is down
| through many of the APIs. For example, scheduled jobs set
| to depend on internet access won't run.
| throwaway-0001 wrote:
| I think they don't even have basic location mocking. They have
| disable or enable. But some apps won't work.
| eks391 wrote:
| Not by default, but there are several apps on F-Droid that do
| this
| johnisgood wrote:
| Can you give me one that works on a stock Android? I used
| to use one but it no longer works on newer Androids.
| strcat wrote:
| It's a standard Android feature with various apps available
| for different use cases. Some are for setting a specific
| location, others are for using an external device. It's a
| very generic feature. GrapheneOS plans to add a different
| feature called Location Scopes similar to our Contact
| Scopes and Storage Scopes features for setting a per-app
| location. Android's Mock Location is global.
| skim wrote:
| I believe this is in the works:
| https://bsky.app/profile/grapheneos.org/post/3lqbhoqwrjs2y
| strcat wrote:
| Mock Location is a standard Android feature available in
| GrapheneOS. Our upcoming Location Scopes feature is being
| added for per-app control rather than global.
|
| It's fairly pointless for apps to check for Mock Location
| being active without also verifying the OS via the Play
| Integrity API or hardware attestation API. Most apps checking
| for it are using or in the process of adopting the Play
| Integrity API. Apps enforcing the Play Integrity API
| basic/strong integrity level won't work on GrapheneOS unless
| they explicitly allow it. A growing number of apps doing this
| are explicitly allowing GrapheneOS. It would be
| counterproductive if our Location Scopes API didn't provide a
| way for apps to check if since those apps simply wouldn't
| permit GrapheneOS. However, it doesn't need to be the
| existing Mock Location API. It can be our own API which would
| only be used by apps explicitly choosing to permit
| GrapheneOS. This would allow apps like Pokemon Go and Ingress
| to permit GrapheneOS even if they insist on not allowing
| directly spoofing location.
| sebastiennight wrote:
| My understanding is that Mock Location on android is a
| developer setting that apps can easily check for, and as
| such, is basically useless (it will not fool any app that is
| asking for your location).
|
| It's basically only useful for debugging.
| squigz wrote:
| https://grapheneos.org/donate
|
| If you want it to stay free
| b8 wrote:
| I'd install Graphene OS in a heartbeat on my Pixel if they'd add
| support for Google call screening and feature like Hold for me.
| Thise features are why I bought my pixel and it's too much of an
| inconvenience to go without them now. Spam calls have went down
| significantly and has saved me a lot of time.
| aesh2Xa1 wrote:
| I believe spam detection in the Google Phone app does work on
| GrapheneOS.
|
| For spam, install their sandboxed Google Play, and then install
| Google's Phone and Speech Recognition & Synthesis apps. For
| SMS/MMS/RCS spam, you'd use an app supporting blocking (e.g.,
| Google Messages).
|
| I imagine that Hold For Me works if you also install the Google
| app and whatever other dependencies.
| largbae wrote:
| The most fun feature of GrapheneOS is the ability to look at the
| logs of any app at any time from the App Info page.
| Sytten wrote:
| Been using it for the past two years and supporting the project.
| I personally love it but you do have to tinker a bit once in a
| while so I would hesitate to put it in the hands of my parents
| (though I bought them pixel just in case). Google Pay not working
| is mildly annoying (hoping to get PayPal or Curve eventually).
| Android Auto works but I didnt yet try to make voice commands
| work. Some app behave weird if you block access to the sensors
| (though it is nice to be able to do it). Sandboxed google play
| works great for the most part.
| hft wrote:
| My workaround for using both NFC payments and Graphene OS is
| wearing a Google Pixel Watch (1). All other Google Wallet
| features besides NFC payments should work.
|
| [1] https://discuss.grapheneos.org/d/475-wallet-google-pay/4
| danieldk wrote:
| Sadly that solution does not work everywhere. In a lot of
| countries, Google Pay cards are added by the bank's app and
| it's on the bank to support rolling out cards on WearOS as
| well. A lot of banks in my country only support putting a
| card in Wallet on phones, but not WearOS watches (not sure if
| it is laziness on their part or whether security of WearOS
| watches is not deemed acceptable in general due to the lack
| of secure elements, shorter/no PINs, etc.).
| icar wrote:
| Curve NFC payments work for me.
| rdescartes wrote:
| Why firefox in andriod is "more vulnerable to exploitation" ?
| worldsavior wrote:
| https://grapheneos.org/usage#web-browsing
| ndriscoll wrote:
| Does Vanadium include the necessary APIs for uBlock Origin?
| Otherwise this seems like having a long explanation of how
| secure the windows are with titanium frames and bulletproof
| glass while the front door is wide open.
| worldsavior wrote:
| uBlock origin won't save you from exploits in Firefox. The
| only way it would've might save you is if you disabled
| first-party JS, which you might as well just disable in the
| browser itself.
|
| Chromium still is the superior browser in terms of security
| and Firefox is way behind. Adding an extension so you
| _might_ have less security exploits in the foundation is a
| wrong tactic and should be avoided.
| ndriscoll wrote:
| Real world threats generally aren't exploiting process
| memory errors or whatever. Unless they're in the shadier
| parts of the web, users are unlikely to encounter such
| things even when they might exist. Spyware and adware
| threats on the other hand are ubiquitous and highly
| likely to be encountered by nearly everyone. A web
| browser that doesn't mitigate that is simply not fit for
| purpose. It's a table stakes security requirement.
| ysnp wrote:
| Vanadium implements per-site content filtering as a
| usability feature via Chromium's in-built filtering engine
| [0]. They currently use EasyList & EasyPrivacy filters
| which are quite popular and also a prominent default in
| uBlock Origin [1].
|
| [0] https://grapheneos.org/features#vanadium
|
| [1] https://github.com/gorhill/uBlock?tab=readme-ov-
| file#ublock-...
| Night_Thastus wrote:
| I've been interested in Graphene OS, but being limited to just
| the Pixel phones is kind of lame. Have a Galaxy A55 I'd have
| liked to try it with.
| tonydav wrote:
| I've been using graphene since 2 weeks. It's been great. I'm only
| missing 1 feature: auto call recording.
| morserer wrote:
| Not automatic, but the GrapheneOS dialer supports call
| recording out of the box.
|
| During a call, drag your buttons and they will scroll. The call
| recorder is the 7th button.
| mbananasynergy wrote:
| We recently made it so that the call recording option is not
| hidden away. If there are 7 options, it's RTT that will be
| the last one now, and we've made the scroll bar always be
| visible to make it clearer to people that they can scroll
| there.
| ajb wrote:
| It's interesting that the only devices complying with the
| security requirements are Google's.
|
| I wonder if Google actually has an internal version of Android
| that's more security-focussed. Given that critical engineers'
| personal devices being hacked should be a security threat that's
| on Google's radar, it's possible.
| bernoufakis wrote:
| According to the developers, beside the AOSP software itself,
| there seems to also be hardware requirements that only the
| Pixel satisfies.
|
| https://grapheneos.org/faq#future-devices
|
| As a large company, they are probably targeted through their
| devices and since they have the means, it does make sense that
| the Pixel devices have high security standards compared to
| other OEMs.
| tholdem wrote:
| Why do you think that's interesting? Google is highly respected
| for its security practices. Do you think Apple engineers use
| some special hardened iOS?
| strcat wrote:
| Our hardware requirements are listed at
| https://grapheneos.org/faq#future-devices. There are a small
| subset of other devices with at least nearly all of the
| security features we require. However, those devices either
| don't allow using another OS or cripple security for it.
| There's no other device providing the listed security features
| and allowing us to support it. Pixels are also the only devices
| properly keeping up with current Android OS and security
| updates. We need ongoing firmware and driver updates. There are
| other devices offering support for a similar time period, but
| not actually providing close to the same thing during that time
| period.
|
| Most OEMs do the bare minimum for security. The security
| features they provide are the ones provided for them by AOSP,
| the SoC vendor, etc. They provide delayed and quite incomplete
| security patches.
|
| Android downplays the fact that it has OS releases every month.
| There's a new monthly, quarterly or yearly release each month.
| The monthly Android Security Bulletin patches are a separate
| thing providing backports of a subset of the security patches
| (most High and Critical severity AOSP patches) to older initial
| yearly releases (the initial releases of Android 13, 14, 15 and
| 16). There are also a huge amount of SoC and other hardware-
| related security patches with a small subset included in the
| Android Security Bulletin. Most OEMs struggle to provide these
| backports and vendor patches on time for a reasonable time
| period. Non-Pixel OEMs eventually update to a new initial
| yearly release, usually quite late, then rely on the backports
| to it for a year or more. Full Android security patches mean
| shipping the latest stable releases, which have been through
| significant public testing beforehand for quarterly/yearly
| releases and are not actually bleeding edge. Quarterly releases
| are as large as yearly ones but awareness of them existing is
| low. Android 16 QPR1 currently in Beta has more user-facing
| changes than Android 16.
|
| We're working with a major Android OEM towards some of their
| future devices meeting our requirements and providing official
| GrapheneOS support. It will be their regular devices but
| meeting our requirements currently only Pixels do. Hopefully
| available in 2026 or 2027. There's no reason other devices
| can't provide comparable or better security than Pixels, but
| it's not easy or cheap.
| sebtron wrote:
| I have used LineageOS [0] for a few years on my old phone, and
| last year I got a Pixel 4 and I am using Graphene on it. Both
| systems work well and I am really glad they exist; Graphene gets
| extra points for its extremely easy installation process.
| Unfortunately it seems Graphene is already phasing out support
| for the Pixel 4 [1], so I'll have to switch back to Lineage at
| some point.
|
| The only technical limitation I have encountered using these ROMs
| is related to GPS: my position is often lost and I need at least
| multiple minutes to gain it back (or sometimes it never comes
| back, depending on where I am). This is likely related to not
| using Google's location services, even though I have turned on
| all settings like using WiFi / bluetooth to improve the location
| accuracy. I tried every advice I found online, without luck.
| Somehow the issue is a bit worse on Graphene, as my position is
| lost every time I close the Maps app, but it may be related to
| the phone and not the OS.
|
| [0] https://lineageos.org/
|
| [1] https://grapheneos.org/faq#supported-devices
| ThePowerOfFuet wrote:
| >The only technical limitation I have encountered using these
| ROMs is related to GPS: my position is often lost and I need at
| least multiple minutes to gain it back (or sometimes it never
| comes back, depending on where I am). This is likely related to
| not using Google's location services, even though I have turned
| on all settings like using WiFi / bluetooth to improve the
| location accuracy. I tried every advice I found online, without
| luck. Somehow the issue is a bit worse on Graphene, as my
| position is lost every time I close the Maps app, but it may be
| related to the phone and not the OS.
|
| Pixel 8 works amazingly with Graphene's new network location
| feature. Position fixes are SO MUCH FASTER. It is truly a
| gamechanger. First it was Wi-Fi only, but they just released
| cellular location as well. They provide a proxy to Apple's
| location services.
| jech wrote:
| >>The only technical limitation I have encountered using
| these ROMs is related to GPS: my position is often lost
|
| > Graphene's new network location feature
|
| I believe it uses https://beacondb.net/, which is starting to
| have fairly decent coverage, at least in large parts of
| Europe. You can contribute to BeaconDB even if you have an
| ordinary Google phone by installing
| https://github.com/mjaakko/NeoStumbler.
|
| I use LineageOS myself (because Graphene no longer supports
| my Pixel 5), and unfortunately it doesn't do network location
| out of the box. You can get network location on LineageOS by
| installing MicroG, but it's currently somewhat flaky.
| RealStickman_ wrote:
| In newer Android versions, network location with microg
| requires an additional patch to work. Else you only get
| GPS.
|
| See note at the bottom here:
| https://github.com/microg/GmsCore/wiki/Installation
| mbananasynergy wrote:
| We use Apple's location service, not beaconDB. We want to
| eventually make it so that it all happens offline, without
| any online service being used for it.
| jech wrote:
| > We use Apple's location service, not beaconDB.
|
| I stand corrected. Do you have plans to switch to
| BeaconDB when the coverage in the USA improves?
| strcat wrote:
| We're building our own fully offline implementation. Our
| existing implementation is semi-offline and does the
| position estimation locally based on downloading data
| kept in an in-memory cache for a limited time. We're
| close to what's needed for offline support already in
| that sense. We need to finish scraping the data and
| putting together a system for distributing and using it.
| matheusmoreira wrote:
| It's a shame that Android as a whole is trending towards hardware
| remote attestation. It's pretty much guaranteed that app
| developers will eventually start writing their apps so that they
| refuse to run on anything that doesn't pass Google Play
| Integrity. Being unable to run WhatsApp or bank apps on
| GrapheneOS will render it useless as a smartphone operating
| system. It might not be happening right now but the threat of it
| looms eternal. My bank could flip a switch somewhere and suddenly
| my phone becomes useless for the purpose of accessing my bank
| account.
|
| The Google Pixel requirement also makes me sad. I understand that
| they have solid reasons why. The problem is Google is incapable
| of selling their phones worldwide. It's really embarrassing for
| Google and unfortunate for me.
| icar wrote:
| Hardware attestation and Google Play Integrity are two
| different things, and the former solves the monopolistic
| practices of the latter.
| matheusmoreira wrote:
| Not at all. They are one and the same. Both of those things
| will literally destroy the computer freedom we enjoy today.
|
| GrapheneOS can attest to the device's security. The question
| is whether the app developers will _trust_ such an
| attestation. Will they put money, time and effort into
| evaluating and trusting GrapheneOS? Of course not. They will
| just decide to trust nobody except Google and Apple.
|
| This is the future. We'll be discriminated against. Can't
| even log into an account from an "unauthorized device". Their
| servers will just refuse to talk to our phones if they can't
| cryptographically verify that we have not "tampered with"
| them. We'll be refused service straight up unless our
| computers are straight up owned by corporations.
|
| This so called "integrity checking" is meant to protect the
| corporations from us, not the other way around. It's so we
| can't do things like hack our way around their "policies".
| mbananasynergy wrote:
| Well, there are examples such as Yuh and Swissquote which
| are using Play Integrity API _and_ also using hardware
| attestation to specifically allow GrapheneOS. The latter is
| in the process of implementing what 's needed right now.
|
| We also expect Google's Play Integrity API to inevitably be
| ruled as anti-competitive, which it is.
| matheusmoreira wrote:
| That's immensely good news. It's good to know that
| there's still hope.
|
| > We also expect Google's Play Integrity API to
| inevitably be ruled as anti-competitive, which it is.
|
| I certainly hope so.
| sandreas wrote:
| Happy long term user, great project. Here is a list of Open
| Source Apps, I use to replace Google stuff:
| Aurora Store - Anonymized frontend for Playstore F-Droid -
| Open Source App Store Obtainium - App Store for other
| sources (e.g. github) Organic Maps - Open Source navigation
| (not as good as proprietary ones though) SherpaTTS - Text
| to speech for Organic Maps PDF Doc Scanner - Little
| Trickster, Open Source document scanner Binary Eye -
| Barcode reader K9 Mail / FairMail - Mail client
| LocalSend - Cross Platform File Transfer Syncthing Fork -
| Catfriend1 Syncthing fork to sync files VLC Media Player -
| media player KOReader - ebook reader Voice - Paul
| Woitaschek, local audiobook player AudioBookShelf - Remote
| audiobook player Immich - image backup Fossify File
| Manager - file manager Substreamer / DSub - Audio streamer
| for navidrome self hosted server OpenCamera - Open Source
| camera app
|
| I wish I had this list from the start... Hope it helps someone
| :-)
| pedro_caetano wrote:
| Worth mentioning that Fossify also has an amazing Contacts and
| Calendar app (using both right now on Android 15).
|
| https://www.fossify.org/apps/
|
| Fossify is a FOSS project with a handful of volunteers and they
| do take donations:
|
| https://www.fossify.org/donate/
| jraph wrote:
| > Organic Maps - Open Source navigation (not as good as
| proprietary ones though)
|
| Note that a community fork done by some core contributors was
| just spawned: CoMaps [1]
|
| > K9 Mail / FairMail - Mail client
|
| And now there's Thunderbird, which is branded version of K9
| Mail IIUC (I don't know if there's any reason to switch from K9
| Mail to Thunderbird for existing users)
|
| [1] https://f-droid.org/en/packages/app.comaps.fdroid/
| Liquix wrote:
| Does the fork solve the issue with inputting addresses?
| Organic Maps will happily route to the correct street, but
| falls over when entering a standard format address (i.e. XXX
| Streetname Ave)
| jraph wrote:
| I don't think the fork is very different right now, and I
| doubt inputting addresses works differently.
|
| You might want to try:
|
| - writing the city name at the beginning
|
| - putting the street number at the end
|
| Note that OSM might not have the street number. If it
| doesn't, searching for it will fail for sure.
|
| You should probably file an issue:
| https://codeberg.org/comaps/comaps/issues
| upcoming-sesame wrote:
| for someone who doesn't want to replace Google services, does
| it still make sense to move to Graphene?
| other8026 wrote:
| Absolutely. You can basically get almost the same experience
| as you would on a stock OS device, but with much better
| privacy. On the stock OS, Google apps get privileged access,
| so they can still access photos and your camera and all that,
| but what people don't realize is that their privileged access
| also includes things like usage data, hardware identifiers,
| etc. Using Google apps on GrapheneOS makes a lot of sense.
|
| The only problems you might run into would be some features
| might require privileged access, things like Now Playing.
| Makes sense because normal apps cannot have unrestricted
| access to the microphone like that. Google Wallet works, but
| you cannot make payments because the app refuses to work on
| alternate OSes.
|
| Besides that kind of stuff, though, I've used all sorts of
| Google apps without issues.
| fmajid wrote:
| According to Terence Eden, Curve Pay allows NFC payments,
| at least in the UK
| theandrewbailey wrote:
| Over the years, Big Tech has given me reasons to trust them
| less and less. So I encourage you to be a rebel: cut Google
| out and live outside the system.
| fmajid wrote:
| Aegis: TOTP 2FA code manager
|
| SuperCards: stores shop loyalty card barcodes
|
| KeePassDX: password manager
|
| ReadEra: eBook reader
|
| Magic Earth: another maps app
|
| Vivaldi: power-user's browser
|
| JuiceSSH: SSH client
|
| Termux: like running a Linux term
|
| AntennaPod: podcasts
| johnisgood wrote:
| I do not use Aegis anymore, I use KeePassDX instead. It works
| for TOTP just fine.
|
| JuiceSSH is still under development?
| timbit42 wrote:
| Some people don't like to keep passwords and TOTP in the
| same place.
| anthk wrote:
| >Magic Earth: another maps app
|
| >Vivaldi: power-user's browser
|
| Propietary. Get Fennec with FDroid with Ublock Origin and
| some addons.
| timbit42 wrote:
| CoMaps: another maps app
|
| StreetComplete: help update CoMaps and OpenStreetMap
|
| Catima: for loyalty cards
| wanderingmind wrote:
| I'm surprised no one mentioned NewPipe, the best YouTube App. A
| few other apps I use Feeder - RSS App Fedilab - For Mastodon
| timbit42 wrote:
| I prefer Tubular which is a NewPipe fork with not only an ad
| blocker, but also with SponsorBlock and ReturnYouTubeDislike.
| ulrikrasmussen wrote:
| NextCloud - sync photos, calendar, notes and contacts to your
| own server.
| labadal wrote:
| How do push notifications and similar things work on GraphenOS?
| Do they work reliably out of the box on most apps, or did you
| have to set up MicroG/whatever GrapheneOS's equivalent is?
| bogwog wrote:
| Everything works out of the box, and it doesn't use a third
| party layer like MicroG. The difference is that Google's
| apps/services are not given admin privileges like they
| usually are, so you can selectively enable or disable things.
|
| For example, installing an app on Google Play works like
| F-Droid. Once the download finishes, you have to open the
| Play store app to trigger a system dialog to accept the
| installation. On other Android devices, GPlay can install
| apps without your approval.
| Andromxda wrote:
| > How do push notifications and similar things work on
| GraphenOS?
|
| Some apps require Google's FCM for push notifications. You
| need to install Sandboxed Google Play services from the
| GrapheneOS App Store and grant them unrestricted battery
| access (so they can run in the background, which is required
| for maintaining a network connection to FCM and delivering
| notifications). https://grapheneos.org/faq#notifications
|
| Other apps like Signal use their own background connections,
| for example WebSockets, to deliver push notifications, but
| keeping a connection open for each app consumes more battery
| life than just having one background network connection.
| Also, not every app supports this.
|
| For Signal specifically, the GrapheneOS project recommends
| either using FCM via Sandboxed Google Play, or installing
| Molly (https://molly.im/), a fork of the Signal client for
| Android, which makes some changes to reduce battery
| consumption when using WebSocket-based notifications. It also
| allows you to use UnifiedPush (https://unifiedpush.org/) for
| notifications instead, but that requires an application
| called mollysocket (https://github.com/mollyim/mollysocket)
| running on a server.
| sandreas wrote:
| Awesome! Thanks for sharing this.
| strcat wrote:
| Push notifications work on GrapheneOS whether apps do it
| themselves, use UnifiedPush with the user's choice of
| provider or use FCM. UnifiedPush and FCM are a more efficient
| design where apps share a push connection. Unfortunately,
| many apps only support FCM and some support their own push as
| a fallback, but few support UnifiedPush. FCM works very well
| via sandboxed Google Play, which is an approach where Google
| apps can be installed as regular sandboxed apps with zero
| special access or privileges. Nothing FCM does actually
| requires special privileges and our compatibility layer makes
| it work without it.
|
| GrapheneOS does not include sandboxed Google Play but rather
| includes an open source compatibility layer providing support
| for installing Google Play as regular sandboxed apps. They
| can't do or access anything more than other apps including
| the Google Play code running inside apps using Google Play
| which is the reason for choosing this design. It simply uses
| the same app sandbox and permission model which are both
| greatly improved by GrapheneOS for supporting running the
| rest of Google Play not bundled with apps using it.
|
| Worth noting apps don't need Google Play services to use
| Google services and many Google libraries like Ads and
| Analytics work without it. FCM requires Google Play services
| but many of their libraries do. There are Lite variants of
| Ads and Analytics for keeping apps smaller which lose the
| ability work without Google Play services. The general reason
| for the design is they don't want to have huge apps and want
| to be able to update the clients for their services without
| app developers doing it and shipping an app update. FCM is
| one of the special cases requiring the central design for
| efficiency. UnifiedPush is an alternative with choice of
| implementation / provider.
| leumon wrote:
| Can also recommend: PassAndroid: to open
| apple/android wallet files (airplane/cinema tickets etc.)
| Find My Device (FMD) on F-Droid: replacement for the google
| version, works via sms commands or a self-hosted app
| AntennaPod: Podcast App Breezy Weather: with multiple
| weather sources, great ui
| user070223 wrote:
| A question for strcat / other Graphene developers:
|
| Can you clarify what can one expect from legacy extended support.
| Will old devices get any more updates? how long, how often, is it
| just security patches etc..
|
| Thanks for you hard work!
| Andromxda wrote:
| Not a dev, but legacy extended support means that there are no
| more feature updates, i.e., no new Android versions or QPRs,
| only AOSP security backports. Obviously there aren't any
| firmware patches either, as these devices are unsupported by
| the manufacturer, who is responsible for delivering any changes
| to the firmware.
|
| https://grapheneos.org/faq#device-
| support:~:text=The%20follo....
| nvdr wrote:
| Big thank you to the GrapheneOS team! I have been running it for
| a week now on my 9pro and the user / app sandboxing is great. If
| there's a way to donate with cryptocurrency or help contribute,
| let me know!
| kupfer wrote:
| Check https://grapheneos.org/donate
| BLKNSLVR wrote:
| The article mentions the lack of a swipe keyboard, which is an
| issue for me.
|
| There is an option though: Heliboard with a custom swipe
| configuration applied (which is apparently sourced from Google,
| I'm not sure how "grey" that is).
|
| It definitely works as a swipe keyboard, but it's just not as
| good as GBoard. I will persist, however. I hope that it's
| learning at least...
| pdesi wrote:
| Check out FUTO keyboard (it's only ok). Or install GBoard,
| download the language of interest, and then disable network
| access to it
| JayWS wrote:
| I'm using Ginger, which works well. Once I used it once, it
| downloaded the dictionaries, and I could revoke network access.
| senorqa wrote:
| My personal favorite feature of GrapheneOS is that we can toggle
| the network access permission. In the past, I'd have to root my
| phone just to be able to install a firewall to do the same. Big
| props to GrapheneOS!
| gtsop wrote:
| As a long time GOS user I just want to remind what a joy it is to
| see my very old phone outlive flagships due to the lack of
| bloatware. I upgrade phones just for a single reason: it has been
| physically hit so hard over the years that it stops being
| physically functional.
| lrvick wrote:
| GrapheneOS (like all modern AOSP based ROMS) can literally not
| function with just the open source code. It requires hundreds of
| binary blobs from the vendor partition of a stock Android ROM,
| many of which have root access and have not been audited by
| anyone, including Google, who often lacks source code for them.
|
| Beyond that, the GraheneOS team still controls a single signing
| keychain for all phones in the wild, which we have to assume is
| still controlled by Daniel Micay (strcat) as it has not rotated
| as far as I can tell since he mostly stepped away from public
| view.
|
| He is without question a brilliant security engineer, but we
| can't ignore his very public Terry-Davis-esqe history of mental
| illness. Making -anyone- a single point of failure for a ROM
| frequently recommended for journalists and dissidents is a bad
| plan, and especially not someone very prone to believing wild
| conspiracy theories.
|
| I can't recommend GrapheneOS for any high risk use cases until:
|
| 1. they are able to find a device they can run 100% open source
| code on with no binary blobs
|
| 2. The ROM can be full source bootstrapped to mitigate trusting
| trust attacks.
|
| 3. The ROM builds 100% deterministically and is reproduced and
| signed by multiple team members publicly
|
| 4. Threshold signing or a quorum managed enclave issues the final
| signature only if multiple team members give it signed approvals
| of a hash to sign.
|
| Until at least those points are covered, the centralized trust
| model of GrapheneOS is a liability and the central keyholder is
| at high risk of being targeted for manipulation or coercion.
|
| Honestly there is no good solution to these problems right now,
| and as a security and privacy researcher my best advice today to
| potentially targeted individuals is don't carry a phone at all,
| or if you must carry one, keep it in airplane mode whenever
| possible and do not do anything sensitive on it. Consider QubesOS
| or AirgapOS for such things.
|
| If you are fine with centralized control of a phone, and fine
| with binary blobs controlled by random corpos having God access
| to your device, but would prefer to eliminate as much proprietary
| corpotech bullshit as possible, then I would suggest considering
| CalyxOS which is at least run by a former LineageOS maintainer
| with a great reputation.
| tholdem wrote:
| So you're saying don't use a smartphone at all, which isn't
| possible, or use CalyxOS, which not only suffers from the same
| "problems" you criticize in GrapheneOS, but is also inferior in
| every way when it comes to security and privacy?
|
| This does not make sense at all.
| lrvick wrote:
| > don't use a smartphone at all, which isn't possible
|
| I run a b2b tech company in Silicon Valley and have not
| carried a smartphone in 5 years or had an LTE subscription in
| 6. I have a family and hang out with friends, mostly tech
| workers, at least once a week. I am online when I am at my
| desk or one of my family PCs, otherwise I am offline. It has
| been a massive productivity boost, attention span boost, and
| social improvement in every way.
|
| I don't miss hours of doom scrolling a day and missing out on
| being present with friends and family. Took a few weeks to
| rewire my dopamine engine so the FOMO went away.
|
| Phones -are- optional and if you think otherwise you might be
| an addict.
|
| > CalyxOS, which not only suffers from the same "problems"
| you criticize in GrapheneOS, but is also inferior in every
| way when it comes to security and privacy?
|
| It is better in one way: a reasonably stable person holds the
| keys to the kingdom. Personally I do not like having -any-
| central person controlling my devices, so I just opt out of
| Android entirely until that situation changes.
|
| I am a supply chain security researcher and founded a Linux
| distro where no single computer or maintainer is trusted, so
| trust decentralization, freedom, and control in software are
| very important to me.
| strcat wrote:
| > Phones -are- optional and if you think otherwise you
| might be an addict.
|
| Smartphones are small portable computers. You're using a
| similar computer to make posts on social media platforms
| including Hacker News.
|
| > It is better in one way: a reasonably stable person holds
| the keys to the kingdom.
|
| Repeatedly claiming that I'm insane, schizophrenic,
| delusional, etc. is not a reasonable criticism of
| GrapheneOS. I'm clearly none of those things. I've been
| targeted with attacks including harassment and tons of
| fabricated stories for years beginning with my former
| business partner and his associates. You thoroughly
| discredit yourself by going as far as baselessly claiming
| that I'm schizophrenic because you don't like the way I've
| tried to defend myself from these attacks.
|
| The lead developer of CalyxOS (cdesai) was a Copperhead
| employee directly involved in the 2018 takeover attempt on
| GrapheneOS. CalyxOS itself directly originates from the
| takeover attempt on GrapheneOS. The people involved
| demonstrated their lack of ethics through their
| participation in the attacks on GrapheneOS and partnerships
| with people involved in it. You've been attacking us for
| years alongside them. CalyxOS exists because of this
| takeover attempt. It's a non-hardened OS which was created
| by heavily using GrapheneOS source code and documentation
| without most of our privacy and security features.
| strcat wrote:
| > CalyxOS, which not only suffers from the same "problems"
| you criticize in GrapheneOS, but is also inferior in every
| way when it comes to security and privacy?
|
| CalyxOS lacks the current driver/firmware patches and isn't a
| hardened OS with similar privacy and security patches. There
| are plenty of worse options but people are better off using
| an iPhone.
|
| Hardware and firmware is closed source in general and the
| complexity of that dwarfs a few dozen closed source driver
| libraries used on top of open source kernel drivers. Pixels
| have those libraries built with debug symbols and they're not
| hard to review. It's not obfuscated code and you're given the
| function names, etc.
|
| Those few dozen mostly quite small libraries being open
| source instead of closed source with debug symbols would be
| nice and is something we want. With an OEM partnership, we
| can have access to the sources and build them with hardening
| even without those being open source yet. We can likely
| include debug symbols just as Google did for the most part on
| Snapdragon Pixels. Convincing a company like Qualcomm to open
| source those would be ideal, but it's far from being at the
| top of a rational list of privacy and security improvements
| which could be made.
|
| > This does not make sense at all.
|
| You can see he's once again making a baseless claim that I'm
| schizophrenic, delusional, etc. in his post here as he has
| done many times before. There's also the baseless claim that
| I believe wild conspiracy theories. It's not me making
| unsubstantiated claims about backdoors and proposing
| approaches to prevent it which disregard the hardware and
| firmware to focus on the OS having reproducible builds, which
| would not stop malicious changes hidden at a source code
| level. I don't think Hacker News should permit baselessly
| claiming someone is schizophrenic. It's not reasonable
| discourse, and neither is linking what's clearly harassment
| content from a Kiwi Farms as happens here regularly. I've
| never claimed GrapheneOS prevents hypothetical backdoors and
| certainly wouldn't claim reproducible builds (which we have)
| can somehow we used to prevent it for the OS.
|
| We can make more use of the reproducible builds but enforcing
| anything based on it requires early access and more resources
| to fix reproducibility issues early to avoid delaying
| security updates. It will not avoid trust in the OS
| developers and the projects it uses itself. It can only
| reduce trust in the build infrastructure and people involved.
| Open source does not prevent backdoors. The small amount of
| closed source library code for supporting a modern smartphone
| SoC, etc. is also quite insignificant compared to the overall
| hardware and firmware complexity. Reviewing those libraries
| is also quite doable. Open source is not a hard requirement
| to review something, particularly with debug builds for most
| of it and no obfuscation. When we find bugs in this code with
| MTE, we get nice tracebacks with the function names due to
| the debug symbols. It's hard for us to make our own fixes for
| it, but not impossible. We would prefer if they were open
| source, but it's FAR from the most pressing issue and is
| something SoC vendors could quickly solve if convinced to do
| so.
| gf000 wrote:
| > my best advice today to potentially targeted individuals is
| don't carry a phone at alil
|
| Lol. I hope you like working with geese, but be careful, they
| can't be trusted!
|
| Also, you are pretty much factually wrong on a bunch of items
| on your list. GrapheneOS still has room for improvement of
| course, but they are very ahead of anything else on every
| aspect. And where you are not factually wrong, you are just
| unrealistic. There is no 100% open-source hardware, period.
| This is complete "what color you want your dragon to be"
| category.
| lrvick wrote:
| > Lol. I hope you like working with geese, but be careful,
| they can't be trusted!
|
| Geese? That is offensive. I raise chickens.
|
| I also run a successful tech company, and have a full EE lab,
| several full server racks, and more tech in my home than
| anyone I have ever met.
|
| Phones are completely optional in modern society. We have
| just convinced ourselves we need them because doom scrolling
| and constant notifications are addictive.
|
| Print your boarding pass, ask for paper menus, pay with cash,
| and arrange times and places to meet people and then actually
| be there on time. The rare times you really need to do online
| work on the go, bring an actual computer with a real
| keyboard. Free wifi is everywhere.
|
| Works just fine, and as a bonus your time away from home
| becomes mostly invisible to marketing firms.
| lrvick wrote:
| > Also, you are pretty much factually wrong on a bunch of
| items on your list.
|
| If you are going to call me misinformed, please take the time
| to prove it so I can stop sharing information I otherwise
| have no reason to believe is incorrect.
|
| > There is no 100% open-source hardware, period.
|
| Multiple fully or mostly open hardware computers exist. They
| just cannot run android.
|
| MNT Reform, Precursor, and Talos II are the top three that
| come to mind.
|
| Those are lightyears ahead in openess and auditability
| compared to anything Google produces.
| strcat wrote:
| > Multiple fully or mostly open hardware computers exist.
| They just cannot run android.
|
| No, not really, and there's no reason those can't run AOSP.
|
| > MNT Reform
|
| It has a typical closed source ARM SoC and other
| components. The chassis and board being open doesn't make
| all the components open. CPU, GPU, MMU, USB, etc. are
| provided by the SoC and are closed source as usual. It has
| closed source hardware and firmware for the SoC along with
| other closed source hardware and firmware. Not having to
| load firmware from the OS does not mean it's open hardware
| and firmware. It's barely more open than other computers
| for the most complex parts of it.
|
| How is something fully open hardware if the vast majority
| of the complexity is in closed source components providing
| most of the functionality? The SoC is just the most complex
| of these by far.
|
| Why couldn't AOSP be run on a regular ARM SoC used in
| devices which run AOSP? AOSP works fine on top of the
| mainline Linux kernel and drivers.
|
| > Talos II
|
| A mostly open source motherboard where you drop in a closed
| source CPU is not really an open source platform. It's not
| fully open source itself and the CPUs used with it are not
| open source. IBM took steps towards open sourcing PowerPC
| as an ISA and relatively primitive open source cores
| OpenPOWER core designs exist. However, what's actually
| available and used with it are closed source CPUs. In
| theory, there can be open design CPUs for use with it. As a
| motherboard, it's pretty close to fully open hardware. As a
| functioning computer, it's mostly not because a motherboard
| is not a whole computer and is far less complex than the
| CPU even with a more traditional desktop design with less
| functionality moved into an SoC.
|
| > Precursor
|
| It has a closed source FPGA as the primary processor and
| other closed source components. It's far closer to being
| open source, but it isn't fully open hardware. This is the
| only one you listed which is anywhere close to mostly open
| source. It is very far from a powerful modern smartphone
| device though.
|
| > Those are lightyears ahead in openess and auditability
| compared to anything Google produces.
|
| The primary SoC in each is closed source. Precursor
| programs their CPU on top of that closed source FPGA so the
| CPU is open source in that sense and much closer to being
| mostly open. It's not the only closed source part of it.
|
| The other 2 examples have a closed source SoC. One uses a
| regular closed source ARM SoC incorporating far more than a
| CPU and GPU into the closed source chip. The other depends
| on a more traditional desktop style closed source CPU from
| IBM outsourcing more to the motherboard.
| strcat wrote:
| > GrapheneOS (like all modern AOSP based ROMS) can literally
| not function with just the open source code.
|
| It does not inherently require any closed source code or
| hardware. Real world hardware is closed source and requires
| tons of closed source firmware. Not updating the firmware
| doesn't make it not exist. It would mean it was outdated and
| missing important security patches. Lots of firmware is updated
| by GrapheneOS. All of the kernel drivers are open source.
| Replacing closed source libraries such as the Mali GPU library
| to use hardware components is something relevant to GrapheneOS
| and any other OS targeting the same hardware. It's best for the
| SoC vendor and OEM to be involved in that rather than spending
| many years gradually assembling it downstream where by the time
| things work, the device is end-of-life. The hardware/firmware
| would still be just as closed source after doing all of that.
|
| Ignoring all of our hardware requirements would not result in
| there being a single device we could support without nearly
| entirely closed source hardware and firmware.
|
| > He is without question a brilliant security engineer, but we
| can't ignore his very public Terry-Davis-esqe history of mental
| illness.
|
| There's no basis for these repeated claims that I'm insane,
| delusional or schizophrenic. Defending myself from frequent
| attacks by many people doing exactly what you're doing doesn't
| make me crazy or an aggressor towards the people doing it.
| You're demonstrating the ongoing libel, harassment and bullying
| directed towards me. There's no point in claiming it's a
| delusional when you've repeatedly engaged in it. Engaging in
| this in plain sight and pretending it's imagined is ridiculous.
|
| > Making -anyone- a single point of failure for a ROM
| frequently recommended for journalists and dissidents is a bad
| plan, and especially not someone very prone to believing wild
| conspiracy theories.
|
| I do not believe any wild conspiracy theories. It's a baseless
| and dishonest claim. I'm not the one pushing unsubstantiated
| claims about backdoors and a clearly non-working approach to
| preventing them. Not having the Mali GPU driver library and
| similar closed source userspace libraries would not change that
| the hardware and firmware is closed source and also far more
| complex.
|
| > 1. they are able to find a device they can run 100% open
| source code on with no binary blobs
|
| There's no laptop, desktop, tablet or smartphone which is not
| filled with closed source hardware and firmware. Having some
| closed source libraries for a Mali GPU driver, etc. which are
| not obfuscated, generally have debug symbols and can be
| thoroughly inspected/audited if you want to do that is
| insignificant compared to the vast complexity of the closed
| source hardware/firmware.
|
| A device avoiding having a few dozen closed source vendor
| libraries would be nice but it's still going to be closed
| source hardware and firmware. It would allow us to cover it
| with our added compiler-based hardening and much more easily
| fix or work around bugs we find with our hardening features
| such as memory tagging. It's something we want and can
| eventually be a requirement, but not yet. Tensor Pixels greatly
| reduced how much of this there is compared to Snapdragon Pixels
| but didn't keep going in that direction especially with Android
| 16 throwing away a lot of progress.
|
| > 2. The ROM can be full source bootstrapped to mitigate
| trusting trust attacks.
|
| It's an operating system, not a ROM. Having a standard
| toolchain build is for reproducible builds and all parts of the
| toolchain itself can be built from the source tree.
|
| > 3. The ROM builds 100% deterministically and is reproduced
| and signed by multiple team members publicly > 4. Threshold
| signing or a quorum managed enclave issues the final signature
| only if multiple team members give it signed approvals of a
| hash to sign.
|
| GrapheneOS has reproducible builds. There's a community member
| regularly testing it and publicly reporting any issues which
| come up in our public development room. A recent example is
| that Android 16 split up the kernels into 3 groups which we
| found hard to explain and make sensible for people building it,
| which they ran into. There are sometimes regressions in AOSP
| which cause minor reproducibility issues. This community member
| looks into those to determine what's wrong. There are not
| currently any known build reproducibility issues which occur
| regularly. There's no strong commitment from the Linux kernel,
| AOSP, Chromium, etc. to keeping builds fully reproducible and
| blocking security updates based on this wouldn't make much
| sense, particularly with a strict interpretation of it rather
| than investigating the actual differences and determining if
| it's even an actual code difference.
| strcat wrote:
| AOSP having a regression causing a timestamp to be added
| somewhere isn't a reasonable justification for blocking
| security updates. No system without the ability to
| investigate the cause and determine if it's okay would be
| reasonable. We would need to finally have early access to new
| Android releases to test this in advance and have fixes ready
| to go prior to the stable releases. We do not currently have
| this early access but will likely obtain it from the OEM
| we're working with soon. We would still need additional
| resources to have ongoing testing for this and fixes for any
| relevant regression that finds. Porting to new releases prior
| to them being stable and specifically testing this would be
| needed.
|
| We can't risk introducing a very a fragile system which could
| result in substantially delayed updates. Our plan for
| reproducible builds is to provide an opt-in feature where
| people can select which additional parties they trust to
| reproduce builds without falling behind significantly. This
| would solely be for the OS update client and App Store
| updates. It would not be for other uses of signing such as
| verified boot which are not designed to handle this. It would
| a system to verify that signed hashes from other parties have
| been published for an update. The meaning of that can be
| defined by these parties reproducing builds, such as how
| they'll investigate a mismatch and the way they'll determine
| if it's an issue.
|
| In practice, this would be based on tools we publish for
| others to use for building and comparing. Similar to the
| rest, people are trusting the source code and the people who
| wrote it. Source code is not inherently trustworthy and
| provides no magical privacy or security properties. Reading
| the sources does not mean you will find all the
| vulnerabilities, particularly subtle ones or hidden ones. It
| clearly doesn't provide that even for extensive
| audits/review. Why does the Linux kernel have so many serious
| vulnerabilities being found on a regular basis including ones
| which are years and even decades old if this approach works?
|
| If you truly believe that I'm insane, why do you think it's
| reasonable to use code that I wrote or supervise writing as
| long as the build matches the sources?
|
| > Until at least those points are covered, the centralized
| trust model of GrapheneOS is a liability and the central
| keyholder is at high risk of being targeted for manipulation
| or coercion.
|
| You use many open source projects with far fewer review.
| GrapheneOS itself is based on AOSP which uses a huge number
| of open source projects from a huge number of people. The
| Linux kernel alone has a massive number of contributors and
| most code has little review. It's filled with vulnerabilities
| which are found regularly. https://lore.kernel.org/linux-cve-
| announce/ provides a very flawed overview of this based on
| what is backported. These devices are compromised in the real
| world by exploiting vulnerabilities like many of these.
| Reproducible builds and checking that others have reproduced
| builds is not actually going to stop a software supply chain
| attack in practice, which would work within the constraints
| and use source code. If one of the projects used by AOSP has
| a backdoor added to the sources, how do reproducible builds
| help? We'd just be building the code and the backdoor would
| be reproducible.
|
| > Honestly there is no good solution to these problems right
| now, and as a security and privacy researcher my best advice
| today to potentially targeted individuals is don't carry a
| phone at all, or if you must carry one, keep it in airplane
| mode whenever possible and do not do anything sensitive on
| it. Consider QubesOS or AirgapOS for such things.
|
| Computers have closed source hardware and firmware in
| general. A few small closed source libraries are not
| significant compared to the overall complexity of the closed
| source hardware and firmware. Those libraries are easy enough
| to review. Pixels have debug symbols enabled for them.
| Reviewing firmware is a larger scale and much harder
| undertaking. How do you review the hardware itself? Even if
| the hardware design was fully open source for the SoC
| including the CPUs, GPUs, MMU and everything else along with
| the radios and other peripherals, how would you verify that
| what a chip manufacturer like TSMC produced matches the
| hardware design?
|
| > If you are fine with centralized control of a phone, and
| fine with binary blobs controlled by random corpos having God
| access to your device, but would prefer to eliminate as much
| proprietary corpotech bullshit as possible, then I would
| suggest considering CalyxOS which is at least run by a former
| LineageOS maintainer with a great reputation.
|
| The lead developer of CalyxOS is a former Copperhead employee
| directly involved in the takeover attempt on GrapheneOS in
| 2018. You're talking about someone who was a direct
| participant in doing shady things for Copperhead's CEO going
| against the ethics of the open source project the company was
| meant to be supporting including participating in the
| takeover attempt and then leaving following it.
|
| He was involved in subsequent attacks on GrapheneOS including
| similar harassment to what you participate in yourself.
| CalyxOS does not have current Android privacy/security
| patches. It's still missing the June 2025 patches for Pixel
| drivers/firmware. It isn't a hardened OS like GrapheneOS with
| similar privacy or security improvements, and it doesn't
| maintain all of the standard security model due to the
| privileged code they add to the OS.
| torium wrote:
| > ""will never again be closely tied to any particular sponsor or
| company"". Work on GrapheneOS is supported by a Canada-based
| foundation created in 2023; there appears to be almost no public
| information available regarding this organization, though.
| torium wrote:
| Does anybody else here see as problematic that this OS supports
| mostly Pixel, a Google phone?
|
| Over and again people on HN make the following argument: "Google
| is a company that makes most of its revenue from ads and
| surveillance. Therefore, you should always assume that Google is
| spying on you". But somehow when it comes to Pixel people give it
| a pass?
|
| Prediction: If Pixel isn't already hardwired to phone home and
| report on your activities, it will slowly become so over time, as
| Google realizes its interest. You know, as it happened with
| Android, Chrome, and everything else that Google touches.
| _vere wrote:
| This is just conspiratorial fearmongering based on vibes. If
| pixels somehow phoned home on a hardware level, do you think we
| wouldn't be able to tell? Do you think we wouldn't see it in
| our network logs? GrapheneOS supports pixels because they are
| currently the only devices that fulfill their list of
| requirements, like an actually usable secure element, hardware
| memory tagging, etc. They have said and continue to reiterate
| that they would support other devices that fulfill their
| requirements and seem to be currently looking into working with
| OEMs to move away from pixels in the long term. Just saying
| "you claim to degoogle phones yet the phone you use is a GOOGLE
| pixel, suspicious" is baseless nonsense.
| bitpush wrote:
| +1. It is kinda sad that folks seem to have lost critical
| thinking or even just some plain perspective on things.
|
| They hear their favorite influencer spout something, and they
| parrot it everywhere. Google bad, hurr durr.
| strcat wrote:
| See the response at
| https://news.ycombinator.com/item?id=44686895.
| const_cast wrote:
| > If pixels somehow phoned home on a hardware level, do you
| think we wouldn't be able to tell?
|
| Yes.
|
| > Do you think we wouldn't see it in our network logs?
|
| If it's done on the baseband processor, no.
|
| I believe grapheneos has some sort of band band processor
| isolation, but I'm not sure exactly how it works.
|
| But yes - your phone has a separate SOC, with its own
| operating system you can't access, which communicates with
| cellular networks. We don't know what, exactly, it's used for
| or what, exactly, is being transmitted. We do know it's used
| for location tracking because this is utilized by law
| enforcement somewhat regularly. But cellular triangulation
| isn't too accurate, not like precise location services.
| strcat wrote:
| > If it's done on the baseband processor, no.
|
| The baseband firmware is not obfuscated and people can/do
| analyze the cellular protocol and how it functions. Which
| devices receive more privacy/security research than Pixels
| do? Which devices avoid trusting multiple companies making
| the hardware? Nothing. Similar things could be said about
| any hardware we supported, but all the other available
| options supporting using another OS would be far less
| secure and unable to provide what GrapheneOS offers. Core
| features would be missing elsewhere.
|
| We're working with an OEM to have their future devices meet
| our requirements and provide official GrapheneOS support,
| but how would that change anything? It's another big tech
| company making devices. What do you think is special about
| Google and what reason is there to think they would be
| putting a backdoor but other companies wouldn't?
|
| > I believe grapheneos has some sort of band band processor
| isolation, but I'm not sure exactly how it works.
|
| Isolation for the radios is a standard security practice on
| most modern smartphones. GrapheneOS improves the security
| of the isolation through hardening the drivers and services
| against exploitation after exploiting the radio firmware.
|
| > But yes - your phone has a separate SOC, with its own
| operating system you can't access, which communicates with
| cellular networks. We don't know what, exactly, it's used
| for or what, exactly, is being transmitted. We do know it's
| used for location tracking because this is utilized by law
| enforcement somewhat regularly. But cellular triangulation
| isn't too accurate, not like precise location services.
|
| The CPU, GPU and many other components in laptops,
| desktops, tablets and smartphones are closed source
| hardware with closed source firmware. Wi-Fi and Bluetooth
| are implemented with a separate processor and operating
| system. There's nothing about that specific to cellular and
| it's a misconception that it's different from other
| components in this regard. Modern computers have a bunch of
| processors and little operating systems across a bunch of
| components. Many people have the wrong idea that it's
| somehow specific to a few things like AMD PSP, Intel ME or
| cellular radios when in reality that's just how things are
| at a hardware level across many components. Cellular radios
| are normally an isolated component.
|
| Cellular can be used to detect location, but so can Wi-Fi
| and Bluetooth. Wi-Fi is the main way network-based location
| works. Most Wi-Fi networks are from ISP routers and some
| even have an official way for other subscribers to use it.
|
| Cellular doesn't need to be left enabled all the time.
| There's airplane mode. Using cellular is an option.
| GrapheneOS runs on portable computers with support for Wi-
| Fi, USB ethernet, etc. too not onlyg cellular.
| strcat wrote:
| See the response at
| https://news.ycombinator.com/item?id=44686895.
| rlue wrote:
| Your prediction is about a hardware product, and your examples
| are both software products (one is a browser and another is a
| mobile OS, both of which are platforms for running other
| software, and thus extremely well-suited to the task of
| reporting user data back to Google).
|
| I'm not an expert, but baking telemetry into the hardware (or
| at least the kind of telemetry that I assume Google is
| interested in) seems like skipping a few levels of abstraction,
| and thus more trouble than it's worth.
| other8026 wrote:
| > baking telemetry into the hardware (or at least the kind of
| telemetry that I assume Google is interested in) seems like
| skipping a few levels of abstraction, and thus more trouble
| than it's worth.
|
| This isn't really a practical way of doing it. Google Play
| and Google Play Services having privileged access is more
| than sufficient.
| gf000 wrote:
| Which they don't have under Graphene OS - they are the same
| as any other service you could write.
| other8026 wrote:
| Yes, thanks for pointing that out. I meant they get all
| that on the stock OS, but didn't make that clear.
| gf000 wrote:
| So what computer you use which is 100% open-source?
| zevon wrote:
| I think it's perfectly valid to consider this as problematic
| (the GrapheneOS team certainly seems to think this is not
| ideal, for example). However - somewhat counter-intuitively -
| it's also valid to consider Pixels as among the most secure and
| most appropriate Android phones for something like GrapheneOS.
|
| They write about their reasoning and criteria for device
| support here, for example: https://grapheneos.org/faq#future-
| device.
| strcat wrote:
| See https://news.ycombinator.com/item?id=44686811.
| dang wrote:
| Please don't copy-paste comments
| (https://news.ycombinator.com/item?id=44686811).
|
| Linking is fine, as you did here:
| https://news.ycombinator.com/item?id=44686876.
| strcat wrote:
| It had some changes to what was written due to a different
| context, but I've changed it to a link.
| dang wrote:
| Yeah, I appreciate that that happens sometimes. Probably
| the best thing is to link to the original comment and
| then add the diff in the new context.
| maelito wrote:
| I want Graphene OS on a non-Google compact smartphone.
|
| Not "pixel compact", but the size of an iPhone mini.
| maelito wrote:
| My main complain by far to LineageOS is the necessity to wipe
| everything for major releases on my S10. That's not possible
| every year.
|
| What about Graphene ? Can I get 5 years of updates without
| needing to wipe the phone ?
| tholdem wrote:
| You don't need to wipe the phone when updating GrapheneOS. It's
| as painless as on stock Pixel OS. OTAs downloaded and installed
| on the background, just reboot the phone after.
| timschumi wrote:
| > My main complain by far to LineageOS is the necessity to wipe
| everything for major releases on my S10. That's not possible
| every year.
|
| Are you sure that you are not just misinterpreting the upgrade
| instructions?
|
| For the S10 a mandatory wipe-on-upgrade has last been the case
| when upgrading from versions _older than LineageOS 21.0_.
|
| During the time where LineageOS 20 was the current version
| there was no requirement to wipe listed at all, so presumably
| it didn't exist then.
| maelito wrote:
| > For the S10 a mandatory wipe-on-upgrade has last been the
| case when upgrading from versions _older than LineageOS
| 21.0_.
|
| Ah, that might be it. My current version is 21.
|
| > If your device is running LineageOS version older than
| 21.0, wipe your data partition (this is usually named "Wipe",
| "Format", or "Factory reset") .
|
| https://wiki.lineageos.org/devices/beyond0lte/upgrade/
|
| Yes ! Thank you, I can upgrade to 22 without wiping.
| Andromxda wrote:
| Yes, GrapheneOS has always offered OTA updates via the _System
| Updater_ app. https://grapheneos.org/usage#updates It's set up
| to download and install updates automatically by default.
| Alternatively, you can install a signed update package via _adb
| sideload_. https://grapheneos.org/usage#updates-sideloading
|
| Both the update client and the backend are open source, just
| like the rest of the system:
| https://github.com/GrapheneOS/platform_packages_apps_Updater
| https://github.com/GrapheneOS/releases.grapheneos.org
| lollobomb wrote:
| I am a long time GrapheneOS user, amazing project. One thing that
| is not clear to me is the support for NFC payments. Las time I
| checked, NFC payments on Graohene didn't work at all, but I am
| reading on this thread that some users _do_ manage to pay via
| NFC? Did Iget this right? Mind explaining how?
|
| I do not use banking apps (I only use banks that allow me to log
| in via browser using a 2FA which is _not_ a proprietary app, like
| a FIDO key or other physical dongle), but do I get it right that
| Revolut would allow me to pay via NFC in this case? Is this
| something geo-dependent?
| prophesi wrote:
| The issue isn't with NFC. It's passing the Play Integrity check
| that app developers optionally can use to prevent devices that
| don't pass the check from running their app, or remove parts of
| its functionality. IIRC I don't think any custom ROM's can pass
| the check. So you might be able to pay via NFC with a banking
| app if they don't implement the Play Integrity API. For
| Graphene's thoughts on the matter (2024):
|
| https://grapheneos.org/articles/attestation-compatibility-gu...
| lollobomb wrote:
| Yes, I know the issue, but my question was more: is Revolut
| one of such banking apps?
| acheong08 wrote:
| Yes https://discuss.privacyguides.net/t/revolut-is-
| blocking-new-...
| lollobomb wrote:
| OK, and then these HN users who report being able to pay
| via NFC with Revolut on Graphene OS are lying? Sorry, I
| am confused :|
| mbananasynergy wrote:
| Revolut currently works fine on GrapheneOS. If they
| decide to adopt Play integrity, it won't work unless they
| whitelist GrapheneOS, which banks have started doing.
| kytazo wrote:
| Impressive! Glad to be able to use Revolut again.
| Wondering, is this a change or their end or some
| workaround implemented by Graphene?
| mbananasynergy wrote:
| GrapheneOS community manager here: They weren't using
| Play integrity and we were able to work around what they
| were doing, so Revolut should work again. They can decide
| to use Play Integrity in the future, though.
| WhyNotHugo wrote:
| AFAIU, there's two forms of NFC payment:
|
| - Adding your card to Google Wallet. - Using a banking app
| which actually implements payments via NFC.
|
| Many banks used to implement the latter, but dropped it in
| favour of "just use Google Wallet". In the Netherlands, it
| seems to be all of them. This varies a lot per region.
|
| I believe that the "just use Google Wallet" banks are the ones
| that don't work.
|
| Also (as others have mentioned): many banks perform integrity
| checks, to ensure that you're using a software chain signed by
| Google.
| strcat wrote:
| NFC payments work on GrapheneOS. Curve Pay works with
| GrapheneOS and is available in the UK And European Economic
| Area (EEA). PayPal launched tap-to-pay which works with
| GrapheneOS but has very limited regional availability. Many
| European banks provide working tap-to-pay with GrapheneOS.
|
| The issue is apps banning using a device not licensing Google
| Mobile Services or a non-stock OS via the Play Integrity API.
| Google Pay does this and a lot of banks outsource tap-to-pay to
| Google Pay instead of providing their own like many European
| banks. GrapheneOS users in Europe have multiple options. Users
| in the US often use a smartwatch for this purpose which
| includes the option of Garmin Pay rather than only Apple Pay
| and Google Pay.
|
| The choices depend on the region. It would be nice if the Play
| Integrity API was forced to permit GrapheneOS via hardware
| attestation verification by regulators. We're pushing for it in
| Europe.
| ovalanche wrote:
| True privacy is such a rare commodity these days. It's a breath
| of fresh forest air to enter an OS unwatched, allowing your mind
| to be free.
|
| Not to get too deep, but contemporary philosophy posits that our
| phones have become extensions of our brains (not only
| theoretically, but literally! See e.g. Andy Clark and David
| Chalmers, "The Extended Mind," 1998). Our devices have access to
| profound parts of our lives-- our habits, friends, desires,
| notes, thoughts... With something this fundamental, it's vital to
| have privacy.
|
| Thank you, Graphene team, for all the hard work you do.
| preisschild wrote:
| I love GrapheneOS. The only "issue" I had is that you are
| actually responsible for your own device, including taking
| backups.
|
| Unfortunately my home server, which I was using for backups, was
| flooded and before I replaced it my phone died and I lost a lot
| of data...
| fmajid wrote:
| I am (very slowly) migrating from iOS to GrapheneOS, for the same
| reasons as OP (privacy, Apple's increasingly user-hostile and
| developer-exploitative policies).
|
| Apart from migrations concerns, which are not GrapheneOS' fault,
| the main shortcoming I see is the lack of proper backup/restore,
| e.g. when switching phones. There is Seedvault, but I've found it
| unreliable.
| sjw987 wrote:
| Perhaps a newbie question, but since there's a lot of Graphene
| users here I thought it'd be best to get a human answer.
|
| I have an old Pixel 5 which I stopped using because Google
| dropped Google Pay (tap to pay) on it. I moved to a new device
| (Pixel 9) for daily usage but still have the 5 laying around (due
| to low resale value).
|
| At the time I moved, Pixel 5 was about 1.5 years (November 2023)
| beyond Android security updates. I still love the form factor
| (more than the bigger 9 I use now) and it has much more life left
| in it. I'd quite like to use this as a backup device for basic
| utility (camera, phone, SMS, basic read-only web use) and to take
| with me for runs and travelling.
|
| Would installing GrapheneOS on this device likely make it more
| secure? Do Graphene releases work the same on all devices, or is
| it sort of device-by-device basis?
| backscratches wrote:
| Yes it will make it more secure (and faster!), but it is
| already receiving only bare EOL updates, but will definitely
| give it some life extension. See:
| https://grapheneos.org/faq#supported-devices
| fmajid wrote:
| You won't get the full set of security measures (those
| require newer Google Tensor chipsets with ARM Memory Tagging
| Extensions, so Pixel 8 and later), but it's still going to be
| far more secure than any Android or even iPhone.
|
| Regarding NFC payments, the apps themselves refuse to run on
| non-vanilla OSes due to spurious security concerns and
| Google's maneuvers behind the scenes, but there are reports
| that Curve Pay works, at least in the UK.
| sjw987 wrote:
| That shouldn't be much of an issue. I didn't plan on NFC
| payments going forward. If I use the web minimally and
| toggle the internet off when not in use, that should be
| pretty secure, right?
| fmajid wrote:
| Yes, Vanadium (or any browser based on the system
| WebView) is going ot be up to date and as secure as it
| gets on a mobile OS.
|
| I only mentioned NFC because you mentioned Google Pay.
| sjw987 wrote:
| That's interesting. Thanks for the information.
|
| I'll give it an install tonight. I'm curious to play around
| with it anyway and if I make minimal use of it, it should be
| pretty secure by it's use case.
| backscratches wrote:
| Yes definitely more secure than stock, it is actually
| staggering to compare some of the features like ability to
| give apps access to only a selected set of contacts/files
| which as far as i know is still not on base android.
| whatsapp for example gets ALL of your address book or
| nothing (limiting usability) on other OS but on Graphene i
| can give it just 10 whatsapp-only contacts. I dont know how
| long the 5 will keep getting updates but for all I know it
| will be some years. the installation process is
| surprisingly the easiest of any mobile os I have ever
| encountered, you will be impressed!
| strcat wrote:
| Pixel 5 should only be used to preview what GrapheneOS provided
| prior to October 2024 when Android 15 was released and we
| migrated to it. It's an end-of-life device and therefore lacks
| driver and firmware updates. We were able to provide some of
| those updates past the end-of-life, but not most, and we
| recommend against using it. We show a notification about it
| being an insecure device at boot. We continued providing all of
| our updates and the Android updates for it until the release of
| Android 15, at which point we shifted to supporting it via a
| legacy extended support branch based on Android 14 QPR3 with
| backported AOSP patches and minor fixes of our own. Our support
| for the Pixel 5 has been winding down further since it's
| increasingly insecure and we don't want people to use it based
| on us still providing updates. A Pixel 5 works as a way to try
| out outdated GrapheneOS but that's about it.
|
| Using GrapheneOS on it would be more secure than the stock OS
| but it's going to be quite insecure regardless of the OS so
| we'd recommend just not using it. The intention of our extended
| support prior to Android 15 and then legacy ex trended support
| following Android 15 was harm reduction for people unable to
| afford a new device yet. That's essentially over now. We just
| didn't remove it from the site yet to avoid complaints. It
| informs people that it's an insecure device at boot so it's
| better than people getting misled into believing the alternate
| OS they've put on it keeps them safe when it doesn't.
| Funes- wrote:
| If I need to buy a phone made by Google to get away from Google,
| I'm just not doing it. /e/ doesn't support my current smartphone,
| either, and postmarketOS is not functional. At this rate, I think
| we're better off going back to dumbphones.
| CommenterPerson wrote:
| Thank you. I have the same worry. I'm not a developer, how
| could one tell there isn't some built in backdoor in the
| hardware? There was another HN posting on Graphene and asked
| the same question there with no answer.
| strcat wrote:
| The same thing could be said about any hardware. Pixels
| receive by far the most privacy and security research of any
| devices. They're by far the most secure Android devices and
| the only ones providing competitive security with iPhones.
| They're the only devices with even a reasonable level of
| security combined with proper alternate OS support. Our
| hardware requirements are listed at
| https://grapheneos.org/faq#future-devices. These are very
| reasonable requirements for industry standard security
| features, standard updates and the ability for GrapheneOS to
| use those standard security features. There are other devices
| with all the major features listed there but not the ability
| for GrapheneOS to use all of them. Updates are a major issue
| for all non-Pixel Android devices including the ones
| advertising lengthy support.
|
| GrapheneOS is working with a major Android OEM towards their
| future devices providing the expected hardware-based security
| features and updates, unlike their current devices. The
| purpose of GrapheneOS is not specifically avoiding Google but
| if you want hardware from another large tech company to use
| with GrapheneOS, you'll have that option. The initial goal
| for these devices is providing a similar level of security
| and long term support to what we already have with Pixels. In
| the longer term, we want to have add hardware-based security
| features unavailable on Pixels or iPhones along with
| hardening below the OS layer.
|
| For now, Pixels are the only viable option for us to use.
| We're actively working on changing that but we're not going
| to simply greatly lower our standards and support devices
| where we can't adequately protect users. There's no evidence
| of any backdoor and it's contradicted by how exploits are
| developed and used. There is plenty of evidence that other
| devices lack comparable security.
|
| https://discuss.grapheneos.org/d/14344-cellebrite-premium-
| ju... shows an example where only the Pixel 6 and later /
| iPhone 12 and later have brute force protection which holds
| up against the most sophisticated company developing forensic
| data extraction tools. We have access to more recent
| documentation showing the same thing.
|
| Why do governments buy exploit tools from NSO, Cellebrite,
| etc. and develop their own if they supposedly have backdoors
| in devices? Why would using a device from Samsung or Sony
| protect against it if they did?
| NotPractical wrote:
| Even if you aren't concerned about the possibility of
| "backdoored hardware" (and I am not, for one), I'm still
| sympathetic to the argument that giving money to Google is
| morally wrong because it provides financial support for their
| data-harvesting business model (though since you use
| GrapheneOS, they'll only be able to use it to harvest other
| users' data, of course, not yours). Buying a used Pixel doesn't
| support Google financially, so perhaps that's more ethical.
| strcat wrote:
| See the response at
| https://news.ycombinator.com/item?id=44686811.
| tclover wrote:
| What if all this hype about GrapheneOS was actually deliberately
| invented by the CIA so that everyone who has something to hide
| would install a beacon with a backdoor on themselves? _adjusts
| tinfoil hat_
| AstroBen wrote:
| I'm secretly hoping my iPhone will spontaneously explode so I can
| justify buying a pixel for this
| eleitl wrote:
| I've been rocking it on mobile for a while, and went for a tablet
| (LineageOS there previously) this month.
|
| The only real option for privacy and security which isn't swiss
| cheese.
| flntzr wrote:
| I'd like to switch phones soonish and was looking at the
| fairphone 6 with /e/OS but feel deterred by its mid range specs
| which would probably limit its longevity. I would like to get
| away from google.
|
| Is waiting for the new pixel and then putting grapheneOS on it a
| good way forward? Seems weird to pick a google device to get away
| from that company.
|
| Has anyone else done the same?
|
| Alternatively, there is the iPhone but I do like fdroid and the
| more open nature of android.
| bernoufakis wrote:
| > I'd like to switch phones soonish and was looking at the
| fairphone 6 with /e/OS but feel deterred by its mid range specs
| which would probably limit its longevity. I would like to get
| away from google.
|
| > Is waiting for the new pixel and then putting grapheneOS on
| it a good way forward? Seems weird to pick a google device to
| get away from that company.
|
| > Has anyone else done the same?
|
| I did end up going for a Pixel + GOS. Although it is
| conterintuitive to use a Google device to get away from Google,
| according to GOS developers themselves, the Pixel series were
| the only devices that met their strict requirements for
| security.
|
| From personal experience, been using it for almost 3 years now,
| and it gives you 95% of the benefits of Android while giving
| you back control over your phone, and being generally more
| secure.
|
| Just stay out of the radar of the leadership, they can be a bit
| abrasive, for the lack of a better expression.
| flntzr wrote:
| Thank you for the warning.
|
| Is the camera with GrapheneOS as good as the stock android
| one? I get to use my wife's iPhone camera sometimes and it
| frequently shocks me how good and responsive it is. But I'm
| coming from a OnePlus 8 Pro, which never had a great camera
| in the first place.
| bernoufakis wrote:
| I suck at taking pictures. It's definitely good enough, but
| worst case you can install the stock Google Camera app and
| disable network permission to limit snooping.
| flntzr wrote:
| Sweet, I think I'm sold on giving grapheneOS a shot.
| Thanks!
| bernoufakis wrote:
| Definitely worth a try !
| DavideNL wrote:
| I wonder how long it would take them/grapheneOS to support
| the new Pixel...
| bernoufakis wrote:
| They have been usually pretty fast !
|
| I think the Pixel Tablet was a matter of a week or two.
|
| There seems to be two challenges though that popped their
| nasty head lately. Some developer being temporarily
| unaivalable due to personal issue, and something about
| Android Open Source Project (GOS is built upon it, to put
| it simply) not necessarily support upcoming Pixels.
|
| But the team seems resilient and motiviated to keep the
| project going.
| strcat wrote:
| See https://news.ycombinator.com/item?id=44687530.
|
| > Although it is conterintuitive to use a Google device to
| get away from Google
|
| The purpose of GrapheneOS is privacy and security, not
| specifically avoiding Google, which is not what privacy is
| about overall. Many companies including Android OEMs have
| worse privacy practices.
|
| > Just stay out of the radar of the leadership, they can be a
| bit abrasive, for the lack of a better expression.
|
| There are a lot of ongoing attacks on the GrapheneOS project
| and our team including through fabricated stories and spin.
| People should look into the actual verifiable facts and look
| at who is being targeted with harassment and bullying. We
| defend ourselves from this including debunking inaccurate
| claims about the project and our team.
| strcat wrote:
| > I'd like to switch phones soonish and was looking at the
| fairphone 6 with /e/OS but feel deterred by its mid range specs
| which would probably limit its longevity. I would like to get
| away from google.
|
| Fairphones lack proper security patches and OS updates from day
| one. /e/OS makes this substantially worse compared to
| Fairphone's own OS. Fairphone tends to lag 1-2 months behind on
| Android's standard partial security backports and a year or
| more behind on yearly OS updates. They skip the monthly and
| quarterly releases. Fairphone 5 uses the Linux 5.4 LTS branch
| which will be end-of-life in December 2025 with no plan to move
| away. Older Fairphones use end-of-life kernel branches.
|
| Here's information from the author of the divested projects
| about /e/OS including data on updates from 2021 up until late
| 2024:
|
| Issues with /e/OS: https://codeberg.org/divested-
| mobile/divestos-website/raw/co...
|
| ASB update history:
| https://web.archive.org/web/20241231003546/https://divestos....
|
| Chromium update history:
| https://web.archive.org/web/20250119212018/https://divestos....
|
| Chromium update summary:
| https://infosec.exchange/@divested/112815308307602739
|
| For the Chromium update summary from July 2024, note 128/135
| was shipping each update on a given update path. /e/OS only
| shipped 12/135. They did not ship most Chromium security
| updates and skipped most releases. They're still skipping many
| releases and have significant delays for the ones they do ship.
|
| Here's an article from another privacy/security researcher on
| /e/OS covering some of these issues:
|
| https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...
|
| As documented there, /e/OS has their own invasive services
| including user tracking in the update client.
| https://community.e.foundation/t/voice-to-text-feature-using...
| is another example where /e/OS sends user data to OpenAI
| without consent for speech-to-text compared to Apple doing it
| locally by default and Google at least supporting doing it
| locally and encouraging enabling it.
|
| There's a third party comparison table at
| https://eylenburg.github.io/android_comparison.htm with a
| privacy and security focus. It doesn't currently cover invasive
| services added by operating systems or privacy/security
| regressions beyond patch delays though. It covers what is done
| with most of the standard AOSP services and how Google service
| compatibility is handled.
|
| > Is waiting for the new pixel and then putting grapheneOS on
| it a good way forward? Seems weird to pick a google device to
| get away from that company.
|
| The purpose of GrapheneOS is providing a high level of privacy
| and security. This requires secure hardware/firmware with
| important hardware-based security features and driver/firmware
| patches. Using a Fairphone with /e/OS is nearly the direct
| opposite of GrapheneOS.
|
| > Alternatively, there is the iPhone but I do like fdroid and
| the more open nature of android.
|
| An iPhone would be a far better choice for privacy and security
| than anything with /e/OS.
| greenie_beans wrote:
| some things about the UX in this is so bad, which i love because
| it discourages me from using the phone more. every time i end a
| phone call i struggle hanging it up. i don't know how to go
| forward in the browser because the swipe always makes me go back,
| even when i swipe forward. it's using the ugly material ui
| components from google. it's great!
|
| all of the privacy and security parts of the UX are good, though.
| strcat wrote:
| > some things about the UX in this is so bad, which i love
| because it discourages me from using the phone more. every time
| i end a phone call i struggle hanging it up. i don't know how
| to go forward in the browser because the swipe always makes me
| go back, even when i swipe forward. it's using the ugly
| material ui components from google. it's great!
|
| Android has a standard system back navigation gesture based on
| the previous system back button. Apps integrate support for it.
| Chromium disables their back/forward gestures when using the
| modern gesture navigation in the OS. It would have made sense
| to have a forward gesture but Android never had that as
| something apps had to implement so it would only work in a
| small subset of apps and would be generally unavailable, which
| would be confusing.
|
| Phone app has a button for ending the call. It's our fork of
| AOSP Dialer with minor changes including UI improvements.
| Calculator, Clock, Contacts, Gallery, Keyboard, Messaging and
| Phone are AOSP apps which we need to overhaul or replace. These
| look and function the same way Google's apps used to but are
| outdated. They're the open source projects which were abandoned
| beyond security patches after they forked them off into their
| own proprietary Google apps. Gallery and Keyboard will likely
| be replaced while the rest will be overhauled. We know these
| apps have a bad UI but our focus has been on the core OS
| instead of apps people can replace. We're beginning to do more
| work overhauling these.
| eskuero wrote:
| I have been using GrapheneOS en my pixel for almost a year and
| quite satisfied.
|
| The docs for compilation are neat so I'm running my own build
| with my own signatures and my own repository of their AppStore
| for my third party apps that I also build from source.
|
| I run only those apps on the main profile and then keep a private
| space (set to autokill on lock) for proprietary apps that require
| Play Services.
| 1vuio0pswjnm7 wrote:
| Does GrapheneOS firewall provide port forwarding or is Netguard
| required
| ciferkey wrote:
| Really feel a similar sentiment to a lot of others in the
| comments! I'm enjoying the recommendations other shared here. I
| _think_ this follows the rules of conduct for HN but let me know,
| I recently brained dumped about the following on my blog about
| the general experience setting up GrapheneOS:
| https://blog.matthewbrunelle.com/i-picked-a-really-weird-tim...
| emulio wrote:
| I wish to use Graphene OS, but I can't force myself to buy a
| Pixel Phone, I don't like the design.
| DavideNL wrote:
| Note that the author of the article has now added "corrections" :
|
| Corrections/elaborations on some points :
| https://lwn.net/Articles/1031454/
|
| Source: https://grapheneos.social/@GrapheneOS/114914602970489632
|
| > _Our community manager has provided a response to the recent
| LWN article on GrapheneOS with important corrections and
| context._ _The article had significant inaccuracies about the
| history of GrapheneOS, our organization and the details of what
| we provide._ _[.................]_
___________________________________________________________________
(page generated 2025-07-25 23:02 UTC)