> In the longer term, we plan to add support for RCS including support for the standard end-to-end encryption (E2EE) via Messaging Layer Security (MLS). Currently, RCS including E2EE is available on GrapheneOS via Google Messages. We want to avoid the need to use Google Messages for RCS eventually.
Hell yeah. Google Messages has worked reasonably well for RCS so far (after a long and frustrating period where it didn't on T-Mobile), but having a non-Google option will be huge.
They are really creating a lot of buzz recently. I love it, I hope they succeed beyond just us geeks here. It is imho imperative for a fair and balanced technological society that it retains the means for truly private and secure communications.
My devices help me think, and my thoughts are my own. That is a fundamental condition of human-hood. Sure we can change that, if that's what we want, but do we? If we do, do we make it a conscious choice per person? Or do we let big tech/corporatocracy dictate what it is to be human?
Ctrl+f clipboard, no results. What does "Secure Clipboard" in the title refer to?
The release seems to be only the SMS/RCS app, rest is future:
> We're also going to be overhauling or fully replacing the rest of the AOSP apps in the near future. AOSP Gallery is incredibly outdated and is being entirely replaced. AOSP Keyboard may be similar. We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
Our plan is to fork ReFra and drastically change it. We have a different scope and requirements for it. ReFra will still be useful for people who want features we don't plan to provide. We've considered trying to do it as an ongoing fork and making upstream contributions which we started on but it likely isn't practical. We haven't fully decided on this.
I hope they replace the AOSP keyboard with FUTO keyboard. I'm mostly fine with the other stock apps, but that keyboard was the one thing I absolutely had to end up replacing due to its jenky behavior.
AFAIK everything FUTO makes is open source? I haven't seen a counter-example (I have not looked hard though!), and https://futo.tech/about claims the following:
>All FUTO-funded projects are expected to be open source or develop a plan to eventually become so. No effort will ever be taken to hide from the people what their computers are doing, to limit how they use them, or to modify their behavior through their software.
>You may modify the software only for non-commercial purposes such as personal use for research, experiment, and testing for the benefit of public knowledge, personal study, private entertainment, hobby projects, amateur pursuits, or religious observance, all without any anticipated commercial application.
Violates clause 3 (Derived Works) and clause 6 (No Discrimination Against Fields of Endeavor) of the Open Source Definition [0].
>You may distribute the software or any part of its source code only if you do so free of charge for non-commercial purposes.
Violates clause 1 (Free Redistribution) and clause 6.
>Notwithstanding the above, you may not remove or obscure any functionality in the software related to payment to the Licensor in any copy you distribute to others.
Violates clause 3.
It is a "source available" license, not Open Source.
Thanks for sharing this! I spoke out of ignorance, having only considered the source code being available but not the licensing. (though I find narrowly defining "open source" to be rather pointless) I haven't tried every open-source Android keyboard, I've been very happy with FUTO Keyboard. Kinda too bad it's not compatible with being shipped with GrapheneOS, but it's also understandable why they'd license it this way.
Right, they are adhering to a definition of open that includes free as in liberty, so licensing matters. What good is it to read the source if I don’t have rights to modify and redistribute?
It is not open source. They use a custom source available license. There's no way any Android distribution would include it. A layman's reading is that FUTO could claim license violation on account of the distribution accepting donations (non-commercial use only) and there's a weird clause about not accusing FUTO of patent infringement.
curious: what are the advantages of futo vs leantype? i use the latter but never looked deep into it, it just seemed the easiest better than aosp thing on f-droid
I like Heliboard a lot, but its autocorrect gets stuck in the mud all the time.
It completely falls apart and starts injecting nonsense phrases made up of nonsense misspelled words moment you miss a space ('v' or 'b') or type a really long word it doesn't know.
It also stubbornly incorrects other things like 'a' into "and" if it thinks it knows a phrase fragment. It's always wrong. It just happened to me now twice. Above, "or type a" became "or type and". Also, "it's" became "IRS".
Heliboard would be perfect if it stuck to word-only spellcheck and never split words. Just now again, it tried correcting "heliboard" into "hellenized" and "he lib oars".
This is not a matter of just lowering how aggressive the spellcheck is. It will still generate slop every time. The only real option is to completely turn it off. Futo can have similar problems, but there are a lot more options to tweak and the defaults aren't so bad.
Unsure what you mean by link against it. GPLv3 requires making the entire project it is bundled with GPLv3 as well. GrapheneOS would need to relicense the entire OS and bundled apps as GPLv3 to allow them to use any app with that license.
Go read the GPLv3 license and/or ask yourself how Linux distributions are able to ship a mix of GPLv3, v2, MIT, BSD, etc licensed software all in the same image.
GrapheneOS may or may not have a policy against shipping GPLv3 software (I don't know), but if they do, it's a political or business decision, not a restriction imposed by GPLv3.
As someone who uses and loves Unexpected Keyboard: the higher learning curve compared to other keyboards would be the main reason I can think of. The reliance on swipes in particular is something that's likely alien to a lot of smartphone users.
I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.
The latest FUTO works just as well as Gboard for me. Their somewhat recent update to their swiping library really changed the game, and their voice recognition is also pretty decent.
It seems like work on voice recognition has halted entirely though. On https://keyboard.futo.tech/voice-input-models , community models and other models have been "coming soon" forever, and in the end the only model they offer is whisper-small, a very basic model from 2022. Which in AI is like prehistory.
Google can shuttle network requests to any of their other apps (or play services, if that's running) via IPC, even with the network permission disabled in Gboard.
So if you're using Graphene for privacy from Google specifically, it's not safe to install things like Gboard even with the network permission disabled. Even if they don't use IPC in this way today, there's no telling what the Google-of-tomorrow will do.
there's no telling what the Google-of-tomorrow will do.
This is true and even vastly understated. Google is like the Walter White of companies. Starts out innocent, turned into a monster, everyone around him astonished at the dark, depraved change.
So if one thinks "nah, Google wouldn't do that", I have a bridge to sell you...
fyi disabling network permission doesn't protect against deliberate and coordinated data exfiltration. Apps can still communicate with other apps, for example with Google Play Services or any other app.
I wish Futo had the ability to use a typing heat map for more accurate predictions like SwiftKey. It constantly suggests "AMD" when I am trying to type "and". I have fat thumbs OK! I don't even have the caps on and I RARELY talk about AMD. It's just the one thing I miss. I do find the predictions generally less accurate as well, but perfectly usable.
Probably never happening in the next millennium. GrapheneOS has a gripe against FUTO because it is tied to Louis Rossmann, which dared to challenge GrapheneOS's social skills in the past.
Default apps in GrapheneOS are really outdated. Especially "Gallery" where on standard "compact" device top navbar is still too small and requires very precise touch. Hopefully, little by little, all stock applications will be updated to more modern variants. I personally had plans to build some open source stock Android applications, but after whole nonsense with platform being locked down I do not see the point in investing my time, just for google to block my apps.
> I personally had plans to build some open source stock Android applications, but after whole nonsense with platform being locked down I do not see the point in investing my time, just for google to block my apps.
It doesn't apply to GrapheneOS users and it doesn't affect developers who have apps on the play store. You should do it! Many users on stock android who would install apps not from the play store will have gone through the 24 hours or used ADB.
"RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported."
Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt Jive?
The rcs part doesn’t make sense at all, it’s a google messaging standard. How do you do rcs without Google approval esp for things like business messaging it has to go to Google for approval eventually.
Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing.
Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.
GrapheneOS does include GPLv2 code both via AOSP and our own but not GPLv3. We want GrapheneOS to have no additional restrictions beyond AOSP. AOSP uses GPLv2 but not GPLv3.
We do need to be careful with GPLv2 due to license incompatibilities. For example, GPLv2-only licensing such as the Linux kernel is incompatible with Apache 2 and GPLv3. GPLv3 is compatible with Apache 2 so GPLv2-or-later can be compatible but only by using it as GPLv3 with the extra restrictions too.
It seems like you have more freedom than you think you do. See this comment <https://news.ycombinator.com/item?id=49594824> Packaging software shouldn't change the license of GOS as such. If you haven't had already, maybe the free software foundation could provide you with assurance?
I guess it will make your life much easier if you wouldn't have to restrict yourself that much.
No, we're not talking about packaging software in our app repository (App Store) but rather software being included in GrapheneOS. If any GPLv3 software is included in GrapheneOS then that places more restrictions on how it can be used as a whole.
I think you are confused. You can have a Linux distribution with software with incompatible licenses (e.g. GPLv2 and Apache License version 2), because the license for a particular program or library only applies to that specific work, not other works that it is distributed with. The GPL is very clear on this:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
There are some cases where a separate work can be considered derivative and thus the GPL can apply. E.g. I think it is generally accepted that a program linked statically against a GPL library is considered a derivative work (and must thus must have a license compatible with the GPL). More controversial is whether dynamic linking creates a derivative work. To cover the latter case, a lot of copyleft libraries are licensed under the LGPL or the GPL with a dynamic linking exception.
At any rate, shipping a Linux distribution with GPLv2 code (e.g. the Linux kernel) and a GUI application that is under the Apache v2 license is not a problem at all (as long as the GUI application is not a derivative of a GPLv2 work).
GPLv2 and Apache 2.0 are not incompatible licenses when bundled together. GPLv3 is the problematic license as it requires all code it is bundled with be GPLv3 as well.
When it comes to AOSP/GOS, bundled apps are not aggregated together, they are built and signed under a singular OS binary.
OS components don't need to have compatible licenses if they're separate from each other. The Linux kernel is GPLv2-only which forbids GPLv3 licensing. That doesn't mean GPLv3 code can't be used in a Linux-based OS.
We use GPLv2 and permissive licensing for GrapheneOS to avoid more restrictive licensing than the AOSP. We'll happily use GPLv3 and AGPLv3 for components outside of GrapheneOS if we think it's the best fit for specific projects. We aren't currently licensing anything as GPLv3/AGPLv3 but we aren't strictly opposed to it outside of the OS.
We'll use what we think are the best open source licenses for what we want to achieve. What we want to achieve is usually broad adoption of our code with painless usage of it. That means we usually choose permissive licenses. We use GPLv2 in certain cases such as Vanadium where we decided we wanted extensions to our code to be under a compatible open source license instead of a source available license or GPLv3.
The Refra gallery fork would replace the current ancient gallery app. That would be bundled with the OS. Doing the same with the fossify suite or similar would be illegal. These licenses do not treat apps or libraries differently. GPLv3 code forces the code that it is bundled with to also be GPLv3.
It does make a difference. GrapheneOS includes a lot of GPLv2 code from AOSP and we choose it as a license for several of own projects within GrapheneOS.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
If you'd include a GPLv3 gallery app in, say, a mobile OS, it does not mean that the rest of the OS has to be under the GPLv3. It merely means that you cannot limit the user's right when it comes to the GPLv3-part (the gallery app). They would still be allowed to redistribute/modify it and you have to provide the source code on request.
You only have to make other code GPLv3 if you somehow create a derivative work (e.g. linking against a GPLv3 library).
The issue isn't that GPLv3 applies to non-derivative OS components but rather that the terms apply to the overall redistribution of the OS. Including any GPLv3 component means GrapheneOS cannot be used in products where AOSP can be used due to having additional restrictions beyond GPLv2. We don't want more restrictive licensing than AOSP. We're fine with using additional GPLv2 code as long as we're sure it's not going to move to GPLv3 or that if it does we're prepared to maintain it ourselves.
Yes, AOSP includes a lot of GPLv2 code and we use GPLv2 licensing ourselves including for our Vanadium browser project. We don't want GrapheneOS to be more restrictively licensed than the Linux kernel and AOSP so we avoid GPLv3 code bundled with the OS. GPLv3 is perfectly acceptable for apps in our App Store but we don't want it for the ones in the OS.
We're going to be forking one of them (ReFra). We want to make extensive changes and have a different vision for it than the upstream project. For example, we don't want it to have integration into services. There's plenty of room for both an increasingly different fork of it in GrapheneOS and the original project which our users will continue to use who want features we don't consider inside the scope of what we want from a local gallery app.
> RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported.
What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Google. I wouldn't hate it if GrapheneOS would totally ignore RCS. I fail to see any value in it, but maybe I am lacking information(?)
Perhaps it's different in other countries, but I've never seen anyone use MMS. (Everyone uses WhatsApp nowadays, but even before WhatsApp existed, I never saw anyone use MMS.)
I've seen people try, only for it to never actually work (images either compress horribly, to the point there's no reason even sending it, or just fail to send).
MMS bring broken since day 1 in my experience is probably the reason I jumped on internet chat and email, since those actually work as advertised (sure, they has some practical limits, but they tell you about those!). I probably would have sent my mum that image over MMS if MMS actually every worked. Since it never did, using a difference service was a must.
Then again, this feels like an extension of the rest of the phone system. Anything beyond calls between two people, SMS and data that involves connecting to the phone system has always (in my experience) been either janky or broken. No wonder I try to use anything else given the opportunity.
It depends heavily on country, yes. USA is extremely light on WhatsApp, and MMS use is widespread (and has been free for a long time now, and SMS even longer). RCS is a mostly silent upgrade for USA.
I'm not sure which of the two is better tbh. Utterly dominated by a Facebook-owned system, or using something that's crappy enough that people spread out to a variety of systems?
The huge switch from SMS to WhatsApp in Europe was well done before they were acquired by Facebook. By then the damage was already done, because the network effects made it very hard to move away. By now, many people I know also have a Signal account, but it doesn't really get off the ground as long as, say, 30% of every group chat does not use Signal.
Year, back prior to the Zuckification I'd say it was a very clear upgrade for everyone in essentially every way. Dirt cheap (much less than even minimal texting), installable everywhere, adopted solid E2EE far ahead of basically every major player (2016!), it was great. USA had everything worse for a long time, and many things still are.
But once it landed in Zuck's hands, I no longer trust it one bit. Abandon ship.
RCS provides far better support for group chats, many small feature improvements and end-to-end encryption (E2EE) via Messaging Layer Security (MLS). E2EE for talking to GMS Android and iOS users without them needing to install another app is the main reason we care about it, but far better group chat support matters too. iPhone users very often don't want to have SMS/MMS users in their group chats.
This is a very US-centric (and maybe Canada) thing though? Most of the rest of the world doesn't really use or care about iMessage, even on iPhones. So, I think it's rather
-US- iPhone users very often don't want to have SMS/MMS users in their group chats.
The rest of the world is using WhatsApp, WeChat, Telegram, Snapchat, LINE, etc. for group chats (for better or worse), even on iPhone.
> This is a very US-centric (and maybe Canada) thing though?
If what you say about “the rest of the world” using other messaging apps is true, then yeah, it probably is North America–centric. So what? Are you agreeing with the OP who didn’t see any point and advocated that GrapheneOS “totally ignore RCS”?
GrapheneOS already supports WhatsApp, WeChat, Telegram, Snapchat, and LINE. What’s wrong with improving OS support for another widely used alternative, that for all its faults is mostly better than still another widely used alternative (SMS/MMS)?
There’s a thread on the GrapheneOS forum titled “Using RCS with Google Messages on GrapheneOS” with 2,192 posts in it. Clearly there’s a lot of interest in using RCS on GrapheneOS!
Are you agreeing with the OP who didn’t see any point and advocated that GrapheneOS “totally ignore RCS”
No. I think it is useful for GrapheneOS to work on this, the US is a substantial user base.
The comment I reacted to:
iPhone users very often don't want to have SMS/MMS users in their group chats.
I think it is useful to qualify that, because a lot of people from the US are under all kinds of false beliefs like: green bubble anxiety is universal, Pixel 10 and Pixel 10 Pro do not support physical SIMs (Pixels support physical SIM in other regions), etc. (I could go on for a while.)
These misunderstandings repeatedly show up over and over again and discussions, so I think it is worth being specific. In this case most iPhone users worldwide do not even think about SMS/MMS users in their chat, because they do not even rely on iMessage as their primary messaging app.
All carriers I've tried in my country have even disabled MMS entirely. They're not running RCS servers either, though, everyone is on WhatsApp anyway.
In theory carriers could increase the max resolution for MMS now that 3G is essentially dead, but I doubt they will now the slow move to RCS has started.
From [0], it seems that RCS can use the cellular signal instead of LTE or 5G:
> In cases where RCS is able to operate over cellular networks without data, it supports messaging as well as file transfer, enriched calling, and more.
In LTE and 5G there exists no cellular signal without data. That was a 2G/3G thing. Since 4G everything is data. The separate sms and voice services are gone. And 3G is rapidly being deprecated.
That's not quite true. VoLTE was an optional part of 4G in the beginning. I had one of the gaming ASUS phones that shipped with 4G, but no VoLTE. 6 months after getting it, the US phone carriers conspired to make VoLTE mandatory for connecting to their towers, effectively bricking my device. ASUS never issued the firmware update that would have enabled the feature in the modem, which had the capability, and the community hack to enable it never worked for me.
Yes, circuit switched fallback was possible for a time (LTE data and circuit-switched 2G or 3G voice). I think 3GPP shouldn't have written that into the spec in the first place, but you know what they say about hindsight....
It was an optional part but without VoLTE you just could not call with 4G. For that the phone just switched back to 2G/3G.
That's not a sustainable solution because 2G/3G are getting switched off. And it doesn't really have any bearing on LTe itself.
The real issue is that they didn't really standardise VoLTE enough. Leaving every carrier and manufacturer to have a mesh of different options and not every carrier and every phone supports the exact same subset of options, which causes the compatibility issue. Also sometimes providers don't bother checking phones they don't sell.
They really should have standardised it 100% so this couldn't happen.
It's true that it's all packet-switched rather than circuit-switched, but IMS traffic is still handled differently than regular data traffic. (The most user-visible implication of this is the QCI difference: cellular phone calls are much more reliable at poor signal strength and high congestion than over-the-top VoIP calls).
The point of the exercise is for Google and Apple to maintain control over the ecosystem.
RCS is technically superior (protocol, transport, security, all of it) but is captured from the start on the technical level by design by the big players. From the perspective of the vast majority of users who have very limited technical awareness, it was silently slipped in as an upgrade at one point or another. This means that those not adopting the proprietary BigTech solution are perceived as being difficult by insisting on using software that's now perceived as outdated or as otherwise mildly incompatible.
GrapheneOS does not want to adopt RCS for public perception. It is still a better option than SMS/MMS and providing it is beneficial. GrapheneOS will still recommend using better platforms and protocols but RCS being bundled and cross platform are great reasons to implement it.
Suppose GrapheneOS becomes highly popular. Then I have to fight the average Joe who insists RCS is fine enough.
I understood from other comments that RCS is the default communication channel in N.America an I can sort of see why you want to give people a somewhat less worse option here than Google's Messenger. But RCS should not be the default imho, because lazy people gonna be lazy. So I hereby endorse you to gently push newcomers towards a safe and privacy friendly default by pre-installing Signal or whatever meets the bar and give it a prominent place.
Whether or not you tolerate using RCS is up to you. Not supporting it for the sake of having a worse default option on the off-chance you can use the to convince them to use a better option is not a good reason to not support RCS.
Either you will have people content with SMS, or you will have people content with RCS. Which is better is obvious.
I am not on the GrapheneOS team but the community does push better options such as Molly/Signal and RCS is usually only advised as a fallback messenger.
Eh, I don’t think you have to include Apple here. If it were up to them, the iPhone would still have zero RCS support right now. The current implementation of RCS, even in iOS 27 beta, is clunky.
To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
> To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
Yes, exactly. Apple and Google are both acting to maintain control and this has resulted in a standard that improves functionality but is effectively poisoned at the technical level. Left to their own devices I'm sure Apple would have preferred to stay with their original solution that is even more closed off.
RCS was DOA from day one as far as I'm concerned. The carriers being involved in any capacity deeper than providing dumb pipes alone was enough to make it pointless, but no E2E in the base spec makes it extra pointless. They may as well have just extended SMS to be more capable, because that's what they've effectively created.
It has it in its current documentation (maybe 3.0 too? I forget, but it's new this year), and Apple and Google have had messages to themselves encrypted for a while (but not to each other, which is what the RCS docs are intended to resolve). It took many years to get it documented though (despite loudly claiming RCS is more secure the whole time), and AFAIK none yet implement it. Definitely none with all the documented things it needs to show to be compliant with the spec I read, e.g. key verification - I certainly don't see any of that in Google's "Messages" app! Though hopefully that will all change.
But honestly, in a non-open ecosystem, can you really trust that the near-exclusive two major players are actually playing by the rules? Apple has been relatively protective of its users on privacy stuff, but I've lost all trust in Google at this point.
> key verification - I certainly don't see any of that in Google's "Messages" app!
I do! I have a old-ish but up-to-date and stock Pixel phone, and I see (what appears to be) full E2EE with several text contacts in Messages, with ability to verify keys (which admittedly I have not attempted to use yet). It only works if both devices / all of the devices in a group are fully compatible with the version that adds encryption or newer, but when they do, it just starts working automatically and transparently. AFAIK, that's primarily thanks to Google's work.
I think what we've learned from the rise and fate of current alternative messaging apps and services is that, if we actually want to get the majority of the world's population on modern-quality E2EE for all of their communication, it's going to have to be done gradually and transparently through the apps they already use. Getting everyone to switch to a different app is a pipe-dream that will never happen, at least not thanks to the work of any particular person or company.
Apple is pretty good at privacy and security for people playing within their ecosystem. They seem rather indifferent to any attempts to communicate or interact with anybody without an Apple device. Better than nothing, but not great IMO. Google has many faults in many areas, but I think they're doing awesome work at a difficult and thankless job as far as developing a standard for modern and fully encrypted communications that is actually possible for everyone to switch to transparently, and dragging everyone kicking and screaming into actually using it. Apple just rolled out support for it in beta 4 months ago. Very likely in the next year or so, we may see the majority of texts and group-chats between Android and iOS be actually E2EE without the users needing to do anything besides ordinary OS updates. That will be IMO 80% Google's doing, and 20% Apple's.
Yes but there are different specs that “compatible” apps will have to adhere to, basically until everyone is always running auto updating software to the latest version supporting RCS 4.0
Long story short somebody preferred to “ship it” instead of waiting to figure out how to make encryption compatible between iOS and Android. I guess there’s some differences in how the key rings work, but Signal can figure it out and /they’re/ open source so it sucks they ever supported unencrypted messages. They just wanted to say it technically worked for rich text messages and reactions.
I don't know much about RCS other than that carriers need to be involved, but there's a way to not involve them, which Google did for a while using some kind of compat-service (jibe or something?), and then they stopped doing it.
Never seen RCS working on any carrier ever since. I don't understand why Google couldn't just continue doing what it was doing. Why require carriers?
The intended purpose of RCS was to be federated between carriers, just like SMS. If you centralise it then it's just a worse version of any of Google's abandoned chat apps. But there's a realpolitik reason to insist on centralised RCS: because it's already got the reputation of decentralisation, it makes it look like Google is better than it actually is.
Did SMS fail? Sort of, as it's rarely used, but also not, because it continues to work and it's still the only federated messaging system you can rely on being available on your phone (besides phone calls).
SMS was a huge success. For a standard that was defined in 1986 and first rolled out in 1992, it had good longevity and was extremely popular from its introduction until ~2010 [1]. Nearly 20 years is a good run for a technology in a rapidly evolving field. It was also designed in a completely different age when most phones did not have cellular internet and carrier support and federation were the only way to provide reliable person-to-person messaging. Even though the carriers probably dream of reviving SMS as RCS to be more than just pipes for the internet, those days are over.
Google-based RCS is Google coopting an existing standard to get the foot in the door for Apple Messages interoperability. By coopting a standard (rather than pushing yet another Google messenger), they could convince regulators to push Apple towards supporting it. Otherwise RCS is completely irrelevant and if it weren't for Google, it would've been mostly dead.
[1] Yeah, I realize that is was probably used in the US much longer, but that's when it started to dwindle in the rest of the world, where MMS also never really took off.
RCS is an extension of SMS and has quite literally been "SMS but more capable" from the start. The protocol on the wire looks a lot like MMS over LTE. Registration and communication mostly happens over SIP and RTP like in the latest MMS specs.
The early versions of RCS were barely implemented. Android and iOS didn't bother including clients, carriers didn't bother hosting servers because the spec was optional, and third party applications made by carriers were launched and then died because carriers couldn't explain to customers why their app was better than WhatsApp e.a. for those in the market for alternative messengers.
I think it's safe to say that RCS would've died a quiet death had Google not used it as a basis for their own Hangouts alternative built into their SMS client.
When RCS was first (soft) launched back in 2008, E2EE messaging practically didn't exist. Google slapped E2EE on top when they hosted their own iMessage alternative to bring it into the modern era but the base spec was still "what if MMS wasn't so outdated and restricted".
Agreed. Google used a standard that virtually nobody (except some carriers) cared about to get a foot in the door for better interoperability with iPhones, to try to solve an issue that is mostly US-only (green bubble anxiety),
In most of the rest of the world nobody gives a shit about RCS since we have adopted other messengers (than iMessage or SMS/MMS) ages ago, most of which are already end-to-end encrypted.
I understand why GrapheneOS has to spend time on this (the US is a large user base), but it's sad nonetheless.
The point is to access an e2ee protocol bundled by default on many devices, and is cross-platform.
GrapheneOS does recommend using superior platforms like Signal, but that is 3rd party, and thus has adoptability issues in convincing people to use it. Just because better platforms exist does not mean RCS should be ignored.
Thanks for clarification. Anything first party from Big Tech is a lost cause privacy wise. At the same time, nobody uses it (maybe that is different in the USA, don't know). So for me this would be ultra-low prio as I (and I expect almost every other GOS user) will never use it. But I believe GOS knows what it is doing.
In the US everyone with an iphone uses RCS, so you'll often have family group conversations on it and so on. Whatsapp or signal are comparatively rare (although more common for anyone with overseas family naturally)
No, in the US, everyone with an iphone uses imessage. (Basically all my family's messaging goes over imessage) It's only when non-iphone users are on the chat that RCS comes into play.
Nearly everybody uses it in the USA. It's very common to text people through the default messaging app on your phone there (probably an outgrowth of the popularity of iPhones and iMessage), and backup options would be Instagram, Snapchat for a certain demographic, or Facebook messages. Whatsapp is only for messaging foreigners, and Signal/Telegram are for messaging your drug dealer.
Yep, I have never used anything other than the stock messaging app that came with the phone. Whether that's SMS, iMessage, or whatever has never crossed my mind
I was really disappointed when Signal went away from being used as an "everything" messenger, including regular SMS. I onboarded all my family and now because it's not a default messenger, nobody is using it.
Give them 2 channels, be clear about your terms of service and that your intent is to become exclusively available on Signal after one year:
- Signal. high priority channel, checked daily
- $PrivacyHazardApp. low prio, checked with steadily increasing intervals.
Make sure you communicate those intervals in advance, have them in the footer of every message you sent on $PrivacyHazardApp. Average Joe needs lots of patience and lots of education.
TIL. My deepest condolences. I thought that we, from this side of the pond, were upholding the honor of being the dumbest with our Whatsapp subjugation, but alas.
I assume many people would use it due to SMS concerns and difficulty having people move to other platforms. I would personally use it as a fallback to Signal since my current fallback is SMS, which I dont like.
If the protocol is properly e2ee, it does not matter who backs it or hosts it. GrapheneOS would be in control of the client which is what matters in an e2ee system.
GrapheneOS would be in control of the client which is what matters in an e2ee system.
Not really... You will be communicating with other people who don't use GrapheneOS and if you are e.g. communicating with iPhone users who have iCloud backups enabled (most iPhone users) and did not opt in to ADP (against most iPhone users), the chats are only encrypted at-rest in the iCloud backups and are accessible by Apple and law enforcement.
Signal is way better because it opts out iCloud backups (and Android backups) in favor of truly end-to-end encrypted backups.
RCS's point is to deliver ads. It is its first purpose.
The way I see the situation, the point for Graphene to implement RCS is to prepare for the foreseeable deprecation of SMS. Who knows when it will happen, but better start working now than wait and get stranded when it'll happen. I'm pretty sure RCS implementation will take a long while.
I believe it was meant to be federated, like SMS, and then in practice it wasn't. With Signal you depend on your carrier and on Signal - with SMS you only depend on your carrier.
Certainly, with Opus 5 and GPT-6, modernizing or even completely rewriting self-contained, non-critical tools seems like a Friday afternoon job now. I wonder however how important this is, in the grand scheme of things. I use GrapheneOS and the bundled messaging app is serviceable. It isn't pretty, but it gets the job done.
Our code quality standards are very high. Vibe coding is not capable of meeting those standards. The details of how things get written and improved to meet our standards is up to individual developers. We don't have a policy against developers using AI for assistance. They need to understand all of the code and it needs to pass our code review. Our code review is now usually a lot more thorough than before. In addition to human review, we regularly pass code through a couple frontier AI models and then review the results to figure out which claims it makes are valid. Even the frontier models hallucinate many non-existent problems and often get a lot of details wrong when they find real problems, but they do find a lot of real problems.
Our port of Messaging to Compose was clearly not vibe coded as both the parent comment and yours are wrongly portraying it. Experienced developers have been working on overhauling the app for months with a lot of back and forth code review to get the pull requests into shape. We don't have a policy against using AI for assistance as long as the resulting code meets our high standards.
We definitely use frontier AI models with cybersecurity access unlocked for code review. Those often find problems we didn't catch via multiple rounds of human review. The output is filled with hallucinations and incorrect details but an experienced developer can sift through it, identify the real issues it uncovered and get those fixed.
I appreciate all the hard work the Graphene team has done all these years with advancing alternative mobile OS and have been following them for years so I hope they don’t take this the wrong way -
The project would benefit from more polished, professional image/interactions with the community. I (personally) have a hard time trusting my data to a project that is constantly bickering (“no, we don’t vibecode, did you even look at the repo”) in public forums like this under the official letterhead account.
I’d love to see y’all discussing these types of technical details with individual, identifiable (even under fixed pseudonyms if you want) developers’ accounts, and leaving the official letterhead account to stick to posting marketing material.
We're definitely not churning out code with AI models. There's no vibe coding going on in GrapheneOS. We're carefully writing and reviewing code as we've always done. We now have additional tools to assist with it. The main way we're using AI models is for code review and helping to write a lot more tests than we used to. It's helping to improve our code quality, not reducing it. We're not trying to get things done substantially faster.
The code generated by even the bleeding edge publicly available frontier models is rarely good enough to meet our standards. AI models are creating a lot of additional work for us because of how many more security issues are being discovered in upstream projects. It's also helping us raise our standards for our own work by pointing it at that to get extremely pedantic criticism catching many things we would miss.
We've hired multiple experienced app developers who have spent months working on modernizing the Messaging app and carefully reviewing it. There's no vibe coding going on for our apps. Why not look at the actual process of porting Messaging to Compose and our code review for each incremental part of the process?
“We'll be making a new release later today with a completely overhauled user interface written in ‹whatever›” is something developers love, and users fear.
Saying it's going to be released later today means to the Alpha channel. GrapheneOS and each of our apps have Alpha, Beta and Stable channels. Every Stable channel release made it through Alpha and Beta channel testing. We don't expect the initial Messaging app release to reach the Stable channel. AOSP Messaging hasn't been actively developed since around Android 5.x and nearly no one is going to be unhappy with the changes.
We're changing very little about the overall layout and structure of the app in this initial phase of the overhaul. Over the past couple months, it was carefully ported to Compose with a lot of code review and added tests. It was a lot of work and is going to look a lot more modern. It's also now possible to greatly improve the user interface in much more substantial ways than making it look modern.
If you have used GrapheneOS, you know Messaging is positively ancient and bitrotting. The overhaul makes it look like the rest of the OS and uses standard material 3. Its not something to fear.
Indeed. I don't use most of the stock AOSP apps on Graphene because the UI is so awful, but there are decent alternatives so it hasn't been a bother. I'm looking forward to seeing their work.
I don't really get why so many Americans want RCS to succeed though. Do you guys not remember when carriers charged 10p/text? Why on earth would you want to give any power at all back to those people?
It makes group messaging work a lot better, too. Previously, group chats with a mixture of ios and android users were really buggy leading to iPhone users significantly preferring group chats with all ios, which led to some social exclusion for android users in the US, leading to market dominance for iPhones. Now, with RCS, you can make a functional group chat across platforms and you don't have to convince anybody to install something new.
That's one of the reasons we care about it for GrapheneOS. It also provides end-to-end encryption between Android and iOS via Messaging Layer Security (MLS) which is clearly very important for us. GrapheneOS users needing to use Google Messages to get E2EE with Google Messages and iOS users who haven't been convinced to use Signal instead is not ideal. We do have Google Messages working via sandboxed Google Play but want to replace it.
RCS provides properly working group chats and end-to-end encryption with iOS and GMS Android users without having to succeed at convincing people to use Signal instead.
After getting several family group chats finally converted over to RCS, one day my phone just started absolutely refusing to verify my connection to the RCS servers. Instead of any kind of notification, I was just silently not sending or receiving messages for nearly an entire day. I had to disable RCS on my phone, which created a several day long issue where some chats would just fall back to SMS and others absolutely refused to work, or strange interactions with Apple devices where certain messages would not be displayed. After enough trouble with it I convinced everyone to switch to a third party messaging app. I'll never turn RCS on again, I can't trust that it won't just start silently failing.
Text messages in iMessage or SMS are a fairly US-centric relic.
That's not to say overseas is better - Europe depends on Whatsapp - but outside the US the whole 'blue box' thing isn't even a thing.
The main benefit of RCS is the fact it is available by default on other platforms like certified android and IOS. 3rd party messaging apps hit adoptability issues. A bundled, cross platform E2EE protocol is a huge step above SMS and MMS.
Americans have had unlimited texting plans for much longer than Europeans. I'm pretty sure most Americans had unlimited texts before Whatsapp existed, so there was never the move to it for economic reasons.
Yes I think this is the main reason for WhatsApp's popularity in Europe. Our providers were hanging on to sms as a cash cow and they were pretty much the most expensive bits you could send.
Malicious providers like kpn in the Netherlands even sought to charge extra for WhatsApp traffic because they lost so much revenue. However the EU shot that down hard under net neutrality.
But I remember it well and this is why I always disable RCS. I don't ever want to give my provider the chance to do that again. And I don't trust Google either. SMS is completely dead here too. It's been years since anyone sent me a personal message. It's just spam and poorly implemented 2FA shit.
It's not an issue here in Spain anyway. The only phone with iPhones are rich expats. Most of the people I know use cheap budget androids.
We spent months working on this and certainly didn't vibe code it. We do use LLMs but primarily for code review and boilerplate. We're now including a lot more tests partly thanks to it being less of a pain.
Our quality standards are too high for current frontier LLMs to generate much we could use directly. On the other hand, their code review output is extremely useful. It can find many issues we wouldn't catch even with multiple rounds of human review. It's helping us a lot with catching issues we've repeatedly overlooked.
Yeah, I know you guys are using LLMs responsibly. I just found those anti-LLM crusaders funny they way they were calling it an unethical and fascist technology.
As long as the code is being held to the same standards (which have been very high), it's only going to help the developers.
Btw, please save yourself some energy and mental peace by ignoring these people who haven't written a single line of serious code and are only there for bandwagoning and pushing their political agendas. Love the work that you guys do that's why I'd love for you guys to be able to focus on the mission and not get distracted by them. Thanks for all the hard work!
Maybe they'll work on the backup now, this *** seedvault is worse than nothing (consistently broken on both my GOS phones, never giving the same results with 2 backups, never giving out as much as the status I could trust)
Yes RCS is a pig with lipstick. Invented by the carriers to recoup some control over instant messaging, then abandoned and picked up by Google for the same reason. They're the ones that added encryption to it.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
RCS is important because it provides end-to-end encryption (E2EE) for contacts with Google Messages and iOS. That means having E2EE for the vast majority of smartphone users since Google Messages is the standard GMS Android carrier-based messaging app.
It's important for us to provide out-of-the-box end-to-end encrypted (E2EE) messaging for contacts on Google Messages and iOS. Both Google Messages and iOS provide RCS with end-to-end encryption via Messaging Layer Security (MLS). Google Messages is the standard text messaging app on Google Mobile Services Android and iOS now also supports RCS with MLS. The vast majority of people have an E2EE messaging app on their smartphone and it's important for us to provide compatibility with it. Currently, a growing number of our users are installing Google Messages to have better usability and privacy for texting with contacts on Google Messages and iOS.
People can already install the messaging apps of their choice on GrapheneOS. It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide. We need a messaging app to handle carrier-based messaging in the OS including providing end-to-end encryption for it and the rest is up to other open source developers.
It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide.
I disagree with this somewhat. Apple and Google make these sweeping decisions for their users and in effect promote one tech over another. Adopting RCS and integrating it natively, but shunning open protocols and leaving them for third party apps (with probably worse OS integration) means you are following, not leading.
I would at least consider shifting approaches somewhere down the line. Yes, there are a plethora of open messaging protocols out there, but adopting one for first party integration doesn't prevent the others from being used.
I agree. The OS maker has a ton of power with the default apps and putting SMS and phone calls as the default communication platform of the OS is contrary to the goals of giving people more privacy.
And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
> And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
This makes no sense especially when you’re comparing it against Apple Pay and Google Wallet. They shouldn’t waste resources on something so pointless. The only exception is if they can actually make an NFC capable app that can handle cards.
RCS is a modern replacement for SMS/MMS with end-to-end encryption (E2EE) support via MLS. We have SMS/MMS so we need RCS to replace those. Similarly, carrier-based calls are there and should get replaced with a newer standard with E2EE.
RCS is what GMS Android and iOS provide so that's what people need to talk to non-GrapheneOS users.
Which non-carrier-based messaging app or protocol do you think we should include and why? What happens if we decide that's no longer the best one wand want to get rid of it? Apps included in the OS cannot be easily removed but rather only disabled by default for new installs and phased out for new devices. Otherwise, users would have their working setup break.
Yes I understand your point re: interoperability, and I think you've made a convincing case for RCS.
I think in the short term, you should take a look at e.g. Cheogram, Conversations, and Element and consider ways to enhance integration. Address book integration, automatically extending contact do not disturb exceptions, and maybe even dialer integration.
In the long term, it would be best to try to guage antitrust regulator attitudes wrt to protocols like XMPP and Matrix. In the end, they are the only ones who can really force mass adoption of an open protocol. But alternative OSs having native support and integration for such messaging protocols can tip the scales and be used as evidence of the protocol's viability and legitimacy.
Unless one wants interoperability with other people who use Apple and "Samsung" (because they don't know the word Android refers to an OS). It's a de facto standard now, whether you like it or not.
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.
I mean we privacy nerds all love webapps but the reality is the people actually in charge of S&P500 companies hate them. They really, REALLY want to fingerprint your device and use it as a verification and tracking mechanism.
Until that changes, webapps aren't going to sell.
Even Google tried multiple things to "sell" the idea of webapps (e.g. Polymer project) in 2011-2015 and failed.
Funny enough, Wechat kinda succeeded at webapps in China because there's a strong user preference to stay inside one monolithic "everything app".
I find, as a user primarily of free and open source software, it’s really the opposite: native FOSS apps have minimal tracking and analytics that defaults to off or is easily disabled, while most free and open source webapps are behind Cloudflare, blocking access to them until I turn off my VPN and disable the anti‐fingerprinting features in my browser.
I don't want to see more groundwork for web apps. GrapheneOS is meant to be secure, which means running trusted apps on-device. My messages are less secure if they permanently are stored on a server.
Yes, but there is no alternative other than giving up. Starting a new OS from scratch with zero apps is a much worse starting point compared to a platform where 99.9% of apps work (minus those relying on Play Integrity with strong integrity) which may have its rug pulled in the future. The race here is about getting to a big enough market share that GrapheneOS cannot just be ignored as completely niche but has to be treated as a small but not insignificant minority.
It's not ideal, but in the case a hard fork happens, they could implement the same APIs and most apps will probably continue to work. Similar to how microG is a replacement for Play Services and still works for most apps (not as well as sandboxed Google Play of course).
Above that, not much would change for a few years anyway, because apps still target ancient Android versions.
Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.
Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.
I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.
Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.
And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.
They could for a while but what's the point if it's not sustainable? Google is not going to turn around and make it more open again.
With every Android release you will build up more feature base to replicate. Unless you cut all ties and drive a separate ecosystem but good luck getting enough developers to buy into that.
So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?
Apple isn't going to let them build on top of iOS, and anything except those two is dead in the water because it'll never have users because it is missing a bunch of critical apps, and will never have those apps because it doesn't have users.
IE's monopoly was replaced by Chrome and Safari's, and Safari only exists because Apple gives you no choice but to use it on iOS. Firefox had a brief spot on top, but it really didn't last that long.
Windows still has the vast majority share of desktop.
Yes but that's my point. Monopolies don't last. We have other ones now yes. But that's because the earlier ones died.
And yes we still have windows as the major desktop OS but don't forget, in the 90s/early 2000s windows was equivalent to computing.
These days the desktop OS is much less relevant than it was and many people don't even own a laptop or desktop anymore. They just do everything on their phone. And Microsoft totally and completely lost that race.
Chrome is the outlier there. It didn't come with any desktop OS and still got near 100% market share, even before Android contributed to that. How? It's worth studying.
The AOSP does not run modern Android apps, since Google has been replacing the APIs those apps require with closed source versions (that only ship as part of Google Play) for over a decade.
That is not true. AOSP can run all modern android apps, and google play APIs are provided as alternatives, but not replacements, for AOSP functionality.
No, that's a widespread misconception. Google Play services is nearly entirely APIs for using Google services. It hasn't replaced AOSP functionality and the AOSP APIs are still there. If you want to avoid Google services then there isn't much that's useful in Play services. Getting developers to not depend as much on Google services such as supporting UnifiedPush in addition to Firebase Cloud Messaging leads to those apps no longer requiring Play services for that functionality.
Android is an open source Linux distribution for smartphones. It doesn't have to be used with Google Mobile Services. AOSP is far more private, secure, usable and compatible with a far broader amount of apps. Why wouldn't we use that as the starting point even if the goal was to diverge?
I have it. It's far too slow to be useful, and it's not the hardware's fault. GTK and Libhybris are bad separately and hot garbage together. This problem won't be going away while the hardware is relevant.
That's a huge downgrade for privacy, security, usability, battery life and compatibility with apps. GrapheneOS is Linux too. Linux doesn't mean glibc and systemd. Linux is unfortunately not a great base for an OS focused on privacy and security but it's the only practical choice at this time. In the long term, it needs to be replaced as the bare metal kernel.
Testing the FLX1S for a few weeks as a media player, modern day iPod tool with offline content storage / temp caching. Battery is better than current Android phone. Both have areas of better usability.
I would recommend it as tool for a Linux app designer to use with testing and user improvement. Helps find issue not present on a laptop or desktop. Highlights the difference in solution choices; Python vs Node.js vs Rust.
I'm getting away from Google as far and fast as possible. The sooner the bandaid is pulled the better and more freeing. Google's path with being able to reject those that they don't seem worthy to run on Android, that is a prison.
Personally, I should have root access to the device so that all content which must be archived can be or consumed with another tool; Category Theory. I should have direct access to copying or backing up SMS with ease. Watching the network traffic to know what is actually going through.
Security is also being able for one to learn about the actual operations and test and validate them.
So say you use a USB device to host the kernel boot image which then requires manual password authentication to decrypt physical device drives. Without the USB device, it boots into duress mode.
Duress mode provides a false shell into a working phone. Physical security system do this, by provide false statements of what is going on. Wipe the real stuff in the background if need be.
GraphneOS is using a Linux Kernel. I'm looking for something more Linux Distro style of implementation. Not choosing GraphneOS is pure objective to remove myself from Google and Apple as much as possible in a communication tool.
Android device has become phone and text only. Linux device has become my engagement. Going for a walk without primary communication is peaceful.
This, 100%. It's exactly why I would choose a standard Linux distro any day over GrapheneOS. Biggest reasons for me being:
- No dependency on Google
- Actually free and open OS (this means: root access to device, being able to customise any part of the distro/WM/DE, full, low-level access to external devices etc)
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
Waydroid can't run nearly as many Android apps as AOSP on bare metal or especially GrapheneOS with the compatibility features it provides. It's an approach with far more limited compatibility.
Waydroid has very poor privacy and security due to disabling most of the app sandbox. It's also based on an old version of LineageOS so it's missing many important privacy/security updates, but it's much more relevant that it doesn't have SELinux and exposes much more kernel attack surface to apps. SELinux is not an extra layer of security for Android but rather is used in a far more deeply integrated way than any typical desktop/server usage. It's a huge portion of the security model including the app sandbox and protecting the Linux kernel.
We greatly prefer virtual machines over a half-baked container approach disabling most of the privacy/security model. There's already hardware accelerated virtualization on all of the supported devices for GrapheneOS and we plan to make a lot more use of that in the future.
> In the longer term, we plan to add support for RCS including support for the standard end-to-end encryption (E2EE) via Messaging Layer Security (MLS). Currently, RCS including E2EE is available on GrapheneOS via Google Messages. We want to avoid the need to use Google Messages for RCS eventually.
Hell yeah. Google Messages has worked reasonably well for RCS so far (after a long and frustrating period where it didn't on T-Mobile), but having a non-Google option will be huge.
They are really creating a lot of buzz recently. I love it, I hope they succeed beyond just us geeks here. It is imho imperative for a fair and balanced technological society that it retains the means for truly private and secure communications.
My devices help me think, and my thoughts are my own. That is a fundamental condition of human-hood. Sure we can change that, if that's what we want, but do we? If we do, do we make it a conscious choice per person? Or do we let big tech/corporatocracy dictate what it is to be human?
Ctrl+f clipboard, no results. What does "Secure Clipboard" in the title refer to?
The release seems to be only the SMS/RCS app, rest is future:
> We're also going to be overhauling or fully replacing the rest of the AOSP apps in the near future. AOSP Gallery is incredibly outdated and is being entirely replaced. AOSP Keyboard may be similar. We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
https://grapheneos.social/@GrapheneOS/117225731764489295
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
There's a separate thread about our secure clipboard feature:
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
We posted it right after the Messaging app thread but they're separate topics.
I believe this is the planned gallery app. I've already been using it: https://github.com/IacobIonut01/ReFra
Just tried this out. I may soon be cancelling by Google Photos subscription...
While you're doing that check out Immich - https://immich.app
One of the best solutions I've ever used for photos, backups, enrichment, etc
Ente photos is the best. It's almost as good as Apple Photos.
Our plan is to fork ReFra and drastically change it. We have a different scope and requirements for it. ReFra will still be useful for people who want features we don't plan to provide. We've considered trying to do it as an ongoing fork and making upstream contributions which we started on but it likely isn't practical. We haven't fully decided on this.
keeping the OCR and CLIP right? the main thing i miss from ios is the great local ocr + image tagging and search in the photos app
I hope they replace the AOSP keyboard with FUTO keyboard. I'm mostly fine with the other stock apps, but that keyboard was the one thing I absolutely had to end up replacing due to its jenky behavior.
I agree FUTO is the best right now but it's not open source so they won't.
The source is here: https://gitlab.futo.org/keyboard/latinime
Featured prominently in the "Source Code" container on https://keyboard.futo.tech/
AFAIK everything FUTO makes is open source? I haven't seen a counter-example (I have not looked hard though!), and https://futo.tech/about claims the following:
>All FUTO-funded projects are expected to be open source or develop a plan to eventually become so. No effort will ever be taken to hide from the people what their computers are doing, to limit how they use them, or to modify their behavior through their software.
From the LICENSE file:
https://gitlab.futo.org/keyboard/latinime/-/blob/master/LICE...
>You may modify the software only for non-commercial purposes such as personal use for research, experiment, and testing for the benefit of public knowledge, personal study, private entertainment, hobby projects, amateur pursuits, or religious observance, all without any anticipated commercial application.
Violates clause 3 (Derived Works) and clause 6 (No Discrimination Against Fields of Endeavor) of the Open Source Definition [0].
>You may distribute the software or any part of its source code only if you do so free of charge for non-commercial purposes.
Violates clause 1 (Free Redistribution) and clause 6.
>Notwithstanding the above, you may not remove or obscure any functionality in the software related to payment to the Licensor in any copy you distribute to others.
Violates clause 3.
It is a "source available" license, not Open Source.
[0] https://opensource.org/osd
Ah, yeah, agreed - "source available" fits that much better. I'm pretty sure that's the same for immich (which is also from FUTO).
Thank you for the details! That lays it out nicely for anyone else passing through.
Immich doesn't use the FUTO license because they acquired it and it was already under a copyleft open source license.
Thanks for sharing this! I spoke out of ignorance, having only considered the source code being available but not the licensing. (though I find narrowly defining "open source" to be rather pointless) I haven't tried every open-source Android keyboard, I've been very happy with FUTO Keyboard. Kinda too bad it's not compatible with being shipped with GrapheneOS, but it's also understandable why they'd license it this way.
Right, they are adhering to a definition of open that includes free as in liberty, so licensing matters. What good is it to read the source if I don’t have rights to modify and redistribute?
https://gitlab.futo.org/keyboard/latinime/-/blob/master/LICE...
It is not open source. They use a custom source available license. There's no way any Android distribution would include it. A layman's reading is that FUTO could claim license violation on account of the distribution accepting donations (non-commercial use only) and there's a weird clause about not accusing FUTO of patent infringement.
Alternatively they could ask FUTO for a commercial license.
Maybe, but there are better candidates GrapheneOS is more interested in.
Such as?
Florisboard.
Thanks! I wasn't familiar with it (using FUTO now), but it looks really good.
curious: what are the advantages of futo vs leantype? i use the latter but never looked deep into it, it just seemed the easiest better than aosp thing on f-droid
Heliboard is good, customizable, and actually open source - GPL3.
I like Heliboard a lot, but its autocorrect gets stuck in the mud all the time.
It completely falls apart and starts injecting nonsense phrases made up of nonsense misspelled words moment you miss a space ('v' or 'b') or type a really long word it doesn't know.
It also stubbornly incorrects other things like 'a' into "and" if it thinks it knows a phrase fragment. It's always wrong. It just happened to me now twice. Above, "or type a" became "or type and". Also, "it's" became "IRS".
Heliboard would be perfect if it stuck to word-only spellcheck and never split words. Just now again, it tried correcting "heliboard" into "hellenized" and "he lib oars".
This is not a matter of just lowering how aggressive the spellcheck is. It will still generate slop every time. The only real option is to completely turn it off. Futo can have similar problems, but there are a lot more options to tweak and the defaults aren't so bad.
I turn off automatic autocorrect except for "I". I can use it manually when I need it (jot often).
this was my experience. the autocorrect for heliboard is beyond atrocious and renders the keyboard unusable.
i ended up just using gboard on gos because every other one i tried fell short.
hopefully the stock gos one can be reworked into an actually decent keyboard.
Autosuggestions are nice to have but there is no autocorrection that really works well in my experience regardless of OS.
If you are referring to Heliboard as an AOSP board replacement, that cannot work, GrapheneOS cannot use GPLv3 projects.
If you mean it as a user installed app, please disregard.
Could you please elaborate? I wouldn't think this causes an issue unless they need to link against it, which I don't think they do.
Unsure what you mean by link against it. GPLv3 requires making the entire project it is bundled with GPLv3 as well. GrapheneOS would need to relicense the entire OS and bundled apps as GPLv3 to allow them to use any app with that license.
Literally none of what you said is true.
Go read the GPLv3 license and/or ask yourself how Linux distributions are able to ship a mix of GPLv3, v2, MIT, BSD, etc licensed software all in the same image.
GrapheneOS may or may not have a policy against shipping GPLv3 software (I don't know), but if they do, it's a political or business decision, not a restriction imposed by GPLv3.
Why not Unexpected Keyboard?
As someone who uses and loves Unexpected Keyboard: the higher learning curve compared to other keyboards would be the main reason I can think of. The reliance on swipes in particular is something that's likely alien to a lot of smartphone users.
On the other hand, I use Thumb Key (https://github.com/dessalines/thumb-key) and think Unexpected Keyboard doesn't go far enough.
I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.
The latest FUTO works just as well as Gboard for me. Their somewhat recent update to their swiping library really changed the game, and their voice recognition is also pretty decent.
Same. Used to use GBoard, not FUTO is as good so no reason to.
not->now
It seems like work on voice recognition has halted entirely though. On https://keyboard.futo.tech/voice-input-models , community models and other models have been "coming soon" forever, and in the end the only model they offer is whisper-small, a very basic model from 2022. Which in AI is like prehistory.
Google can shuttle network requests to any of their other apps (or play services, if that's running) via IPC, even with the network permission disabled in Gboard.
So if you're using Graphene for privacy from Google specifically, it's not safe to install things like Gboard even with the network permission disabled. Even if they don't use IPC in this way today, there's no telling what the Google-of-tomorrow will do.
there's no telling what the Google-of-tomorrow will do.
This is true and even vastly understated. Google is like the Walter White of companies. Starts out innocent, turned into a monster, everyone around him astonished at the dark, depraved change.
So if one thinks "nah, Google wouldn't do that", I have a bridge to sell you...
fyi disabling network permission doesn't protect against deliberate and coordinated data exfiltration. Apps can still communicate with other apps, for example with Google Play Services or any other app.
futo is running whisper to transcript and it is local only
I wish Futo had the ability to use a typing heat map for more accurate predictions like SwiftKey. It constantly suggests "AMD" when I am trying to type "and". I have fat thumbs OK! I don't even have the caps on and I RARELY talk about AMD. It's just the one thing I miss. I do find the predictions generally less accurate as well, but perfectly usable.
They cannot. The license FUTO uses is not open source and is incompatible with being bundled with GrapheneOS.
Probably never happening in the next millennium. GrapheneOS has a gripe against FUTO because it is tied to Louis Rossmann, which dared to challenge GrapheneOS's social skills in the past.
Daniel Micay stepped down as the lead dev and was where most of the lack of social skills was coming from.
twitter versions have paragraphs not threads
https://xcancel.com/GrapheneOS/status/2096677808424788256#m
https://nitter.click/GrapheneOS/status/2096677808424788256#m
https://bsky.app/profile/grapheneos.org/post/3muun5c4fdc2o
Secure paste:
https://xcancel.com/GrapheneOS/status/2096685327020933355#m
https://nitter.click/GrapheneOS/status/2096685327020933355#m
https://grapheneos.social/@GrapheneOS/117225731764489295
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
Default apps in GrapheneOS are really outdated. Especially "Gallery" where on standard "compact" device top navbar is still too small and requires very precise touch. Hopefully, little by little, all stock applications will be updated to more modern variants. I personally had plans to build some open source stock Android applications, but after whole nonsense with platform being locked down I do not see the point in investing my time, just for google to block my apps.
> I personally had plans to build some open source stock Android applications, but after whole nonsense with platform being locked down I do not see the point in investing my time, just for google to block my apps.
It doesn't apply to GrapheneOS users and it doesn't affect developers who have apps on the play store. You should do it! Many users on stock android who would install apps not from the play store will have gone through the 24 hours or used ADB.
i think the worst offender is dialer
"RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported."
Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt Jive?
None except Jio in India and various carriers in China
The rcs part doesn’t make sense at all, it’s a google messaging standard. How do you do rcs without Google approval esp for things like business messaging it has to go to Google for approval eventually.
I would prefer to have Delta Chat like app that uses email (SMTP/IMAP) as transport instead.
There are excellent FOSS gallery apps already, like the Fossify suite. Why not use them I wonder?
Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing.
Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.
Its not part of the OS so why would it affect the Graphene OS license? Its an app, not a library.
The preinstalled apps are part of the OS.
That cannot be true, when I install e.g., Ubuntu system, there are plenty of applications installed for me, with incompatible licenses.
Can you please elaborate on what you mean?
Ubuntu does not aim to be a permissively-licensed system. It can include copyleft (e.g. GPL) and permissive (e.g. MIT) without issue.
Permissively-licensed systems like FreeBSD and GrapheneOS cannot include GPL code if they want to remain permissive.
GrapheneOS does include GPLv2 code both via AOSP and our own but not GPLv3. We want GrapheneOS to have no additional restrictions beyond AOSP. AOSP uses GPLv2 but not GPLv3.
We do need to be careful with GPLv2 due to license incompatibilities. For example, GPLv2-only licensing such as the Linux kernel is incompatible with Apache 2 and GPLv3. GPLv3 is compatible with Apache 2 so GPLv2-or-later can be compatible but only by using it as GPLv3 with the extra restrictions too.
It seems like you have more freedom than you think you do. See this comment <https://news.ycombinator.com/item?id=49594824> Packaging software shouldn't change the license of GOS as such. If you haven't had already, maybe the free software foundation could provide you with assurance?
I guess it will make your life much easier if you wouldn't have to restrict yourself that much.
No, we're not talking about packaging software in our app repository (App Store) but rather software being included in GrapheneOS. If any GPLv3 software is included in GrapheneOS then that places more restrictions on how it can be used as a whole.
> GrapheneOS cannot include GPL code if they want to remain permissive
It's hard to take this seriously when the entire kernel is GPL.
It is true, and if Ubuntu is shipping apps as a part of the OS with incompatible licenses, that is a crime.
Not a crime a civil matter.
I think you are confused. You can have a Linux distribution with software with incompatible licenses (e.g. GPLv2 and Apache License version 2), because the license for a particular program or library only applies to that specific work, not other works that it is distributed with. The GPL is very clear on this:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
There are some cases where a separate work can be considered derivative and thus the GPL can apply. E.g. I think it is generally accepted that a program linked statically against a GPL library is considered a derivative work (and must thus must have a license compatible with the GPL). More controversial is whether dynamic linking creates a derivative work. To cover the latter case, a lot of copyleft libraries are licensed under the LGPL or the GPL with a dynamic linking exception.
At any rate, shipping a Linux distribution with GPLv2 code (e.g. the Linux kernel) and a GUI application that is under the Apache v2 license is not a problem at all (as long as the GUI application is not a derivative of a GPLv2 work).
(IANAL of course, so this is not legal advice.)
GPLv2 and Apache 2.0 are not incompatible licenses when bundled together. GPLv3 is the problematic license as it requires all code it is bundled with be GPLv3 as well.
When it comes to AOSP/GOS, bundled apps are not aggregated together, they are built and signed under a singular OS binary.
OS components don't need to have compatible licenses if they're separate from each other. The Linux kernel is GPLv2-only which forbids GPLv3 licensing. That doesn't mean GPLv3 code can't be used in a Linux-based OS.
We use GPLv2 and permissive licensing for GrapheneOS to avoid more restrictive licensing than the AOSP. We'll happily use GPLv3 and AGPLv3 for components outside of GrapheneOS if we think it's the best fit for specific projects. We aren't currently licensing anything as GPLv3/AGPLv3 but we aren't strictly opposed to it outside of the OS.
We'll use what we think are the best open source licenses for what we want to achieve. What we want to achieve is usually broad adoption of our code with painless usage of it. That means we usually choose permissive licenses. We use GPLv2 in certain cases such as Vanadium where we decided we wanted extensions to our code to be under a compatible open source license instead of a source available license or GPLv3.
There's 5 licenses :o
IANAL, but I would expect that to fall under "mere aggregation"
The Refra gallery fork would replace the current ancient gallery app. That would be bundled with the OS. Doing the same with the fossify suite or similar would be illegal. These licenses do not treat apps or libraries differently. GPLv3 code forces the code that it is bundled with to also be GPLv3.
That's textbook FUD.
Can the Linux kernel be included in the OS?
Linux is GPLv2, though. Not sure if that makes a difference here.
It does make a difference. GrapheneOS includes a lot of GPLv2 code from AOSP and we choose it as a license for several of own projects within GrapheneOS.
Yes, the GPLv2 license does not have the same restrictions GPLv3 does, it does not necessitate making the code it is bundled with GPLv2.
Neither does the GPLv3:
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
If you'd include a GPLv3 gallery app in, say, a mobile OS, it does not mean that the rest of the OS has to be under the GPLv3. It merely means that you cannot limit the user's right when it comes to the GPLv3-part (the gallery app). They would still be allowed to redistribute/modify it and you have to provide the source code on request.
You only have to make other code GPLv3 if you somehow create a derivative work (e.g. linking against a GPLv3 library).
(IANAL blah blah)
The issue isn't that GPLv3 applies to non-derivative OS components but rather that the terms apply to the overall redistribution of the OS. Including any GPLv3 component means GrapheneOS cannot be used in products where AOSP can be used due to having additional restrictions beyond GPLv2. We don't want more restrictive licensing than AOSP. We're fine with using additional GPLv2 code as long as we're sure it's not going to move to GPLv3 or that if it does we're prepared to maintain it ourselves.
Name the restrictions.
Yes, AOSP includes a lot of GPLv2 code and we use GPLv2 licensing ourselves including for our Vanadium browser project. We don't want GrapheneOS to be more restrictively licensed than the Linux kernel and AOSP so we avoid GPLv3 code bundled with the OS. GPLv3 is perfectly acceptable for apps in our App Store but we don't want it for the ones in the OS.
Media handlers are a security nightmare, might lead you to the right answer if it isn’t it.
We're going to be forking one of them (ReFra). We want to make extensive changes and have a different vision for it than the upstream project. For example, we don't want it to have integration into services. There's plenty of room for both an increasingly different fork of it in GrapheneOS and the original project which our users will continue to use who want features we don't consider inside the scope of what we want from a local gallery app.
What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Google. I wouldn't hate it if GrapheneOS would totally ignore RCS. I fail to see any value in it, but maybe I am lacking information(?)
RCS allows higher resolution pictures than MMS.
Perhaps it's different in other countries, but I've never seen anyone use MMS. (Everyone uses WhatsApp nowadays, but even before WhatsApp existed, I never saw anyone use MMS.)
I've seen people try, only for it to never actually work (images either compress horribly, to the point there's no reason even sending it, or just fail to send).
MMS bring broken since day 1 in my experience is probably the reason I jumped on internet chat and email, since those actually work as advertised (sure, they has some practical limits, but they tell you about those!). I probably would have sent my mum that image over MMS if MMS actually every worked. Since it never did, using a difference service was a must.
Then again, this feels like an extension of the rest of the phone system. Anything beyond calls between two people, SMS and data that involves connecting to the phone system has always (in my experience) been either janky or broken. No wonder I try to use anything else given the opportunity.
It depends heavily on country, yes. USA is extremely light on WhatsApp, and MMS use is widespread (and has been free for a long time now, and SMS even longer). RCS is a mostly silent upgrade for USA.
I'm not sure which of the two is better tbh. Utterly dominated by a Facebook-owned system, or using something that's crappy enough that people spread out to a variety of systems?
Amazing how blinkered supposedly privacy conscious Europeans are when they willingly line up at the Facebook slaughterhouse.
The huge switch from SMS to WhatsApp in Europe was well done before they were acquired by Facebook. By then the damage was already done, because the network effects made it very hard to move away. By now, many people I know also have a Signal account, but it doesn't really get off the ground as long as, say, 30% of every group chat does not use Signal.
Year, back prior to the Zuckification I'd say it was a very clear upgrade for everyone in essentially every way. Dirt cheap (much less than even minimal texting), installable everywhere, adopted solid E2EE far ahead of basically every major player (2016!), it was great. USA had everything worse for a long time, and many things still are.
But once it landed in Zuck's hands, I no longer trust it one bit. Abandon ship.
RCS provides far better support for group chats, many small feature improvements and end-to-end encryption (E2EE) via Messaging Layer Security (MLS). E2EE for talking to GMS Android and iOS users without them needing to install another app is the main reason we care about it, but far better group chat support matters too. iPhone users very often don't want to have SMS/MMS users in their group chats.
This is a very US-centric (and maybe Canada) thing though? Most of the rest of the world doesn't really use or care about iMessage, even on iPhones. So, I think it's rather
-US- iPhone users very often don't want to have SMS/MMS users in their group chats.
The rest of the world is using WhatsApp, WeChat, Telegram, Snapchat, LINE, etc. for group chats (for better or worse), even on iPhone.
> This is a very US-centric (and maybe Canada) thing though?
If what you say about “the rest of the world” using other messaging apps is true, then yeah, it probably is North America–centric. So what? Are you agreeing with the OP who didn’t see any point and advocated that GrapheneOS “totally ignore RCS”?
GrapheneOS already supports WhatsApp, WeChat, Telegram, Snapchat, and LINE. What’s wrong with improving OS support for another widely used alternative, that for all its faults is mostly better than still another widely used alternative (SMS/MMS)?
There’s a thread on the GrapheneOS forum titled “Using RCS with Google Messages on GrapheneOS” with 2,192 posts in it. Clearly there’s a lot of interest in using RCS on GrapheneOS!
Are you agreeing with the OP who didn’t see any point and advocated that GrapheneOS “totally ignore RCS”
No. I think it is useful for GrapheneOS to work on this, the US is a substantial user base.
The comment I reacted to:
iPhone users very often don't want to have SMS/MMS users in their group chats.
I think it is useful to qualify that, because a lot of people from the US are under all kinds of false beliefs like: green bubble anxiety is universal, Pixel 10 and Pixel 10 Pro do not support physical SIMs (Pixels support physical SIM in other regions), etc. (I could go on for a while.)
These misunderstandings repeatedly show up over and over again and discussions, so I think it is worth being specific. In this case most iPhone users worldwide do not even think about SMS/MMS users in their chat, because they do not even rely on iMessage as their primary messaging app.
All carriers I've tried in my country have even disabled MMS entirely. They're not running RCS servers either, though, everyone is on WhatsApp anyway.
In theory carriers could increase the max resolution for MMS now that 3G is essentially dead, but I doubt they will now the slow move to RCS has started.
From [0], it seems that RCS can use the cellular signal instead of LTE or 5G:
> In cases where RCS is able to operate over cellular networks without data, it supports messaging as well as file transfer, enriched calling, and more.
[0]: https://en.wikipedia.org/wiki/Rich_Communication_Services
In LTE and 5G there exists no cellular signal without data. That was a 2G/3G thing. Since 4G everything is data. The separate sms and voice services are gone. And 3G is rapidly being deprecated.
That's not quite true. VoLTE was an optional part of 4G in the beginning. I had one of the gaming ASUS phones that shipped with 4G, but no VoLTE. 6 months after getting it, the US phone carriers conspired to make VoLTE mandatory for connecting to their towers, effectively bricking my device. ASUS never issued the firmware update that would have enabled the feature in the modem, which had the capability, and the community hack to enable it never worked for me.
Yes, circuit switched fallback was possible for a time (LTE data and circuit-switched 2G or 3G voice). I think 3GPP shouldn't have written that into the spec in the first place, but you know what they say about hindsight....
The whole saga with VoLTE was really quite entertaining: https://nickvsnetworking.com/background-to-the-volte-mess/
4G without VoLTE is using 3G for voice because there is no other 4G voice.
It was an optional part but without VoLTE you just could not call with 4G. For that the phone just switched back to 2G/3G.
That's not a sustainable solution because 2G/3G are getting switched off. And it doesn't really have any bearing on LTe itself.
The real issue is that they didn't really standardise VoLTE enough. Leaving every carrier and manufacturer to have a mesh of different options and not every carrier and every phone supports the exact same subset of options, which causes the compatibility issue. Also sometimes providers don't bother checking phones they don't sell.
They really should have standardised it 100% so this couldn't happen.
It's true that it's all packet-switched rather than circuit-switched, but IMS traffic is still handled differently than regular data traffic. (The most user-visible implication of this is the QCI difference: cellular phone calls are much more reliable at poor signal strength and high congestion than over-the-top VoIP calls).
Isn't that just basic QoS?
The point of the exercise is for Google and Apple to maintain control over the ecosystem.
RCS is technically superior (protocol, transport, security, all of it) but is captured from the start on the technical level by design by the big players. From the perspective of the vast majority of users who have very limited technical awareness, it was silently slipped in as an upgrade at one point or another. This means that those not adopting the proprietary BigTech solution are perceived as being difficult by insisting on using software that's now perceived as outdated or as otherwise mildly incompatible.
GrapheneOS does not want to adopt RCS for public perception. It is still a better option than SMS/MMS and providing it is beneficial. GrapheneOS will still recommend using better platforms and protocols but RCS being bundled and cross platform are great reasons to implement it.
Suppose GrapheneOS becomes highly popular. Then I have to fight the average Joe who insists RCS is fine enough.
I understood from other comments that RCS is the default communication channel in N.America an I can sort of see why you want to give people a somewhat less worse option here than Google's Messenger. But RCS should not be the default imho, because lazy people gonna be lazy. So I hereby endorse you to gently push newcomers towards a safe and privacy friendly default by pre-installing Signal or whatever meets the bar and give it a prominent place.
Whether or not you tolerate using RCS is up to you. Not supporting it for the sake of having a worse default option on the off-chance you can use the to convince them to use a better option is not a good reason to not support RCS.
Either you will have people content with SMS, or you will have people content with RCS. Which is better is obvious.
I am not on the GrapheneOS team but the community does push better options such as Molly/Signal and RCS is usually only advised as a fallback messenger.
Eh, I don’t think you have to include Apple here. If it were up to them, the iPhone would still have zero RCS support right now. The current implementation of RCS, even in iOS 27 beta, is clunky.
To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
Idk, I mean RCS on iPhone is just SMS/MMS but fixing like 90% of the issues. I don’t find it that clunky.
More like it's iMessage, since it's locked to two vendors.
> To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
Yes, exactly. Apple and Google are both acting to maintain control and this has resulted in a standard that improves functionality but is effectively poisoned at the technical level. Left to their own devices I'm sure Apple would have preferred to stay with their original solution that is even more closed off.
RCS was DOA from day one as far as I'm concerned. The carriers being involved in any capacity deeper than providing dumb pipes alone was enough to make it pointless, but no E2E in the base spec makes it extra pointless. They may as well have just extended SMS to be more capable, because that's what they've effectively created.
The RCS spec has encryption in its documentation. I think the current spec version is 4.0?
It has it in its current documentation (maybe 3.0 too? I forget, but it's new this year), and Apple and Google have had messages to themselves encrypted for a while (but not to each other, which is what the RCS docs are intended to resolve). It took many years to get it documented though (despite loudly claiming RCS is more secure the whole time), and AFAIK none yet implement it. Definitely none with all the documented things it needs to show to be compliant with the spec I read, e.g. key verification - I certainly don't see any of that in Google's "Messages" app! Though hopefully that will all change.
But honestly, in a non-open ecosystem, can you really trust that the near-exclusive two major players are actually playing by the rules? Apple has been relatively protective of its users on privacy stuff, but I've lost all trust in Google at this point.
> key verification - I certainly don't see any of that in Google's "Messages" app!
I do! I have a old-ish but up-to-date and stock Pixel phone, and I see (what appears to be) full E2EE with several text contacts in Messages, with ability to verify keys (which admittedly I have not attempted to use yet). It only works if both devices / all of the devices in a group are fully compatible with the version that adds encryption or newer, but when they do, it just starts working automatically and transparently. AFAIK, that's primarily thanks to Google's work.
I think what we've learned from the rise and fate of current alternative messaging apps and services is that, if we actually want to get the majority of the world's population on modern-quality E2EE for all of their communication, it's going to have to be done gradually and transparently through the apps they already use. Getting everyone to switch to a different app is a pipe-dream that will never happen, at least not thanks to the work of any particular person or company.
Apple is pretty good at privacy and security for people playing within their ecosystem. They seem rather indifferent to any attempts to communicate or interact with anybody without an Apple device. Better than nothing, but not great IMO. Google has many faults in many areas, but I think they're doing awesome work at a difficult and thankless job as far as developing a standard for modern and fully encrypted communications that is actually possible for everyone to switch to transparently, and dragging everyone kicking and screaming into actually using it. Apple just rolled out support for it in beta 4 months ago. Very likely in the next year or so, we may see the majority of texts and group-chats between Android and iOS be actually E2EE without the users needing to do anything besides ordinary OS updates. That will be IMO 80% Google's doing, and 20% Apple's.
Almost none of my RCS conversations are encrypted. Who cares what's in the spec if nobody uses it?
Yes but there are different specs that “compatible” apps will have to adhere to, basically until everyone is always running auto updating software to the latest version supporting RCS 4.0
Long story short somebody preferred to “ship it” instead of waiting to figure out how to make encryption compatible between iOS and Android. I guess there’s some differences in how the key rings work, but Signal can figure it out and /they’re/ open source so it sucks they ever supported unencrypted messages. They just wanted to say it technically worked for rich text messages and reactions.
I don't know much about RCS other than that carriers need to be involved, but there's a way to not involve them, which Google did for a while using some kind of compat-service (jibe or something?), and then they stopped doing it.
Never seen RCS working on any carrier ever since. I don't understand why Google couldn't just continue doing what it was doing. Why require carriers?
The intended purpose of RCS was to be federated between carriers, just like SMS. If you centralise it then it's just a worse version of any of Google's abandoned chat apps. But there's a realpolitik reason to insist on centralised RCS: because it's already got the reputation of decentralisation, it makes it look like Google is better than it actually is.
> The intended purpose of RCS was to be federated between carriers, just like SMS.
Oof, so it was essentially destined to fail when the spec was being written.
Did SMS fail? Sort of, as it's rarely used, but also not, because it continues to work and it's still the only federated messaging system you can rely on being available on your phone (besides phone calls).
SMS was a huge success. For a standard that was defined in 1986 and first rolled out in 1992, it had good longevity and was extremely popular from its introduction until ~2010 [1]. Nearly 20 years is a good run for a technology in a rapidly evolving field. It was also designed in a completely different age when most phones did not have cellular internet and carrier support and federation were the only way to provide reliable person-to-person messaging. Even though the carriers probably dream of reviving SMS as RCS to be more than just pipes for the internet, those days are over.
Google-based RCS is Google coopting an existing standard to get the foot in the door for Apple Messages interoperability. By coopting a standard (rather than pushing yet another Google messenger), they could convince regulators to push Apple towards supporting it. Otherwise RCS is completely irrelevant and if it weren't for Google, it would've been mostly dead.
[1] Yeah, I realize that is was probably used in the US much longer, but that's when it started to dwindle in the rest of the world, where MMS also never really took off.
RCS is an extension of SMS and has quite literally been "SMS but more capable" from the start. The protocol on the wire looks a lot like MMS over LTE. Registration and communication mostly happens over SIP and RTP like in the latest MMS specs.
The early versions of RCS were barely implemented. Android and iOS didn't bother including clients, carriers didn't bother hosting servers because the spec was optional, and third party applications made by carriers were launched and then died because carriers couldn't explain to customers why their app was better than WhatsApp e.a. for those in the market for alternative messengers.
I think it's safe to say that RCS would've died a quiet death had Google not used it as a basis for their own Hangouts alternative built into their SMS client.
When RCS was first (soft) launched back in 2008, E2EE messaging practically didn't exist. Google slapped E2EE on top when they hosted their own iMessage alternative to bring it into the modern era but the base spec was still "what if MMS wasn't so outdated and restricted".
RCS was DOA from day one as far as I'm concerned.
Agreed. Google used a standard that virtually nobody (except some carriers) cared about to get a foot in the door for better interoperability with iPhones, to try to solve an issue that is mostly US-only (green bubble anxiety),
In most of the rest of the world nobody gives a shit about RCS since we have adopted other messengers (than iMessage or SMS/MMS) ages ago, most of which are already end-to-end encrypted.
I understand why GrapheneOS has to spend time on this (the US is a large user base), but it's sad nonetheless.
The point is to access an e2ee protocol bundled by default on many devices, and is cross-platform.
GrapheneOS does recommend using superior platforms like Signal, but that is 3rd party, and thus has adoptability issues in convincing people to use it. Just because better platforms exist does not mean RCS should be ignored.
Thanks for clarification. Anything first party from Big Tech is a lost cause privacy wise. At the same time, nobody uses it (maybe that is different in the USA, don't know). So for me this would be ultra-low prio as I (and I expect almost every other GOS user) will never use it. But I believe GOS knows what it is doing.
In the US everyone with an iphone uses RCS, so you'll often have family group conversations on it and so on. Whatsapp or signal are comparatively rare (although more common for anyone with overseas family naturally)
No, in the US, everyone with an iphone uses imessage. (Basically all my family's messaging goes over imessage) It's only when non-iphone users are on the chat that RCS comes into play.
Nearly everybody uses it in the USA. It's very common to text people through the default messaging app on your phone there (probably an outgrowth of the popularity of iPhones and iMessage), and backup options would be Instagram, Snapchat for a certain demographic, or Facebook messages. Whatsapp is only for messaging foreigners, and Signal/Telegram are for messaging your drug dealer.
Yep, I have never used anything other than the stock messaging app that came with the phone. Whether that's SMS, iMessage, or whatever has never crossed my mind
I was really disappointed when Signal went away from being used as an "everything" messenger, including regular SMS. I onboarded all my family and now because it's not a default messenger, nobody is using it.
But that's the same situation as WhatsApp, and everyone uses WhatsApp.
Give them 2 channels, be clear about your terms of service and that your intent is to become exclusively available on Signal after one year:
- Signal. high priority channel, checked daily
- $PrivacyHazardApp. low prio, checked with steadily increasing intervals.
Make sure you communicate those intervals in advance, have them in the footer of every message you sent on $PrivacyHazardApp. Average Joe needs lots of patience and lots of education.
TIL. My deepest condolences. I thought that we, from this side of the pond, were upholding the honor of being the dumbest with our Whatsapp subjugation, but alas.
I assume many people would use it due to SMS concerns and difficulty having people move to other platforms. I would personally use it as a fallback to Signal since my current fallback is SMS, which I dont like.
If the protocol is properly e2ee, it does not matter who backs it or hosts it. GrapheneOS would be in control of the client which is what matters in an e2ee system.
GrapheneOS would be in control of the client which is what matters in an e2ee system.
Not really... You will be communicating with other people who don't use GrapheneOS and if you are e.g. communicating with iPhone users who have iCloud backups enabled (most iPhone users) and did not opt in to ADP (against most iPhone users), the chats are only encrypted at-rest in the iCloud backups and are accessible by Apple and law enforcement.
Signal is way better because it opts out iCloud backups (and Android backups) in favor of truly end-to-end encrypted backups.
RCS's point is to deliver ads. It is its first purpose. The way I see the situation, the point for Graphene to implement RCS is to prepare for the foreseeable deprecation of SMS. Who knows when it will happen, but better start working now than wait and get stranded when it'll happen. I'm pretty sure RCS implementation will take a long while.
I believe it was meant to be federated, like SMS, and then in practice it wasn't. With Signal you depend on your carrier and on Signal - with SMS you only depend on your carrier.
It's nice to be able to send/receive photos with more than 13 pixels in them.
Certainly, with Opus 5 and GPT-6, modernizing or even completely rewriting self-contained, non-critical tools seems like a Friday afternoon job now. I wonder however how important this is, in the grand scheme of things. I use GrapheneOS and the bundled messaging app is serviceable. It isn't pretty, but it gets the job done.
They are using AI [1]. I don't think messaging app is non-critical though.
[1] https://github.com/GrapheneOS/Camera/tree/compose
I dunno. If they're using AI, it's well controlled. I don't see a lot of artifacts you usually get from full-on vibe-coding.
Our code quality standards are very high. Vibe coding is not capable of meeting those standards. The details of how things get written and improved to meet our standards is up to individual developers. We don't have a policy against developers using AI for assistance. They need to understand all of the code and it needs to pass our code review. Our code review is now usually a lot more thorough than before. In addition to human review, we regularly pass code through a couple frontier AI models and then review the results to figure out which claims it makes are valid. Even the frontier models hallucinate many non-existent problems and often get a lot of details wrong when they find real problems, but they do find a lot of real problems.
https://news.ycombinator.com/item?id=49592770
Our port of Messaging to Compose was clearly not vibe coded as both the parent comment and yours are wrongly portraying it. Experienced developers have been working on overhauling the app for months with a lot of back and forth code review to get the pull requests into shape. We don't have a policy against using AI for assistance as long as the resulting code meets our high standards.
We definitely use frontier AI models with cybersecurity access unlocked for code review. Those often find problems we didn't catch via multiple rounds of human review. The output is filled with hallucinations and incorrect details but an experienced developer can sift through it, identify the real issues it uncovered and get those fixed.
How did my comment portray your port as you are vibecoding it? I just said that AI is being used.
It seems obvious to me that you guys would use it responsibly.
I appreciate all the hard work the Graphene team has done all these years with advancing alternative mobile OS and have been following them for years so I hope they don’t take this the wrong way -
The project would benefit from more polished, professional image/interactions with the community. I (personally) have a hard time trusting my data to a project that is constantly bickering (“no, we don’t vibecode, did you even look at the repo”) in public forums like this under the official letterhead account.
I’d love to see y’all discussing these types of technical details with individual, identifiable (even under fixed pseudonyms if you want) developers’ accounts, and leaving the official letterhead account to stick to posting marketing material.
Just my 2 cents.
We're definitely not churning out code with AI models. There's no vibe coding going on in GrapheneOS. We're carefully writing and reviewing code as we've always done. We now have additional tools to assist with it. The main way we're using AI models is for code review and helping to write a lot more tests than we used to. It's helping to improve our code quality, not reducing it. We're not trying to get things done substantially faster.
The code generated by even the bleeding edge publicly available frontier models is rarely good enough to meet our standards. AI models are creating a lot of additional work for us because of how many more security issues are being discovered in upstream projects. It's also helping us raise our standards for our own work by pointing it at that to get extremely pedantic criticism catching many things we would miss.
We've hired multiple experienced app developers who have spent months working on modernizing the Messaging app and carefully reviewing it. There's no vibe coding going on for our apps. Why not look at the actual process of porting Messaging to Compose and our code review for each incremental part of the process?
https://github.com/GrapheneOS/Messaging/pulls?q=is%3Apr+is%3...
I'm really glad to read this. Thanks for putting in the effort to make quality software, far too few people are willing to do that these days.
Could they just do PGP over SMS, built into the default app? They have all the machinery in place to store keys securely.
And send the content + PGP envelope over how many text messages? And for every single message?
“We'll be making a new release later today with a completely overhauled user interface written in ‹whatever›” is something developers love, and users fear.
LineageOS keyboard and the Trebuchet launcher would be most helpful.
I do miss keyboard symbols without shifting and icon packs.
FUTO Keyboard or Heliboard (both FOSS) will give you key symbols without shifting, as will likely several other FOSS keyboards.
Saying it's going to be released later today means to the Alpha channel. GrapheneOS and each of our apps have Alpha, Beta and Stable channels. Every Stable channel release made it through Alpha and Beta channel testing. We don't expect the initial Messaging app release to reach the Stable channel. AOSP Messaging hasn't been actively developed since around Android 5.x and nearly no one is going to be unhappy with the changes.
We're changing very little about the overall layout and structure of the app in this initial phase of the overhaul. Over the past couple months, it was carefully ported to Compose with a lot of code review and added tests. It was a lot of work and is going to look a lot more modern. It's also now possible to greatly improve the user interface in much more substantial ways than making it look modern.
If you have used GrapheneOS, you know Messaging is positively ancient and bitrotting. The overhaul makes it look like the rest of the OS and uses standard material 3. Its not something to fear.
Indeed. I don't use most of the stock AOSP apps on Graphene because the UI is so awful, but there are decent alternatives so it hasn't been a bother. I'm looking forward to seeing their work.
Very good idea! Google abandoned these long ago.
I don't really get why so many Americans want RCS to succeed though. Do you guys not remember when carriers charged 10p/text? Why on earth would you want to give any power at all back to those people?
The only benefit is sending higher DPI pictures between android and ios
It makes group messaging work a lot better, too. Previously, group chats with a mixture of ios and android users were really buggy leading to iPhone users significantly preferring group chats with all ios, which led to some social exclusion for android users in the US, leading to market dominance for iPhones. Now, with RCS, you can make a functional group chat across platforms and you don't have to convince anybody to install something new.
Well that is if that user uses Google messages. I certainly don't even have it installed.
If you have a smartphone from the last 5 years, you have to have done something unusual to it to not have an SMS app that also does RCS.
That's one of the reasons we care about it for GrapheneOS. It also provides end-to-end encryption between Android and iOS via Messaging Layer Security (MLS) which is clearly very important for us. GrapheneOS users needing to use Google Messages to get E2EE with Google Messages and iOS users who haven't been convinced to use Signal instead is not ideal. We do have Google Messages working via sandboxed Google Play but want to replace it.
RCS provides properly working group chats and end-to-end encryption with iOS and GMS Android users without having to succeed at convincing people to use Signal instead.
After getting several family group chats finally converted over to RCS, one day my phone just started absolutely refusing to verify my connection to the RCS servers. Instead of any kind of notification, I was just silently not sending or receiving messages for nearly an entire day. I had to disable RCS on my phone, which created a several day long issue where some chats would just fall back to SMS and others absolutely refused to work, or strange interactions with Apple devices where certain messages would not be displayed. After enough trouble with it I convinced everyone to switch to a third party messaging app. I'll never turn RCS on again, I can't trust that it won't just start silently failing.
It's a bandaid over iMessage's dominance among iOS users.
Text messages in iMessage or SMS are a fairly US-centric relic. That's not to say overseas is better - Europe depends on Whatsapp - but outside the US the whole 'blue box' thing isn't even a thing.
The main benefit of RCS is the fact it is available by default on other platforms like certified android and IOS. 3rd party messaging apps hit adoptability issues. A bundled, cross platform E2EE protocol is a huge step above SMS and MMS.
Many 3rd party platforms are still better though.
Americans have had unlimited texting plans for much longer than Europeans. I'm pretty sure most Americans had unlimited texts before Whatsapp existed, so there was never the move to it for economic reasons.
Yes I think this is the main reason for WhatsApp's popularity in Europe. Our providers were hanging on to sms as a cash cow and they were pretty much the most expensive bits you could send.
Malicious providers like kpn in the Netherlands even sought to charge extra for WhatsApp traffic because they lost so much revenue. However the EU shot that down hard under net neutrality.
But I remember it well and this is why I always disable RCS. I don't ever want to give my provider the chance to do that again. And I don't trust Google either. SMS is completely dead here too. It's been years since anyone sent me a personal message. It's just spam and poorly implemented 2FA shit.
It's not an issue here in Spain anyway. The only phone with iPhones are rich expats. Most of the people I know use cheap budget androids.
Funny reading those anti-LLM comments, lol
We spent months working on this and certainly didn't vibe code it. We do use LLMs but primarily for code review and boilerplate. We're now including a lot more tests partly thanks to it being less of a pain.
Our quality standards are too high for current frontier LLMs to generate much we could use directly. On the other hand, their code review output is extremely useful. It can find many issues we wouldn't catch even with multiple rounds of human review. It's helping us a lot with catching issues we've repeatedly overlooked.
Yeah, I know you guys are using LLMs responsibly. I just found those anti-LLM crusaders funny they way they were calling it an unethical and fascist technology.
As long as the code is being held to the same standards (which have been very high), it's only going to help the developers.
Btw, please save yourself some energy and mental peace by ignoring these people who haven't written a single line of serious code and are only there for bandwagoning and pushing their political agendas. Love the work that you guys do that's why I'd love for you guys to be able to focus on the mission and not get distracted by them. Thanks for all the hard work!
I'm happy todays update shipped auto call recording.
Yay! Finally, been waiting for it for ages.
Maybe they'll work on the backup now, this *** seedvault is worse than nothing (consistently broken on both my GOS phones, never giving the same results with 2 backups, never giving out as much as the status I could trust)
Graphene is clearly bullish on Android, but I have no idea why. The writing is on the wall, Google is slowly asphyxiating AOSP.
They may as well get ready for an eventual hard fork, then?
Yes RCS is barely a standard worth implementing, let alone the best one. Make SMS/MMS and XMPP work together seamlessly in one app, forget RCS.
Yes RCS is a pig with lipstick. Invented by the carriers to recoup some control over instant messaging, then abandoned and picked up by Google for the same reason. They're the ones that added encryption to it.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
RCS is important because it provides end-to-end encryption (E2EE) for contacts with Google Messages and iOS. That means having E2EE for the vast majority of smartphone users since Google Messages is the standard GMS Android carrier-based messaging app.
https://news.ycombinator.com/item?id=49593026
Remember Pidgin and Trillium?
I remember who forced me to consider other options.
I use cheogram daily.
It's important for us to provide out-of-the-box end-to-end encrypted (E2EE) messaging for contacts on Google Messages and iOS. Both Google Messages and iOS provide RCS with end-to-end encryption via Messaging Layer Security (MLS). Google Messages is the standard text messaging app on Google Mobile Services Android and iOS now also supports RCS with MLS. The vast majority of people have an E2EE messaging app on their smartphone and it's important for us to provide compatibility with it. Currently, a growing number of our users are installing Google Messages to have better usability and privacy for texting with contacts on Google Messages and iOS.
People can already install the messaging apps of their choice on GrapheneOS. It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide. We need a messaging app to handle carrier-based messaging in the OS including providing end-to-end encryption for it and the rest is up to other open source developers.
It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide.
I disagree with this somewhat. Apple and Google make these sweeping decisions for their users and in effect promote one tech over another. Adopting RCS and integrating it natively, but shunning open protocols and leaving them for third party apps (with probably worse OS integration) means you are following, not leading.
I would at least consider shifting approaches somewhere down the line. Yes, there are a plethora of open messaging protocols out there, but adopting one for first party integration doesn't prevent the others from being used.
I agree. The OS maker has a ton of power with the default apps and putting SMS and phone calls as the default communication platform of the OS is contrary to the goals of giving people more privacy.
And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
> And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
This makes no sense especially when you’re comparing it against Apple Pay and Google Wallet. They shouldn’t waste resources on something so pointless. The only exception is if they can actually make an NFC capable app that can handle cards.
A FOSS, private, uncensorable way to pay people instantly anywhere with effectively zero fees is not pointless.
Obviously it isn't a direct substitute for Apple pay but it would be more functionality than we have now.
RCS is a modern replacement for SMS/MMS with end-to-end encryption (E2EE) support via MLS. We have SMS/MMS so we need RCS to replace those. Similarly, carrier-based calls are there and should get replaced with a newer standard with E2EE.
RCS is what GMS Android and iOS provide so that's what people need to talk to non-GrapheneOS users.
Which non-carrier-based messaging app or protocol do you think we should include and why? What happens if we decide that's no longer the best one wand want to get rid of it? Apps included in the OS cannot be easily removed but rather only disabled by default for new installs and phased out for new devices. Otherwise, users would have their working setup break.
Yes I understand your point re: interoperability, and I think you've made a convincing case for RCS.
I think in the short term, you should take a look at e.g. Cheogram, Conversations, and Element and consider ways to enhance integration. Address book integration, automatically extending contact do not disturb exceptions, and maybe even dialer integration.
In the long term, it would be best to try to guage antitrust regulator attitudes wrt to protocols like XMPP and Matrix. In the end, they are the only ones who can really force mass adoption of an open protocol. But alternative OSs having native support and integration for such messaging protocols can tip the scales and be used as evidence of the protocol's viability and legitimacy.
Unless one wants interoperability with other people who use Apple and "Samsung" (because they don't know the word Android refers to an OS). It's a de facto standard now, whether you like it or not.
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.
Sure, but what could graphene do in the meantime? It's either make it work for the moment or stop those apps from working today.
I'd like to see them lay more ground work for web apps but it's a tough spot and the easiest choice at the moment is to continue with AOSP.
I mean we privacy nerds all love webapps but the reality is the people actually in charge of S&P500 companies hate them. They really, REALLY want to fingerprint your device and use it as a verification and tracking mechanism.
Until that changes, webapps aren't going to sell.
Even Google tried multiple things to "sell" the idea of webapps (e.g. Polymer project) in 2011-2015 and failed.
Funny enough, Wechat kinda succeeded at webapps in China because there's a strong user preference to stay inside one monolithic "everything app".
I find, as a user primarily of free and open source software, it’s really the opposite: native FOSS apps have minimal tracking and analytics that defaults to off or is easily disabled, while most free and open source webapps are behind Cloudflare, blocking access to them until I turn off my VPN and disable the anti‐fingerprinting features in my browser.
I don't want to see more groundwork for web apps. GrapheneOS is meant to be secure, which means running trusted apps on-device. My messages are less secure if they permanently are stored on a server.
Yes, but there is no alternative other than giving up. Starting a new OS from scratch with zero apps is a much worse starting point compared to a platform where 99.9% of apps work (minus those relying on Play Integrity with strong integrity) which may have its rug pulled in the future. The race here is about getting to a big enough market share that GrapheneOS cannot just be ignored as completely niche but has to be treated as a small but not insignificant minority.
> Yes, but there is no alternative other than giving up.
Of course there is. Sent from my daily driver Librem 5.
Disclaimer: It is less secure than GrapheneOS, according to the GrapheneOS threat model.
It's not ideal, but in the case a hard fork happens, they could implement the same APIs and most apps will probably continue to work. Similar to how microG is a replacement for Play Services and still works for most apps (not as well as sandboxed Google Play of course).
Above that, not much would change for a few years anyway, because apps still target ancient Android versions.
Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.
Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.
I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.
Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.
And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.
I think graphene could maintain a hard fork with manufacturer support (Motorola). At least for a while. Long term viability is an open question.
They could for a while but what's the point if it's not sustainable? Google is not going to turn around and make it more open again.
With every Android release you will build up more feature base to replicate. Unless you cut all ties and drive a separate ecosystem but good luck getting enough developers to buy into that.
And the US might grow a government with a spine and take Android away from Google. It's all hypothetical.
Well, someone is clearly giving Graphene money, and quite a lot of it, as per TFA:
> We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
Oh yeah I didn't catch that, that's interesting. I wonder where the money is coming from.
Perhaps they're hoping to get significant market share before they lose the opportunity for good?
> Graphene is clearly bullish on Android, but I have no idea why.
Their resources are historically better spent hardening vs literally reinventing the wheel.
Multiple variables in that equation have changed - so it could be interesting where we end up.
Someone (else!) may yet arise chasing their stated model without Android, as well.
So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?
There is no alternative.
Apple isn't going to let them build on top of iOS, and anything except those two is dead in the water because it'll never have users because it is missing a bunch of critical apps, and will never have those apps because it doesn't have users.
Remember when we thought IE's monopoly could never be broken? Or windows?
Anything can and will go down. Nothing is forever.
IE's monopoly was replaced by Chrome and Safari's, and Safari only exists because Apple gives you no choice but to use it on iOS. Firefox had a brief spot on top, but it really didn't last that long.
Windows still has the vast majority share of desktop.
Yes but that's my point. Monopolies don't last. We have other ones now yes. But that's because the earlier ones died.
And yes we still have windows as the major desktop OS but don't forget, in the 90s/early 2000s windows was equivalent to computing.
These days the desktop OS is much less relevant than it was and many people don't even own a laptop or desktop anymore. They just do everything on their phone. And Microsoft totally and completely lost that race.
Chrome is the outlier there. It didn't come with any desktop OS and still got near 100% market share, even before Android contributed to that. How? It's worth studying.
The made the best browser on the planet in Google's Bell Labs era and then they used it as leverage during their "do evil" era.
Well, the web was already designed to be compatible with multiple browsers, so that's one element there.
It wasn't really at that time. IE was really quirky and a lot of sites were tailored to those quirks and failed on standards-compliant browsers :S
IE was a web browser. Breaking it was a matter of making a web browser good and compatible enough.
It's a completely different situation here.
> There is no alternative.
There have been several projects like Ubuntu Touch to create an open Linux for smartphones.
That would be an open alternative.
Android is not open.
The AOSP is fully open source. What you suggest is a significant step back in terms of privacy and security.
The AOSP does not run modern Android apps, since Google has been replacing the APIs those apps require with closed source versions (that only ship as part of Google Play) for over a decade.
That is not true. AOSP can run all modern android apps, and google play APIs are provided as alternatives, but not replacements, for AOSP functionality.
No, that's a widespread misconception. Google Play services is nearly entirely APIs for using Google services. It hasn't replaced AOSP functionality and the AOSP APIs are still there. If you want to avoid Google services then there isn't much that's useful in Play services. Getting developers to not depend as much on Google services such as supporting UnifiedPush in addition to Firebase Cloud Messaging leads to those apps no longer requiring Play services for that functionality.
Android is an open source Linux distribution for smartphones. It doesn't have to be used with Google Mobile Services. AOSP is far more private, secure, usable and compatible with a far broader amount of apps. Why wouldn't we use that as the starting point even if the goal was to diverge?
Which of my banking apps are running on any of these?
FuriLabs makes a Linux phone that is designed as a daily driver. Looking at it to replace Android.
I have it. It's far too slow to be useful, and it's not the hardware's fault. GTK and Libhybris are bad separately and hot garbage together. This problem won't be going away while the hardware is relevant.
Which model of phone from FuriLabs?
That's a huge downgrade for privacy, security, usability, battery life and compatibility with apps. GrapheneOS is Linux too. Linux doesn't mean glibc and systemd. Linux is unfortunately not a great base for an OS focused on privacy and security but it's the only practical choice at this time. In the long term, it needs to be replaced as the bare metal kernel.
Testing the FLX1S for a few weeks as a media player, modern day iPod tool with offline content storage / temp caching. Battery is better than current Android phone. Both have areas of better usability.
I would recommend it as tool for a Linux app designer to use with testing and user improvement. Helps find issue not present on a laptop or desktop. Highlights the difference in solution choices; Python vs Node.js vs Rust.
I'm getting away from Google as far and fast as possible. The sooner the bandaid is pulled the better and more freeing. Google's path with being able to reject those that they don't seem worthy to run on Android, that is a prison.
Personally, I should have root access to the device so that all content which must be archived can be or consumed with another tool; Category Theory. I should have direct access to copying or backing up SMS with ease. Watching the network traffic to know what is actually going through.
Security is also being able for one to learn about the actual operations and test and validate them.
So say you use a USB device to host the kernel boot image which then requires manual password authentication to decrypt physical device drives. Without the USB device, it boots into duress mode.
Duress mode provides a false shell into a working phone. Physical security system do this, by provide false statements of what is going on. Wipe the real stuff in the background if need be.
GraphneOS is using a Linux Kernel. I'm looking for something more Linux Distro style of implementation. Not choosing GraphneOS is pure objective to remove myself from Google and Apple as much as possible in a communication tool.
Android device has become phone and text only. Linux device has become my engagement. Going for a walk without primary communication is peaceful.
This, 100%. It's exactly why I would choose a standard Linux distro any day over GrapheneOS. Biggest reasons for me being:
- No dependency on Google - Actually free and open OS (this means: root access to device, being able to customise any part of the distro/WM/DE, full, low-level access to external devices etc)
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
Waydroid can't run nearly as many Android apps as AOSP on bare metal or especially GrapheneOS with the compatibility features it provides. It's an approach with far more limited compatibility.
Waydroid has very poor privacy and security due to disabling most of the app sandbox. It's also based on an old version of LineageOS so it's missing many important privacy/security updates, but it's much more relevant that it doesn't have SELinux and exposes much more kernel attack surface to apps. SELinux is not an extra layer of security for Android but rather is used in a far more deeply integrated way than any typical desktop/server usage. It's a huge portion of the security model including the app sandbox and protecting the Linux kernel.
We greatly prefer virtual machines over a half-baked container approach disabling most of the privacy/security model. There's already hardware accelerated virtualization on all of the supported devices for GrapheneOS and we plan to make a lot more use of that in the future.
Have you used GrapheneOS? It's fantastic UX[1] and while probably being one of if not the most secure and private OS available.
[1] thanks to Android (once you replace some of the worse default apps, but they are doing that as we can see)
A scratch built mobile operating system have zero chances unless it would be straight up adopted by a cellular carrier, or at least blessed by one.
There's quite a list of mobile operating systems on Wikipedia[1]. Most of them are long dead.
1: https://en.wikipedia.org/wiki/Mobile_operating_system