GrapheneOS Overhauled Default Apps and Secure Clipboard
Posted by Cider9986 1 day ago
Comments
Comment by yellowapple 1 day ago
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.
Comment by teekert 1 day ago
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?
Comment by lucb1e 1 day ago
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.
Comment by grapheneos 1 day ago
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
We posted it right after the Messaging app thread but they're separate topics.
Comment by minitech 1 day ago
Comment by XenoCyber0 1 day ago
Comment by goda90 1 day ago
Comment by grapheneos 1 day ago
Comment by throawayonthe 1 day ago
Comment by aussieguy1234 1 day ago
Comment by ticoombs 1 day ago
One of the best solutions I've ever used for photos, backups, enrichment, etc
Comment by Cider9986 21 hours ago
Comment by ravenstine 1 day ago
Comment by Cider9986 1 day ago
Comment by Groxx 1 day ago
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.
Comment by mrob 1 day ago
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.
Comment by Groxx 1 day ago
Thank you for the details! That lays it out nicely for anyone else passing through.
Comment by grapheneos 1 day ago
Comment by ravenstine 1 day ago
Comment by idle_zealot 1 day ago
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.
Comment by mitxela 1 day ago
Comment by HybridStatAnim8 1 day ago
Comment by Redster 21 hours ago
Comment by HybridStatAnim8 20 hours ago
Comment by Redster 11 hours ago
Comment by jazzyjackson 1 day ago
Comment by arximboldi 1 day ago
Comment by wolvoleo 1 day ago
Comment by dsr_ 1 day ago
Comment by HybridStatAnim8 1 day ago
If you mean it as a user installed app, please disregard.
Comment by sha666sum 1 day ago
Comment by HybridStatAnim8 20 hours ago
Comment by microtonal 2 hours ago
The GPLv3 only applies to a work and works derived from it, so either if you take an existing GPLv3 project and modify it or if you link against a GPLv3 project. In these cases, the other code needs to be under licenses that are compatible with the GPLv3.
This is clearly described in 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.
Comment by bityard 19 hours ago
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.
Comment by sublinear 1 day ago
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.
Comment by NewJazz 1 day ago
Comment by prmoustache 1 day ago
Comment by armadyl 1 day ago
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.
Comment by broodbucket 1 day ago
Comment by hellcow 1 day ago
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.
Comment by b112 1 day ago
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...
Comment by MrDrMcCoy 1 day ago
Comment by fph 19 hours ago
Comment by dns_snek 1 day ago
Comment by nicman23 22 hours ago
Comment by Geezus_42 1 day ago
Comment by HybridStatAnim8 1 day ago
Comment by matheusmoreira 1 day ago
Comment by yellowapple 1 day ago
Comment by Gander5739 1 day ago
Comment by mightysashiman 1 day ago
Comment by ImJamal 20 hours ago
Comment by Cider9986 1 day ago
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
Comment by butz 23 hours ago
Comment by Cider9986 23 hours ago
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.
Comment by nicman23 22 hours ago
Comment by kotaKat 1 day ago
Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt Jive?
Comment by benwaffle 1 day ago
Comment by zerozerotwo 19 hours ago
Comment by ruslan 1 day ago
Comment by andrepd 1 day ago
Comment by grapheneos 1 day ago
Comment by HybridStatAnim8 1 day ago
Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.
Comment by graemep 1 day ago
Comment by HybridStatAnim8 1 day ago
Comment by kasabali 17 hours ago
Comment by Cider9986 1 day ago
Comment by gray_-_wolf 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by Cider9986 1 day ago
Comment by novafunc 1 day ago
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.
Comment by grapheneos 1 day ago
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.
Comment by exceptione 1 day ago
I guess it will make your life much easier if you wouldn't have to restrict yourself that much.
Comment by grapheneos 21 hours ago
Comment by xorcist 16 hours ago
It's hard to take this seriously when the entire kernel is GPL.
Comment by HybridStatAnim8 1 day ago
Comment by microtonal 1 day ago
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.)
Comment by HybridStatAnim8 20 hours ago
When it comes to AOSP/GOS, bundled apps are not aggregated together, they are built and signed under a singular OS binary.
Comment by Cider9986 1 day ago
Comment by yjftsjthsd-h 1 day ago
Comment by gkoz 1 day ago
Comment by grapheneos 1 day ago
Comment by palata 1 day ago
Comment by grapheneos 20 hours ago
Comment by HybridStatAnim8 1 day ago
Comment by microtonal 1 day ago
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)
Comment by grapheneos 20 hours ago
Comment by mitxela 15 hours ago
Comment by DANmode 1 day ago
Comment by exceptione 1 day 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.
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(?)Comment by cosmic_cheese 1 day ago
Comment by jeroenhd 1 day ago
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".
Comment by glub 1 day ago
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?
Comment by mitxela 1 day ago
Comment by glub 1 day ago
Oof, so it was essentially destined to fail when the spec was being written.
Comment by mitxela 1 day ago
Comment by microtonal 1 day ago
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.
Comment by microtonal 1 day ago
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.
Comment by HybridStatAnim8 1 day ago
Comment by Groxx 1 day ago
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.
Comment by ufmace 21 hours ago
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.
Comment by jazzyjackson 1 day ago
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.
Comment by bronson 1 day ago
Comment by ebb_earl_co 1 day ago
> 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
Comment by wolvoleo 1 day ago
Comment by MrDrMcCoy 1 day ago
Comment by wolvoleo 1 day ago
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.
Comment by snazz 1 day ago
The whole saga with VoLTE was really quite entertaining: https://nickvsnetworking.com/background-to-the-volte-mess/
Comment by mitxela 1 day ago
Comment by snazz 1 day ago
Comment by wolvoleo 1 day ago
Comment by fc417fc802 1 day ago
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.
Comment by HybridStatAnim8 1 day ago
Comment by exceptione 1 day ago
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.
Comment by HybridStatAnim8 20 hours ago
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.
Comment by george_perez 1 day ago
To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
Comment by fc417fc802 1 day ago
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.
Comment by HybridStatAnim8 1 day ago
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.
Comment by exceptione 1 day ago
Comment by annzabelle 1 day ago
Comment by SoftTalker 1 day ago
Comment by michael-bey 1 day ago
Comment by exceptione 1 day ago
- 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.
Comment by mitxela 1 day ago
Comment by exceptione 1 day ago
Comment by HybridStatAnim8 1 day ago
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.
Comment by microtonal 1 day ago
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.
Comment by nemomarx 1 day ago
Comment by bronson 1 day ago
Comment by hollow-moe 1 day ago
Comment by mitxela 1 day ago
Comment by yellowapple 1 day ago
Comment by kevin_thibedeau 1 day ago
Comment by grapheneos 1 day ago
Comment by microtonal 1 day ago
-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.
Comment by bentley 1 day ago
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!
Comment by microtonal 1 day ago
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.
Comment by jeroenhd 1 day ago
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.
Comment by cesarb 1 day ago
Comment by Telaneo 1 day ago
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.
Comment by Groxx 1 day ago
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?
Comment by kevin_thibedeau 1 day ago
Comment by microtonal 1 day ago
Comment by Groxx 18 hours ago
But once it landed in Zuck's hands, I no longer trust it one bit. Abandon ship.
Comment by ajjahs 20 hours ago
Comment by drnick1 1 day ago
Comment by grapheneos 1 day ago
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...
Comment by bigstrat2003 1 day ago
Comment by ajjahs 20 hours ago
Comment by Cider9986 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by Cider9986 1 day ago
It seems obvious to me that you guys would use it responsibly.
Comment by montyanne 1 day ago
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.
Comment by gib444 1 day ago
Comment by gib444 1 day ago
Comment by grapheneos 22 hours ago
Your account is persistently engaging in inappropriate personal attacks towards our founder. It's inappropriate to keep dropping someone's personal name who has never participated with their name on this site even aside from the personal attacks.
You're seeking out threads with discussion about GrapheneOS to post misleading and inaccurate claims about it in order to troll. You previously set your profile bio to a hostile remark towards the GrapheneOS project and have now changed it to pretend to be a GrapheneOS supporter.
Flagging personal attacks, harassment content, trolling, AI slop, engagement bait, shady advertising for products and deliberate attempts to mislead people is an appropriate use of the feature from our perspective.
We've been reaching out to the Hacker News moderation team for a while to discuss the years of libelous personal attacks and harassment content posted on the site. They can reach out to us at contact@grapheneos.org where we can discuss that.
Comment by gib444 4 hours ago
More world salad to distract. No sources.
I'll send you some proof that my device is running GrapheneOS btw. How would you like to arrange that?
Yes my support of the project is variable, highly influenced by how it is run and how the directors act on social media. The project does not have a right not to be criticised and that includes the people running it. It's the flip side of the coin of engaging in a public forum
"HN is a community—users should have an identity that others can relate to" – it's not designed for corporate PR accounts. We all know it's you purely by your style of writing and persecution complex
Comment by BearOso 1 day ago
Comment by grapheneos 1 day ago
Comment by il-b 1 day ago
Comment by hn8726 1 day ago
Comment by cwillu 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by HybridStatAnim8 1 day ago
Comment by Walf 1 day ago
Comment by chasil 1 day ago
I do miss keyboard symbols without shifting and icon packs.
Comment by epihelix 1 day ago
Comment by IshKebab 1 day 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?
Comment by Dusseldorf 1 day ago
Comment by annzabelle 1 day ago
Comment by wolvoleo 1 day ago
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.
Comment by HybridStatAnim8 1 day ago
Many 3rd party platforms are still better though.
Comment by goda90 1 day ago
Comment by NamTaf 1 day ago
Comment by downrightmike 1 day ago
Comment by annzabelle 1 day ago
Comment by grapheneos 1 day ago
Comment by wolvoleo 1 day ago
Comment by annzabelle 1 day ago
Comment by grapheneos 1 day ago
Comment by water-drummer 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by water-drummer 1 day ago
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!
Comment by thinkp26 1 day ago
Comment by subscribed 1 day ago
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)
Comment by TZubiri 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by TZubiri 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by gib444 1 day ago
Comment by grapheneos 22 hours ago
> But I guess most of the low-hanging fruit has been solved by the mainstream OS, so a new OS has to take all of the dirty work no one else would touch in order to be relevant. Godspeed
Here's a statement which was made earlier and wasn't necessarily trolling:
> I also find it quite poetic that GrapheneOS seems to be against surveillance, yet they are for it, when it's in their favour of course.
However, it was confirmed to be in their follow up reply:
> > One of the parties involved in a call recording it is not surveillance
> I do agree in principle, and would even argue for it. But in many states it's just not what the law is.
Here's our response to what you've pasted in response to multiple of our replies:
Comment by gib444 1 day ago
Comment by grapheneos 22 hours ago
Comment by vancekai 1 day ago
Comment by Unified-Mentor 23 hours ago
Comment by pizzaiolo 1 day ago
Comment by mitxela 1 day ago
Comment by Crestwave 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by ConceitedCode 1 day ago
Comment by qurren 1 day ago
Comment by ConceitedCode 1 day ago
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.
Comment by qurren 1 day ago
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".
Comment by bentley 1 day ago
Comment by mitxela 1 day ago
Comment by ulrikrasmussen 1 day ago
Comment by fsflover 17 hours ago
Of course there is. Sent from my daily driver Librem 5.
Disclaimer: It is less secure than GrapheneOS, according to the GrapheneOS threat model.
Comment by microtonal 1 day ago
Above that, not much would change for a few years anyway, because apps still target ancient Android versions.
Comment by wolvoleo 1 day ago
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.
Comment by ConceitedCode 1 day ago
Comment by wolvoleo 1 day ago
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.
Comment by epihelix 1 day ago
> We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
Comment by wolvoleo 1 day ago
Comment by unrented7977 1 day ago
Comment by matheusmoreira 1 day ago
Comment by wolvoleo 1 day ago
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.
Comment by grapheneos 1 day ago
Comment by wolvoleo 18 hours ago
Comment by Cider9986 1 day ago
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.
Comment by grapheneos 1 day ago
Comment by kllrnohj 1 day ago
Comment by tgsovlerkhgsel 1 day ago
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.
Comment by wolvoleo 1 day ago
Anything can and will go down. Nothing is forever.
Comment by tgsovlerkhgsel 19 hours ago
It's a completely different situation here.
Comment by ryan_lane 1 day ago
Windows still has the vast majority share of desktop.
Comment by mitxela 1 day ago
Comment by unrented7977 1 day ago
Comment by terribleperson 1 day ago
Comment by wolvoleo 6 hours ago
Comment by wolvoleo 1 day ago
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.
Comment by GeekyBear 1 day ago
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.
Comment by grapheneos 1 day ago
Comment by HybridStatAnim8 1 day ago
Comment by GeekyBear 1 day ago
Comment by grapheneos 1 day ago
Comment by HybridStatAnim8 1 day ago
Comment by tgsovlerkhgsel 19 hours ago
Comment by yndoendo 1 day ago
Comment by grapheneos 1 day ago
Comment by yndoendo 22 hours ago
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.
Comment by d3Xt3r 16 hours ago
- 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)
Comment by NewJazz 1 day ago
Comment by wolvoleo 1 day ago
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
Comment by grapheneos 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by NewJazz 1 day ago
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.
Comment by grapheneos 1 day ago
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.
Comment by NewJazz 21 hours ago
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.
Comment by Cider9986 1 day ago
And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
Comment by armadyl 1 day ago
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.
Comment by Cider9986 1 day ago
Obviously it isn't a direct substitute for Apple pay but it would be more functionality than we have now.
Comment by Walf 1 day ago
Comment by numpad0 1 day ago
There's quite a list of mobile operating systems on Wikipedia[1]. Most of them are long dead.
Comment by palata 1 day ago
Comment by Cider9986 1 day ago
[1] thanks to Android (once you replace some of the worse default apps, but they are doing that as we can see)
Comment by DANmode 1 day ago
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.
Comment by dataflow 1 day ago
Comment by TZubiri 1 day ago
Comment by HybridStatAnim8 1 day ago
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.
Comment by mitxela 1 day ago
Comment by 0points 1 day ago
Comment by grapheneos 1 day ago
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.
Comment by HybridStatAnim8 1 day ago
You can check github and see this development has been going on for awhile.