Posted by Cider9986 14 hours ago
> 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.
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.
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.
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.
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?
Oof, so it was essentially destined to fail when the spec was being written.
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.
> 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
The whole saga with VoLTE was really quite entertaining: https://nickvsnetworking.com/background-to-the-volte-mess/
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.
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.
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.
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.
- 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.
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.
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.
-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.
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!
Why are you strawmanning?
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.
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.
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.
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?
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.
I do miss keyboard symbols without shifting and icon packs.
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.
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 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?
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.
Many 3rd party platforms are still better though.
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)
Our feature is designed for people to comply with the law in jurisdictions requiring two party consent. It shows a notice for every inbound and outbound call where call recording will be enabled. It also has a per-contact toggle for enabling it instead of simply being either enabled or disabled. We also plan to offer the option to have it automatically disclose the call is being recorded.
There are other ways to record calls such as enabling speaker mode and using another device to record the audio. It's similar to apps trying to prevent users from taking screenshots. It fundamentally doesn't work.
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.
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.
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".
Above that, not much would change for a few years anyway, because apps still target ancient Android versions.
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.
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.
> We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
Yes Google wants android to be secure, but the problem is that to be truly secure it should be secure from Google too. And they don't want that. They want it to be their personal datamine and walled garden. Just like Apple with ios.
Google is the one making bad actions, which it makes sense to complain about. They moved to building in private so forks don't get features as they come and more recently they stopped providing certain source code in a timely manner.
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.
Anything can and will go down. Nothing is forever.
Windows still has the vast majority share of desktop.
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.
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.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
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.
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.
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.
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.
Obviously it isn't a direct substitute for Apple pay but it would be more functionality than we have now.
There's quite a list of mobile operating systems on Wikipedia[1]. Most of them are long dead.
[1] thanks to Android (once you replace some of the worse default apps, but they are doing that as we can see)
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.
GrapheneOS offers a duress PIN/password, not button, that is solely up to the user to use as they see fit. The threat model for its use is on the user to determine, and the example you are referring to was a judgement that person made. That decision is independent of GrapheneOS.
Whether or not it was a blunder can only be known by the person who used it. Maybe it was a miscalculation, or maybe they were trying to hide something of importance, like protected contacts in an authoritarian country. We cannot know.
Duress PIN is for when the consequences of having the data are worse than erasing the data. This is very important for journalists or citizens of an authoritarian government. The judgements these people make are not a reflection of GrapheneOS.
https://github.com/GrapheneOS/Messaging/pulls?q=is%3Apr+is%3...
Every release of GrapheneOS and GrapheneOS apps goes through internal testing followed by public Alpha channel testing and then public Beta channel testing before reaching the Stable channel. No update goes to Stable without internal, Alpha and Beta channel testing phases.
We've been heavily testing our Messaging overhaul as we've been doing it and we've been making a lot more tests than we used to. It's already in quite good shape and is ready for Alpha channel testing. That's what we're referring to.
You can check github and see this development has been going on for awhile.