[HN Gopher] GrapheneOS is the only Android OS providing full sec...
___________________________________________________________________
GrapheneOS is the only Android OS providing full security patches
Author : akyuu
Score : 372 points
Date : 2025-12-06 13:58 UTC (9 hours ago)
(HTM) web link (grapheneos.social)
(TXT) w3m dump (grapheneos.social)
| komali2 wrote:
| > may i ask how you obtain the source? Are you registered as an
| OEM at Google?
|
| Same question, how does Graphene get patches?
| AlgebraFox wrote:
| Yes. They've parterned with an OEM. In fact, they are making an
| official GOS phone with that OEM.
| styanax wrote:
| Here's the discussion forum post going over it:
| https://discuss.grapheneos.org/d/27068-grapheneos-
| security-p...
| subscribed wrote:
| They have partnership an OEM who provides them with sources.
|
| Currently they're only permitted to release binaries of the
| patches due to the embargo, this is why these patches are in
| the parallel stream/optional (so people unhappy with being
| unable to see the sources won't have them shoved down their
| throats).
|
| I don't have URLs at hand at the moment but all these questions
| have been asked many times and explained extensively on their
| discussion forum.
|
| I, for one, feel safe. I was patched since late October (IIRC)
| for the vulnerabilities that Android-related outlets were
| warning about in early December.
|
| It's quite surreal how unsafe the standard Android is. And how
| Google and the big companies pretend old devices (these running
| Android 11, 12, 13, not updated for several years) are safe and
| secure. While all it takes is the user stumbling upon one
| malicious we page or getting a WhatsApp message they won't even
| see.
| yaro330 wrote:
| > It's quite surreal how unsafe the standard Android
|
| Well that's untrue. I'd even venture to say that with how
| many OEMs there are it's insane how safe Android is. Google
| for one updates their devices for 7 years since Pixel 6, they
| can't control OEMs who might have ~10 people working on their
| devices.
| walterbell wrote:
| https://tbot.substack.com/p/grapheneos-new-oem-partnership
|
| _> GrapheneOS has officially confirmed a major new hardware
| partnership--one that marks the end of its long-standing Pixel
| exclusivity. According to the team, work with a major Android OEM
| began in June and is now moving toward the development of a next-
| generation smartphone built to meet GrapheneOS' strict privacy
| and security standards._
| axelthegerman wrote:
| Oh that's one of the best news in the smartphone world in a
| long time.
|
| It's impossible to escape the Apple/Google duopoly but at least
| GrapheneOS makes the most out of Android regarding privacy.
|
| I still wish we could get some kind of low resource, stable and
| mature Android clone instead of Google needlessly increasing
| complexity but this will over time break app compatibility
| (Google will make sure of it)
|
| Edit: I do think Pixel devices used to be one of the best but
| still I'd like to choose my hardware and software separately
| interoperating via standards
| Kuraj wrote:
| You might also be interested in Jolla Phone
| https://news.ycombinator.com/item?id=46162368
| Klonoar wrote:
| If you're stateside and want a shipping Linux phone today,
| [FuriLabs](http://furilabs.com) is another option.
|
| Graphene is in a class of its own compared to both of these
| though and there's frankly no reason to bother unless
| you're trying to improve those ecosystems.
| embedding-shape wrote:
| > Stateside - being in, going to, coming from, or
| characteristic of the 48 conterminous states of the U.S.
|
| In case others, like me, weren't aware.
| Klonoar wrote:
| I admit to being shocked that such a common phrase isn't
| widely understood, but this site has plenty of
| international traffic so I can only say thanks for the
| context comment. :)
| umbra07 wrote:
| Thanks! I had no idea that this existed. Unfortunately,
| the specs aren't great, especially when compared to
| Jolla's offering. Oh well.
|
| I'm quite enthusiastic about Graphene's OEM
| partnership,though.
| tenthirtyam wrote:
| I'm not knowledgeable enough -- what would it take to escape
| the Apple/Google duopoly?
|
| I'm imagining a future where you buy a smartphone and when
| you do the first configuration, it asks you which services
| provider you want to use. Google and Apple are probably at
| the top of the list, but at the bottom there is "custom..."
| where you can specify the IP or host.domain of your own self-
| hosted setup.
|
| Then, when you download an app, the app informs the app
| provider of this configuration and so your notifications
| (messenger, social media, games, banking, whatever) get
| delivered to that services provider and your phone gets them
| from there accordingly.
|
| Is there anything like that in the world today?
| immibis wrote:
| Any one of us here could learn the skills to design a
| smartphone. It won't necessarily be good, but I remember
| that years ago, someone made one with a touchscreen hat and
| GSM hat atop a Raspberry Pi, rubber-banded to a power bank.
| I'm sure any one of us HN users _could_ do this. And it
| worked. Quality only goes up from there.
|
| The problem is it won't run any apps, so you'll need to
| carry this open-source secure phone in addition to your
| normal phone.
| zdc1 wrote:
| Or use everything via the web browser; but yes, I think
| apps are the main reason we can't just have a generic
| Linux phone OS on an open hardware platform
| bossyTeacher wrote:
| Apps make or break operating systems and app stores. Just
| ask Microsoft (Windows Phone) or Huawei (HarmonyOs). IIRC
| amazon was paying devs to publish to their app store or
| something like that.
|
| Thankfully, some apps have both web and native mobile
| versions but for a modern digital life, the critical apps
| are sadly not on both versions.
| fsflover wrote:
| This is not as simple as you're saying. Making a new
| phone not relying on proprietary drivers tied to Android
| is impossible without a huge effort:
| https://news.ycombinator.com/item?id=21656355
| JoshTriplett wrote:
| > I'm not knowledgeable enough -- what would it take to
| escape the Apple/Google duopoly?
|
| At this point? Reliable emulation that can run 99% of
| Android apps, to provide a bridge until the platform is
| interesting enough for people to develop for it "natively".
|
| I think the easiest way to do that would be to run Android
| in a VM.
| gunalx wrote:
| You can go the waydroid style with namespacing, or native
| containers if using the linux kernel. No need to do a
| full vm
| JoshTriplett wrote:
| You could, but using containers requires that your kernel
| directly provide and secure Android-compatible
| functionality, such as binder. A VM gives you more
| options for abstracting that functionality.
|
| If you expect to be "essentially android, but a little
| different", containers make sense. If you want to build
| an entirely different mobile OS, but provide Android
| compatibility, I think a VM is much more likely to give
| you the flexibility to not defer to Android design
| decisions.
| lawn wrote:
| Similar to how Valve is managing the transition from
| Windows to Linux.
| charcircuit wrote:
| Why not run Android directly, such as using Graphene OS.
| It's decades ahead in both OS architecture, developer
| tools, and developers compared to non Android based Linux
| operating systems.
| fsflover wrote:
| Graphene uses the Google codebase, so Google is choosing
| its long-term development strategy and standards it will
| support. It's like choosing Chromium to escape Chrome.
| DANmode wrote:
| Not the worst choices!
| fsflover wrote:
| Indeed. However, in terms of the independence, better
| choices exist.
| charcircuit wrote:
| If someone is making a new browser, considering you want
| to support the same web standards as everyone else, being
| independent is pretty low on the priority lists. In fact
| it is more of a liability since it could make for
| compatibility issues.
| charcircuit wrote:
| The same can be said about the Linux codebase. Tomorrow
| Linus could private his branch and stop supporting public
| releases. If AOSP goes closed source then people can fork
| it and continue to maintain it.
| fsflover wrote:
| Linus is not known for decisions hostile to the users.
| Google is.
| bossyTeacher wrote:
| Graphene OS exists because Google lets it. You can't rely
| on competitors that can only exist in this manner
| fsflover wrote:
| You can escape the duopoly by using a GNI/Linux phone,
| Librem 5 or Pinephone, but don't expect any support from
| Google or Apple for them. I'm using the former as a daily
| driver.
| itissid wrote:
| I have been trying to come off of google and cloud by
| building -- quite slowly -- my own nas server which has 2
| nodes in two geographic regions where I am building certain
| services like cloud storage and backup, webhosting etc. But I
| think there are a few key things that need to be community
| driven to really get rid of this duoply.
|
| 0. A privacy first approach would be something like this:
|
| `You+App --Read/Write-> f_private(your_data) <--Write only-
| 3p` and App cannot communicate your data to 3p or
| google/apple.
|
| Think of Yelp/Google Maps but with no _read_ permissions on
| location, functions can be run in a private middleware e.g.
| what's near an anonymous location or ads based on anonymous
| data. You can wipe your data from one button click and start
| again for EVERYTHING, no data is ever stored on a 3p server.
| Bonus: No more stupid horrible permission fiascos for app
| development that are just plain creepy.
|
| 1. An opensource data effort that can support (0) with
| critical infra e.g. precise positioning, anonymous or privacy
| preserving functions that don't reveal their data or
| processes to 3p.
|
| Here is my favourite open source effort: Precise Location
| Positioning. A high recall, opensource, 3D building and
| sattelite-shadow Data-Infra effort[3]. This world class
| dataset on shadows and sattelites are a must. Most geo-
| location positioning tied to Radio signals is just a bandaid
| and fraught with privacy issues -- thought there are heroic
| privacy first efforts in this direction[1][2] which though
| amazing will be playing catch-up with google already
| deploying [3].
|
| [1]https://beacondb.net/
|
| [2] https://github.com/wiglenet/m8b
|
| [3] https://insidegnss.com/end-game-for-urban-gnss-googles-
| use-o...
| matheusmoreira wrote:
| This is excellent news. Google doesn't sell Pixels in my
| country for some reason. Hopefully the new phones will be
| easier to obtain.
| DANmode wrote:
| Have you considered using mail forwarding, or sites like
| Swappa.com with forwarding built in?
|
| Hoping this helps you get your hands on a cheap Pixel!
| YY876438726 wrote:
| Has the OEM in question been revealed yet? Likely not one of
| the major OEMs because they all lock their bootloaders. I'm
| crossing my fingers it's Fairphone but that's because I love my
| FP5. The GrapheneOS devs have been pretty harsh towards
| Fairphone because of their slow updates.
| moooo99 wrote:
| They seem to refuse that they're working with fairphone, so
| it seems unlikely.
|
| https://www.reddit.com/r/GrapheneOS/comments/1o3vmn5/comment.
| ..
|
| My guess is that its either HMD or Nothing. Will probably
| still take a while until we learn about this
| umbra07 wrote:
| The most likely contenders are OnePlus, Motorola, and HMD.
|
| > "It is a big enough OEM that there is good chance you may
| have owned a device from them in the past."
|
| I think this takes Nothing out of contention.
| zikduruqe wrote:
| What about HTC, LG? Heck, Blackberry rising from the ashes?
|
| I'd love for it to be Framework.
| bloqs wrote:
| I literally just bought a pixel this week. Just my luck.
| muyuu wrote:
| probably good timing
|
| this will take a while and RAM prices will be out of control
| for a while as well
| getpokedagain wrote:
| I guess my 8a is gonna have to do for a bit longer. This one is
| very exciting.
| joelthelion wrote:
| This is really cool, but, longer term, what happens if Google
| makes android closed source? I feel this is a very real risk.
| worldsavior wrote:
| They won't because they literally control the mobile market
| by having Android open source.
| joelthelion wrote:
| Now that their market is established, I don't think open-
| source is a requirement anymore. They would of course share
| with hardware vendors strategically.
| hamandcheese wrote:
| I wonder if a real OEM supports graphene if that would solve
| device attestation for things like banking apps.
| nanomonkey wrote:
| As a LineageOS user, I'd be interested in the disparity between
| GrapheneOS and LineageOS.
| worldsavior wrote:
| https://eylenburg.github.io/android_comparison.htm
| uneekname wrote:
| This is a great resource! Thanks
| the_biot wrote:
| That comparison shows "Deblobbed? Yes" for GrapheneOS. That
| implies they've replaced (most of) the blobs for wifi,
| bluetooth, 5g chips etc.
|
| Is that actually true? It's such a big deal, and I see little
| to no work being done on this front.
|
| Anyone have any idea what GrapheneOS actually deblobbed?
| fmajid wrote:
| They can because they essentially support Google chipsets,
| which are not blobby like MediaTek or Qualcomm because
| Google for all its faults is still relatively open (except
| their recent change in release schedules is why the Pixel
| 10 series still only has experimental GrapheneOS support).
| vbezhenar wrote:
| Do you claim that there's a place where I can find
| datasheets for peripheral devices for Google Pixel? Like
| GPU, etc.
| fmajid wrote:
| No, but they used to publish the source code for the
| drivers as part of AOSP. Now they no longer publish the
| device trees. Check out GrapheneOS' other Mastodon posts
| for the gory details.
| joecool1029 wrote:
| Here's an example of the radio firmware and vendor blobs
| required for a pixel 9 pro XL build: https://github.com/T
| heMuppets/proprietary_vendor_google_komo...
|
| Nobody, including Graphene, is getting away with building
| their own modem firmware. The reduced blobs are on
| userspace and some HAL components.
| yaro330 wrote:
| It's nowhere near that. Pretty sure even modules are signed
| by Google.
| rolandog wrote:
| Nice! Thanks for the link. I noticed they didn't mention
| MOCOR OS (for the new Nokia 3210), but then I remembered that
| that's not an Android version. I'll see if they can add it
| somewhere else.
|
| Unrelated, but this led me to find gnuclad, which may be
| somewhat externally maintained and is used to create the
| cladogragms.
| mcsniff wrote:
| If you care about security above all else and you have a Pixel,
| GrapheneOS should really be your only consideration.
|
| LineageOS has a place for those who care less about security
| and more about features, "freedom", compatibility, community
| etc...
|
| I was a LOS user and maintained my own forks for devices, but
| switching to GrapheneOS was a good decision and I don't really
| miss anything.
| subscribed wrote:
| It might be important to mention, that Lineage OS is
| available on a number of the devices abandoned by their
| original vendors, so sometimes it may be a much better
| solution to get a Lineage OS onto their former "flagship"
| which stopped getting updates 18 months after the release.
|
| So if the bootloader can be relocked and not passing Play
| Integrity scam is not a problem, Lineage may be a better
| option. Better than nothing, that is.
| Terr_ wrote:
| Just yesterday I took an old Motorola smartphone from 8
| years ago (Android 9) and put LineageOS on it.
|
| Poof, it's transformed from unusually-glitchy e-waste to a
| tool someone can actually benefit from.
|
| > So if the bootloader can be relocked
|
| Their website says they recommend against that and will not
| support it, because of a high chance the device will get
| bricked. :(
| zekica wrote:
| They have different goals:
|
| GrapheneOS wants to make a FOSS Android with the security model
| that makes it hard for any bad party to break into the phone.
|
| LineageOS wants to make a FOSS Android that respects user's
| privacy first and foremost - it implements security as best as
| it can but the level of security protections differs on
| different supported devices.
|
| Good news is that if you have a boot passphrase, it's security
| is somewhat close to GrapheneOS - differing in that third
| parties with local access to the device can still brute-force
| their access whereas with GrapheneOS they can't - unless they
| have access to hardware level attacks.
| akimbostrawman wrote:
| that is simply wrong.
|
| GrapheneOS is both in terms of security and privacy the best
| but currently only supports pixel phones.
|
| LineageOS is trying to support as many devices as possible
| still with lot of google connections and missing security
| updates.
|
| >Good news is that if you have a boot passphrase, it's
| security is somewhat close to GrapheneOS
|
| its not anywhere close https://grapheneos.org/features
| xxmarkuski wrote:
| Graphene OS provides advanced security capabilities and a
| thorough defense-in-depth approach including a hardened supply
| chain. GOS aims to provide mechanisms to protect against 0day
| attacks. For example Celebrite can not open up GOS. GOS relys
| on hardware support provided by Pixels. Graphene OS works on
| getting their developments upstream.
|
| For a list of security features see here [0].
|
| [0] https://grapheneos.org/features
| ForHackernews wrote:
| GrapheneOS is a locked-down, security-hardened system that's
| good if you need absolutely maximal security (e.g. journalists,
| activists, folks targeted by state actors). LineageOS is a more
| of an open system for tinkerers who want to play outside
| Google's walled garden.
|
| You can have root to control your own device on Lineage, but
| not Graphene.
| arcanemachiner wrote:
| I believe you can root GrapheneOS. It just breaks the
| security model, so it's not recommended to do so.
| ForHackernews wrote:
| Ah, you're right: https://github.com/schnatterer/rooted-
| graphene
|
| I stand corrected. Still, as you say, less point in it
| since it breaks their security model.
| drnick1 wrote:
| If you have a Pixel -> Graphene, if not -> Lineage.
|
| I personally don't care about "security" all that much, my main
| reason for using Graphene is freedom to use my hardware in any
| way I wish. This means unrestricted ability to run any program
| on the phone from any source. Sideloading restrictions don't
| apply to Graphene, and it is also impossible for state actors
| to impose things such as client-side scanning of text messages.
| It's also immune to unwanted AI anti-features.
|
| I use my own "cloud" infrastructure with my phone and I am not
| interested in using Google's. My Graphene device is configured
| to route all traffic through Wireguard tunnel and my DNS
| server. I also use exclusively use my own email server and
| "cloud" storage for all non-work related purposes. Graphene
| makes this easy by not leaking any information to Google.
| SubiculumCode wrote:
| Why was it that in the early PC days, IBM was unable to keep a
| lid on 'IBM compatible', allowing for the PC interoperability
| explosion, yet today, almost every phone has closed drivers,
| closed and locked bootloaders, and almost complete corporate
| control over our devices? Why are there not yet a plethora of
| phones on the market that allow anyone to install their OS of
| choice?
| idle_zealot wrote:
| > Why are there not yet a plethora of phones on the market that
| allow anyone to install their OS of choice?
|
| There are technical reasons, but as ever the real underlying
| causes are incentives. Companies realized that the OS is a
| profit center, something they can use to influence user
| behavior to their benefit. Before the goal was to be a hardware
| company and offer the best hardware possible for cost. Now the
| goal is to own as large a slice of your life as possible. It's
| more of a social shift than a technological one. So why would a
| company, in this new environment, invest resources in making
| their hardware compatible with _competing_ software
| environments? They 'd be undercutting themselves.
|
| That's not to say that attempts to build interoperability don't
| exist, just that they happen due to what are essentially
| activist efforts, the human factor, acting in spite of and
| against market forces. That doesn't tend to win out, except
| (rarely) in the political realm.
|
| i.e. if you want interoperable mobile hardware you need a law,
| the market's not going to save you one this one.
| fmajid wrote:
| Most ARM devices don't have UEFI or a standardized hardware
| abstraction layer as x86/x64 does, a prerequisite for having
| a choice of OSes.
| vbezhenar wrote:
| I don't believe that's the true problem. Booting operating
| system is not a problem. There's no standardized hardware
| abstraction layer in PC either, every OS brings their own
| set of drivers.
|
| My guess is that modern hardware is too complicated for one
| hacker to write reliable drivers. That wasn't the case back
| in the 90-s, when Linux matured. So we are at mercy of
| hardware manufacturers and they happened to not be
| interested in open upstreamed drivers.
| immibis wrote:
| In the ARM world, there isn't even a standard way to
| boot, and there are _no_ standard hardware interfaces -
| except maybe the interrupt controller, since it 's part
| of the CPU and only ARM designs the CPUs.
|
| On any PC, you can still use BIOS/UEFI services to get a
| basic framebuffer and keyboard input. You cannot do that
| on embedded ARM devices - you need to get several layers
| into the graphics stack to have a framebuffer. I tried it
| on the PinePhone, using existing source code as a
| reference, and the furthest I got was sending commands
| from the video port to the LCD controller and then not
| having an oscilloscope to see if the LCD controller
| replied back.
| vbezhenar wrote:
| I worked with ARM boards, I know a bit about it. Booting
| into Linux is never hard, it's all about using uboot,
| sometimes with tiny patches on top. I think it's actually
| even easier with android phones, as you don't have access
| to the low level bootloader, you just use fastboot stuff.
|
| Having basic framebuffer in BIOS/UEFI is neat for toy
| OSes, but not very relevant for something practical. You
| gotta need proper driver for GPU. And if you're just
| starting, UART console is actually more preferable way to
| interact with board, IMO.
| zozbot234 wrote:
| Booting into a _mainline Linux kernel_ on your average
| junk-level SBC _with all the hardware working_ (without
| simply sticking to an Android-like downstream
| /proprietary BSP) is quite hard, and that's what you need
| in order to make a phone usable as a daily driver. That's
| really the root issue; mobile phones are built as
| embedded devices, with no consideration for running a
| generic OS kernel. This isn't even an Android issue,
| OpenMoko was the same deal. If anything, Android was the
| first mobile platform to even loosely approach any kind
| of PC-like openness.
| matheusmoreira wrote:
| > My guess is that modern hardware is too complicated for
| one hacker to write reliable drivers.
|
| Modern hardware has turned our operating systems into
| isolated "user OS" nodes in the schematics, completely
| sandboxed away from the real action. Our operating
| systems don't really operate systems anymore.
|
| https://youtu.be/36myc8wQhLo
| dizhn wrote:
| Excellent and scary video that I share myself all the
| time.
| photochemsyn wrote:
| I generally agree, but as a caveat sometimes it's cheaper,
| more robust and more efficient to build an integrated system
| without having to worry about interoperability. BYD's
| electric vehicle chasis for example, seems to greatly cut
| manufacturing costs, even if it makes swap-in repairs harder
| down the road.
|
| But, I'd guess this accounts for a relatively small fraction
| of corporate decision on lock-in strategies for rent
| extraction - advanced users should be able to treat their
| cell phones OS like laptops, with the same basic concepts, eg
| just lock down the firmware for the radio output, to keep the
| carriers happy, and open everything else, maybe with a
| warranty void if you swap out your OS. Laws are needed for
| that, certainly.
| AnthonyMouse wrote:
| > So why would a company, in this new environment, invest
| resources in making their hardware compatible with
| _competing_ software environments?
|
| Because that's what customers want to buy. People are paying
| premium iPhone prices for hardware with mediocre specs and
| then the hardware sells out when someone like Purism or
| Fairphone actually makes an open one. How many sales would
| you get if you did the same thing on a phone that was
| actually price/performance competitive with the closed ones?
|
| Meanwhile all of that "profit center" talk is MBA hopium.
| Nobody is actually using the Xiaomi App Store, least of all
| the people who would put a different OS on their phone.
|
| The real problem here is Google. Hardware attestation needs
| to be an antitrust violation the same as Microsoft
| intentionally breaking software when you tried to run it on a
| competing version of DOS and for exactly the same reason.
| sroussey wrote:
| Some of the funnest work, if you could get it, was swapping
| ssds out of laptops coming through customs for high value
| targets.
| matheusmoreira wrote:
| > Hardware attestation needs to be an antitrust violation
|
| Yes!! Absolutely agree. This needs to be made illegal.
| piyuv wrote:
| Cory Doctorow answers this in his book "The Internet Con". IBM
| fought with DoJ for years. Today, it's a felony to mess with
| anything locked down (anti circumvention)
| subscribed wrote:
| I don't think it's a felony to root/jailbreak one's own
| phone.
| Yokolos wrote:
| The problem is doing it as a company. IBM wasn't defeated
| by hobbyists building their own PCs. They were defeated by
| other companies reverse engineering their BIOS and selling
| their own IBM compatible systems. This isn't possible
| anymore. It just means you get buried in lawsuits until you
| go bankrupt.
| immibis wrote:
| It is. 17 U.S. Code SS 1201 - Circumvention of copyright
| protection systems
| aspenmayer wrote:
| Well actually, it isn't for individuals and certain
| groups, technically.
|
| Rooting/jailbreaking have had exemptions for many years
| now, on a three year basis which has seemingly been
| continually renewed, by the Librarian of Congress.
|
| _Exemption to Prohibition on Circumvention of Copyright
| Protection Systems for Access Control Technologies_
| (2024)
|
| https://www.federalregister.gov/documents/2024/10/28/2024
| -24...
|
| https://www.eff.org/issues/dmca-rulemaking
| matheusmoreira wrote:
| https://www.eff.org/deeplinks/2019/06/felony-contempt-
| busine...
|
| It's not your phone, it's theirs. They're just letting you
| use it, and only if you're a good boy who follows all their
| policies and terms and conditions. Subvert this in any way
| and it's a felony.
| mattmaroon wrote:
| The only thing proprietary in the early PC architecture was the
| BIOS. Everything else was pre-existing architecture from third
| parties, there was nothing to keep a lid on.
|
| Since a PC was a big box of parts anyone could manufacture one.
| A modern phone is much more complicated.
|
| As to why there aren't a plethora: the market doesn't demand it
| that much. The people doing it aren't wildly successful.
| Perhaps that's changing (I hope so) but I know very few people
| outside this community who have ever thought "I wish I could
| have a third party version of Android".
| mcny wrote:
| Even the batteries are not interchangeable on phones. You'd
| think all phones should have the same exact battery, that
| this kind of standardization is beneficial for phone
| manufacturers as it helps them bargain with their parts
| suppliers but no for whatever reason we can't have that.
|
| Edit: I am not saying just user replaceable. I mean
| standardized so the same cells in a 2024 phone also works on
| 2025...
| Bratmon wrote:
| Why, of all parts on a phone, would you expect the battery
| to be the one that's already good enough that it should
| never need to be upgraded?
|
| "Battery capacity" is like the one thing phone
| manufacturers still try to improve.
| shagie wrote:
| The company making a device that is licensed by the FCC has to
| do everything that they can to mitigate the risk of an
| unlicensed broadcast on their devices.
|
| https://www.fcc.gov/oet/ea/rfdevice
|
| > INTENTIONAL RADIATORS (Part 15, Subparts C through F and H)
|
| > An intentional radiator (defined in Section 15.3 (o)) is a
| device that intentionally generates and emits radio frequency
| energy by radiation or induction that may be operated without
| an individual license.
|
| > Examples include: wireless garage door openers, wireless
| microphones, RF universal remote control devices, cordless
| telephones, wireless alarm systems, Wi-Fi transmitters, and
| Bluetooth radio devices.
|
| https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A...
|
| Other countries have similar regulations.
|
| PCs don't have that restriction.
|
| You might be able to get to the point where _you_ have a
| broadcast license and can get approved to transmit in the
| cellphone radio spectrum and get FCC approval for doing so with
| your device... but if you were to distribute it and someone
| else was easily able to modify it who _wasn 't_ licensed and
| made it into a jammer you would also be liable.
|
| The scale that the cellphone companies work at such liability
| is not something that they are comfortable with. So the devices
| they sell are locked down as hard as they can to make it clear
| that if someone _was_ to modify a device they were selling it
| wasn 't something that they intended or made easy.
| AnthonyMouse wrote:
| I see people saying things like this all the time and then
| when I ask them for the specific text requiring them not to
| e.g. publish source code, nobody has been able to show me.
|
| And a huge reason it seems like BS is this:
|
| > PCs don't have that restriction.
|
| There are obviously PCs with Wi-Fi and even cellular modems,
| so this can't be an excuse for a phone to not be at least as
| open as a PC.
| TheCraiggers wrote:
| > The company making a device that is licensed by the FCC has
| to do everything that they can to mitigate the risk of an
| unlicensed broadcast on their devices.
|
| Where do you see this in the rules? The only thing I see that
| even comes close is the following sentence:
|
| "Manufacturers and importers should use good engineering
| judgment before they market and sell these products, to
| minimize possible interference"
|
| Maybe it's because I don't routinely deal with the FCC but to
| me, that language doesn't imply anything close to your
| ironclad rule you posted.
|
| I'll also point out there are plenty of other devices that
| get sold that seemingly break your rule. SDRs, walkie talkies
| with the power to transmit for miles, basically every
| computer motherboard made since the year 2010, the Flipper,
| etc. At most, they simply have some fine print in the manual
| saying "you should probably have an FCC license to use this".
| shagie wrote:
| SDR for listening does not require a license. For
| transmission, depending on the power and frequency may
| require a broadcast license.
|
| https://www.reddit.com/r/RTLSDR/comments/dx5sln/do_develope
| r...
|
| Depending on the power of the walkie talkie, it may require
| a license.
|
| https://www.rcscommunications.com/which-two-way-radios-
| requi...
|
| > MURS (Multi-Use Radio Service) - Two-way radios
| programmed to operate within the MURS (Multi-Use Radio
| Service) are not required to be licensed. They transmit at
| 2 watts or less and only operate on pre-set frequencies
| between 151 -154 MHz in the VHF band. MURS radios have a
| general lack of privacy, a limited coverage area, and
| frequent channel interference.
|
| > ...
|
| > GMRS (General Mobile Radio Service) - The General Mobile
| Radio Service (GMRS) is another of the most popular and
| numerous licenses the FCC granted. GMRS licenses allow for
| radios to transmit up to 50 watts. GMRS licenses also allow
| for hand-held, mobile, and repeater devices. The GMRS
| spectrum has 22 channels that it shares with FRS and an
| additional 8 repeater channels that are exclusive to GMRS.
|
| > Virtually Every Other Land Mobile Radio (LMR) Device -
| Virtually all two-way radios beyond the models mentioned
| above are subject to FCC licensing. In fact, any device
| that transmits at 4 watts or higher requires coordination
| (and, thereby, licensing) by the FCC.
|
| ---
|
| The Flipper is licensed to operate with a particular set of
| power and frequency ranges.
| https://flipperzero.one/compliance
|
| For the SDR it is licensed to operate between 304.5 -
| 321.95; 433.075 - 434.775; and 915.0 - 927.95 MHZ range in
| the US.
|
| Note that none of those are the cellphone frequency bands.
|
| ---
|
| https://prplfoundation.org/yes-the-fcc-might-ban-your-
| operat...
|
| which quotes 2.1033 Application for grant of certification.
| Paragraph 4(i):
|
| > For devices including modular transmitters which are
| software defined radios and use software to control the
| radio or other parameters subject to the Commission's
| rules, the description must include details of the
| equipment's capabilities for software modification and
| upgradeability, including all frequency bands, power
| levels, modulation types, or other modes of operation for
| which the device is designed to operate, whether or not the
| device will be initially marketed with all modes enabled.
| The description must state which parties will be authorized
| to make software changes (e.g., the grantee, wireless
| service providers, other authorized parties) and the
| software controls that are provided to prevent unauthorized
| parties from enabling different modes of operation.
| Manufacturers must describe the methods used in the device
| to secure the software in their application for equipment
| authorization and must include a high level operational
| description or flow diagram of the software that controls
| the radio frequency operating parameters. The applicant
| must provide an attestation that only permissible modes of
| operation may be selected by a user.
|
| and 2.1042 Certified modular transmitters. Paragraph (8)(e)
|
| > Manufacturers of any radio including certified modular
| transmitters which includes a software defined radio must
| take steps to ensure that only software that has been
| approved with a particular radio can be loaded into that
| radio. The software must not allow the installers or end-
| user to operate the transmitter with operating frequencies,
| output power, modulation types or other radio frequency
| parameters outside those that were approved. Manufacturers
| may use means including, but not limited to the use of a
| private network that allows only authenticated users to
| download software, electronic signatures in software or
| coding in hardware that is decoded by software to verify
| that new software can be legally loaded into a device to
| meet these requirements.
| TheCraiggers wrote:
| Well, I sit corrected. Thanks for digging all that up.
| jabl wrote:
| Other companies saw that IBM effectively lost control over
| their platform (and thus lost a large revenue stream), and are
| determined to not make the same mistake.
|
| That's a long running effort, going all the way from lobbying
| (DMCA and their ilk), to all kinds of hardware root-of-trust,
| encrypted and signed firmware, OS kernels and drivers etc etc.
| And yes, today we have the transistor budgets to spend on
| things like this, which wasn't an option back when the PC
| architecture was devised.
| chasil wrote:
| The systems and software were vastly less complex and powerful
| in the 8088 days.
|
| Very little of it was open, including the headliner apps of
| WordPerfect and 123.
|
| Google had the benefit of three decades to study IBM's loss of
| control to prevent it with Android. Aside from China, they have
| been largely successful.
| cwyers wrote:
| Because the original IBM PC was designed to be cheap and built
| in a hurry. IBM had a mandate for the original PC to use off
| the shelf components as much as possible. They also neglected
| to secure an exclusive license from Microsoft for DOS. 95% of
| building an IBM PC clone was buying the same parts and getting
| a DOS license from Microsoft (which they were very happy to
| sell you). Everyone saw what happened to IBM and just didn't do
| it that way again.
| cwyers wrote:
| You can actually look at history and see what happens when
| IBM tries to wrest control of the PC platform back with the
| PS/2, which was a flop with consumers because it wasn't
| backwards compatible enough with IBM's own previous PCs or
| the wider PC market that developed. A bunch of PC clone
| manufacturers got together and came up with the EISA bus
| standard so they wouldn't have to pay IBM license fees for
| MCA, and made it backwards-compatible with ISA cards people
| already had. It was successful enough that IBM ended up
| adopting EISA for some of their PCs.
|
| The other notable thing about the situation is that three
| companies ended up simultaneously responsible for a large
| part of the PC platform, originally -- IBM, Microsoft and
| Intel. They all worked in various ways to encourage
| competition to each other -- the reason we see OS competition
| on the PC platform is that IBM and Intel both found it in
| their interests to allow other OSes on the platform to reduce
| Microsoft's leverage over them. IBM in fact created one of
| the competing PC OSes out the gate, OS/2, which was
| originally an IBM/Microsoft joint project until they started
| feuding. Now, OS/2 is dead, but IBM's interest in being able
| to support their own OS instead of Microsoft's is a big
| reason the PC platform was built in an OS agnostic way.
| People criticize UEFI for locking down the PC platform more
| than the previous BIOS implementations, but UEFI is still
| _way_ more open than basically any other platform, most of
| which don't have a standard for bootloaders at all. It's
| really the absense of a standard for bootloaders that keeps
| most Android phones locked down. Two Android phones from the
| same OEM might have different bootloaders, much less two
| phones from different manufacturers. We've yet to see an
| alternate OS with the resources to support implementing their
| own bootloaders for a majority of Android phones.
| masklinn wrote:
| > Why was it that in the early PC days, IBM was unable to keep
| a lid on 'IBM compatible', allowing for the PC interoperability
| explosion
|
| IBM didn't think to lock it down, the BIOS was the main blocker
| and was relatively quickly reverse-engineered (properly, not by
| copying over the BIOS source IBM had included in the reference
| manual). They tried to fix some with the MCA bus of the PS/2
| but that flopped.
|
| > almost every phone has closed drivers
|
| Lots of hardware manufacturers refuse to provide anything else
| and balk at the idea of open drivers. And reverse engineering
| drivers is either not worth the hassle for the manufacturer or
| a risk of being sued.
|
| > Why are there not yet a plethora of phones on the market that
| allow anyone to install their OS of choice?
|
| Incentive. Specifically its complete lack of existence.
| acomjean wrote:
| IBM was in a hurry.
|
| From triumph of the nerds part 2 ( worth a watch.. they also
| explain how IBM ended up getting and operating system from
| Microsoft)
|
| https://www.pbs.org/nerds/part2.html
|
| https://youtu.be/_cMtZFwqPHc
|
| "In business, as in comedy, timing is everything, and time
| looked like it might be running out for an IBM PC. I'm
| visiting an IBMer who took up the challenge. In August 1979,
| as IBM's top management met to discuss their PC crisis, Bill
| Lowe ran a small lab in Boca Raton Florida.
|
| Bill Lowe:
|
| Hello Bob nice to see you. BOB: Nice to see you again. I
| tried to match the IBM dress code how did I do? BILL: That's
| terrific, that's terrific.
|
| He knew the company was in a quandary. Wait another year and
| the PC industry would be too big even for IBM to take on.
| Chairman Frank Carey turned to the department heads and said
| HELP!!!
|
| Bill Lowe Head, IBM IBM PC Development Team 1980:
|
| He kind of said well, what should we do, and I said well, we
| think we know what we would like to do if we were going to
| proceed with our own product and he said no, he said at IBM
| it would take four years and three hundred people to do
| anything, I mean it's just a fact of life. And I said no sir,
| we can provide with product in a year. And he abruptly ended
| the meeting, he said you're on Lowe, come back in two weeks
| and tell me what you need.
|
| An IBM product in a year! Ridiculous! Down in the basement
| Bill still has the plan. To save time, instead of building a
| computer from scratch, they would buy components off the
| shelf and assemble them -- what in IBM speak was called 'open
| architecture.' IBM never did this. Two weeks later Bill
| proposed his heresy to the Chairman.
|
| Bill Lowe:
|
| And frankly this is it. The key decisions were to go with an
| open architecture, non IBM technology, non IBM software, non
| IBM sales and non IBM service. And we probably spent a full
| half of the presentation carrying the corporate management
| committee into this concept. Because this was a new concept
| for IBM at that point. BOB: Was it a hard sell? BILL: Mr.
| Carey bought it. And as result of him buying it, we got
| through it.
| cons0le wrote:
| You're getting a lot of indirect responses. If you've ever
| tried to mod your android phone the answer is simple. Its
| google play services and hardware attestation for things like
| banking websites.
|
| Its really easy to make a custom rom but hard to do serious
| "real life" stuff; companies don't want to make it easy. To
| most regular users, if they cant download apps from the google
| play store, and they can't use venmo\cashapp, then the OS is
| dead in the water from day 1
| SubiculumCode wrote:
| Yeah but lots of phones you can't get ROMs for from a
| reputable source, and I sure as heck don't have the know how
| or time to build one, even if possible, which a lot of times
| is not due to locking down bootloaders, drivers, etc.
| AnthonyMouse wrote:
| But that has the same cause.
|
| When you buy a Windows PC, the first thing a lot of tech
| people will do is format it and put on a clean install of
| Windows without all of the OEM crapware, or in these days
| install Linux if grandma is just using email and Facebook
| anyway.
|
| If you try to do that on your Android device, your bank app
| is broken, most importantly _not because of anything the
| alternate OS is doing wrong_ , which causes the vast
| majority of people to not want to do it even if it means
| suffering the OEM crapware, with no way for the alternative
| OS to fix it. And that in turn allows the OEMs to get away
| with locked bootloaders etc., because then they're not
| losing sales to a competitor that lets you remove the
| crapware when nobody can do it either way.
| wafflemaker wrote:
| For me the bank app was working, but the electric scooter
| app didn't and that was it for me :( Damn e-scooters,
| can't live without them.
|
| But I still haven't contacted the support to ask them to
| verify phones in another way.
| charcircuit wrote:
| This just shows that the barrier of entry of a new phone OS
| is more than $0. You can pay app developers to port their
| apps off of play services, you can pay developers to add
| support for your attestation keys. Considering how many
| billions of dollars Android makes for Google, there is a room
| for a return on investment for an alternate OS to enable
| investments into a new OS.
| zelphirkalt wrote:
| How much do you want to pay? Who will be paying? Big
| companies will probably laugh such an effort out of the
| room, nay, they will not even let you into the room to talk
| with them.
| charcircuit wrote:
| $10 million dollars per app. The creator of the new OS
| will pay. If you offer enough cash they will stop
| laughing.
| bossyTeacher wrote:
| Where do you think the creators will get this money from?
| Look at existing ones, they are cash strapped as they
| are, paying a million to get an app over beyond their
| budget, let alone 10 million
| charcircuit wrote:
| Investors. Trying to become a new competitor in an
| established industry often takes a large amount of
| capital. If you tried to create a business to compete in
| another industry, you'd also need to find investors or
| other forms of financing if you are cash strapped.
| makeitdouble wrote:
| Have you ever tried to pay a bank to do something for you
| ?
|
| Trying to get some scale, you're hypothesizing about
| giving 10 millions to HSBC to make business with your
| startup, when they're throwing away 500+ millions every
| year just to cover their money laundering.
|
| https://www.investopedia.com/stock-
| analysis/2013/investing-n...
| makeitdouble wrote:
| That's akin to creating a new browser and pay site owners
| to support your client. You can do it for a few dozen sites
| but that can't be your primary strategy.
|
| We actually saw this play out twice with Microsoft's return
| to mobile (Windows phone) and web browsers, money is a
| pretty small part of it.
| HPsquared wrote:
| The business world learned from their mistake.
| flomo wrote:
| Nobody gave you the actual answer. IBM was under an antitrust
| decree and had to openly license their technology for a nominal
| fee. (Supposedly about $5/PC.) So yes, they were in a hurry and
| used generic parts, but they still had tons of patents on it.
| When they got out from under this, they came up with
| Microchannel.
| fpoling wrote:
| The hardware was evolving way faster 40 years ago and in much
| consequent ways than these days. Plus number of users grew
| exponentially. So a company spending too much efforts on
| software could loose its edge on the hardware side. And locking
| hardware would be counterproductive since as it would limit new
| users.
|
| These days things are way slower and the are no exponential
| growth in users. Plus fast cellular networks made the speed of
| local hardware much less relevant. So the software became way
| more important and so its control.
| jMyles wrote:
| Obviously this situation can't go on.
|
| If neither of the two major players can make an open, secure,
| _simple_, easy-to-understand, bloat-free OS, then we somehow need
| another player.
|
| Presently (and I confess, my bias to seek non-state solutions may
| show here), it seems that a non-trivial part of the duopoly stems
| from regulatory capture insofar as the duopoly isn't merely
| software, but extends all the way to TSMC and Qualcomm, whose
| operations seem to be completely subject to state dictates, both
| economic/regulatory and of the darker surveillance/statecraft
| variety (and of those, presumably some are classified).
|
| I'm reminded of the server market 20ish years ago, where,
| although there were more than two players, the array of simple,
| flexible linux distros that are dominant today were somewhere
| between poorly documented and unavailable. I remember my
| university still running windows servers in ~2008 or so.
|
| What do we need to do to achieve the same evolution that the last
| 2-3 decades of server OS's have seen? Is there presently a mobile
| linux OS that's worth jumping on? Is there simple hardware to go
| with it?
| akyuu wrote:
| Take a look at Jolla and Sailfish OS.
|
| https://news.ycombinator.com/item?id=46162368
|
| https://sailfishos.org
| nextos wrote:
| FWIW, Jolla just announced a new phone:
| https://commerce.jolla.com/products/jolla-phone-preorder
| aaravchen wrote:
| It was discussed here when it was announced. I believe it
| was determined the hardware is an ultra-low-budget
| Aliexpress design that normally retails for ~$100 that they
| had custom built with a mic cutoff switch added to it
| (probably the cause of a large portion of the hardware
| price increase). I dont remember the specifics, but even
| thr most optimistic were pretty sure it won't get hardware
| vendor support for even a full year based on the specific
| processor it contains.
| frogperson wrote:
| https://liberux.net/ looks promising as well.
| aaravchen wrote:
| WARNING: This is a Kickstarter device still, and needed
| funding to even create a proof of concept device last time
| it was discussed (extensively). It's a Flagship phone
| device and price, but with only the oldest of pans on how
| it's actually going to deliver some on of the promises.
| Klonoar wrote:
| One comment mentioned Jolla. Another currently available option
| is [FuriLabs](http://furilabs.com). It runs atop Hallium/etc
| but you are effectively still able to daily drive a mobile
| Linux shell and contribute to the ecosystem if you want to see
| it grow.
|
| Now with that said: so much work has gone in to Android (and by
| extension, Graphene) to improve on power usage/security/etc
| that I'm not sure I'd bother to actually run a mobile Linux
| device. The juice just doesn't feel worth the squeeze.
| aaravchen wrote:
| Furilabs was just in the news here because they discontinued
| their device models from a few years ago, and released a new
| device for a big price bump with _significantly worse_
| hardware.
|
| I know I would love to give them a try, but a 720 screen is
| an absolute non starter for me. It would be hard for anyone
| to sell me on just a FullHD (1080) screen in the era of QHD
| (2K) being industry standard. Additionally, I believe their
| FAQ even admits that their already low power devices only get
| a few hours of battery life.
| fsflover wrote:
| GNU/Linux phones exist and can be used as daily drivers, if you
| put enough effort in it. Sent from my Librem 5.
| y-c-o-m-b wrote:
| Graphene has really caught my eye in the last several months, but
| unfortunately I couldn't find a good deal for Pixel phones
| (>128GB storage), used or new. That's the biggest bottleneck for
| adoption it seems. I just finally switched from an S10E to a
| S25Ultra (black friday deal brought down to $820), but not being
| able to use Graphene in the future hurts a bit for sure.
| gruez wrote:
| >Graphene has really caught my eye in the last several months,
| but unfortunately I couldn't find a good deal for Pixel phones
| (>128GB storage), used or new. [...] I just finally switched
| from an S10E to a S25Ultra (black friday deal brought down to
| $820),
|
| There are plenty of deals for pixels under $820:
| https://slickdeals.net/search?q=pixel&searcharea=deals&searc...
| morserer wrote:
| Goodness, friend, where were you looking?
|
| A used 256GB Pixel 8 in good condition is $320.
| https://swappa.com/listings/google-pixel-8?carrier=unlocked&...
| whitepoplar wrote:
| One caveat--you have to be certain that you get a Pixel with
| an unlocked bootloader. There are a lot of Pixels (mostly
| sold by Verizon) that are unlocked for use with any carrier,
| but whose bootloaders remain locked. If you have one of these
| ex-Verizon phones, there is no way as of now to unlock the
| bootloader.
| sgt wrote:
| Samsung Androids are not safe? Big surprise there! /s
| jimjimwii wrote:
| Given what they choose to ship with their phones in some
| regions, id say that Samsung absolutely doesn't care about the
| security of their customers of they can get away with it.
| mrbluecoat wrote:
| GrapheneOS goes even further by allowing you to opt in to pre-
| embargo security releases, bypassing the vulnerable window
| between vendor disclosure and OEM patches. Awesome!
| einpoklum wrote:
| ... maybe, but it also drops support pretty fast, and not
| supported on most phones :-(
| charcircuit wrote:
| It supports devices just as long as the OEM does, which for
| modern Pixels is now 7 years, which is more than what Apple
| advertises for the iPhone. Considering people upgrade phones
| every 2 or 3 years, this is over double the amount of time of
| support than one would use the phone for. I disagree the
| support is for a short period of time.
| immibis wrote:
| You can tell it's truly secure and private because the Cellebrite
| leak says they can't break it (one of very few!) and some
| governments assume you're a drug dealer if you use it. My next
| phone will run GrapheneOS.
| bnjms wrote:
| Does the Celebrite leak say out can break recent iOS?
| wepple wrote:
| Have a link to the source? And have they said they can't break
| it, or haven't yet? I'd imagine from a business perspective it
| would hardly be worth it
| holysoles wrote:
| There more sources if you google, but someone leaked a
| Cellebrite meeting.
|
| https://www.androidauthority.com/cellebrite-leak-google-
| pixe...
|
| https://arstechnica.com/gadgets/2025/10/leaker-reveals-
| which...
| raggi wrote:
| Understaffed gift product wants 1 week cycles.
|
| OEMs want 2-4 month cycles.
|
| This is a perfect representation of the state of the software
| industry.
| luca020400 wrote:
| I don't think that's a fair comparison.
|
| OEMs have quite a lot of extra steps before releasing any build
| to the public.
|
| They have to pass xTS, the set of test suites required before
| getting certified by Google, possibly carrier certification,
| regulatory requirements and more depending on where the build
| will be released.
|
| There are "quicker" release channels for security fixes, but I
| don't think it's common for OEMs to only ship those without any
| other change to the system.
|
| I don't think Graphene does anything of sort, they take what's
| already certified in the Pixel builds and uses it. Not like
| they could do much aside testing on the public part of xTS.
| yaro330 wrote:
| Yep. And GrapheneOS's changes to the kernels of devices they
| ship are laughably small, 20-30 commits at most. I don't
| think they even do any basic CVE checks on any of the source
| code.
|
| Fuzzing, actual security analysis - all those things are done
| by Google.
| raggi wrote:
| > I don't think that's a fair comparison.
|
| Fair?
|
| > OEMs have quite a lot of extra steps before releasing any
| build to the public.
|
| AIUI updates are less stringent and burdensome than initial
| certification. Regardless much of the process is automated.
| Graphene has CI too. 3PL's taking 4 weeks to run automated
| tests is also absurd. There are some "manual steps" to run
| CTS-V but they shouldn't be weeks level burdensome either.
| This is the point, this is an industry problem.
|
| The reason that the OEMs even have to deal with this 3PL test
| mess is for GMS certification, so again this is a policy
| decision that enforces a poor process. The bad properties of
| the process are not inherent to the problem space of
| validating builds against requirements. An industry problem.
|
| > There are "quicker" release channels for security fixes,
| but I don't think it's common for OEMs to only ship those
| without any other change to the system.
|
| Seems like a decision that is not user-centric.
|
| > I don't think Graphene does anything of sort, they take
| what's already certified in the Pixel builds and uses it. Not
| like they could do much aside testing on the public part of
| xTS.
|
| Private test suites for software are a toxic idea, it's in
| the same box as "SSO tax", and other such "pay for security"
| models. Given the software industry can't be trusted not to
| do this, I'm almost keen to see legislation to explicitly ban
| this practice.
| nunobrito wrote:
| Please be aware that every week there are bots pushing this
| distro up on the charts while blissfully forcing you to use
| hardware 100% produced by the same company (and government
| contractor) with a specific interest in undermining your privacy.
|
| There are ZERO valid reasons to use compromised hardware. Lest
| alone to use a distro with opaque financing sources that fully
| endorses government developed/sponsored platforms such as Signal
| and Tor.
|
| The downvote bots will arrive in heavy weight but will exist at
| least one voice exposing the honeypots tonight. Please consider
| saner options such as LineageOS or Replicant which support dozens
| and dozens of different device types.
|
| Don't fall for the trick of "it wasn't proven yet" when there is
| so much smoke and red flags. 3-letter agencies take pride in
| counting the decades until such tricks are exposed.
| OsrsNeedsf2P wrote:
| > Lest alone to use a distro with opaque financing sources that
| fully endorses government developed/sponsored platforms such as
| Signal and Tor.
|
| So you're against Signal, Tor, and Graphene, and suggest to
| instead use.. Lineage?
|
| Don't get me wrong, I love Lineage, it was my first custom ROM,
| but this seems a little tinfoil
| aniviacat wrote:
| Hacker News Guidelines [1]:
|
| > Please don't post insinuations about astroturfing, shilling,
| brigading, foreign agents, and the like. It degrades discussion
| and is usually mistaken. If you're worried about abuse, email
| hn@ycombinator.com and we'll look at the data.
|
| > Please don't comment about the voting on comments. It never
| does any good, and it makes boring reading.
|
| [1] https://news.ycombinator.com/newsguidelines.html
| p0w3n3d wrote:
| The problem with custom android ROM is that the kernel is built
| with proprietary drivers, and porting them to other custom
| android is really hard
| lima wrote:
| Great, so this means that the only way to get an Android release
| that's up-to-date on security patches is a binary-only distro -
| either Google Pixel, or the GrapheneOS preview channel.
|
| Just wonderful. Google should know better than this, shame on the
| other OEMs that forced this mess.
| t1234s wrote:
| I notice my battery life is much better switching to graphine
| from the stock google rom.
| hobberhaven wrote:
| So this is interesting, they release the patched binaries several
| months before anyone else does and several months before the
| source code of the patches is released?
|
| This implies that anyone can download GrapheneOS firmware images
| and use binary diffing techniques to find what are still 0-day
| vulnerabilities on every Android other than GrapheneOS.
|
| Useful! Thank you GrapheneOS developers.
| agentifysh wrote:
| which pixel model is best for grephene? I strongly prefer long
| battery life.
|
| will other phones be supported? why only pixel?
| mac-attack wrote:
| https://grapheneos.org/faq#recommended-devices
___________________________________________________________________
(page generated 2025-12-06 23:00 UTC)