Top
Best
New

Posted by Cider9986 13 hours ago

GrapheneOS Overhauled Default Apps and Secure Clipboard(grapheneos.social)
293 points | 211 comments
yellowapple 4 hours ago|
> 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.

teekert 2 hours ago||
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?

lucb1e 11 hours ago||
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.

grapheneos 5 hours ago||
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.

minitech 11 hours ago|||
https://grapheneos.social/@GrapheneOS/117225731764489295

https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v

XenoCyber0 9 hours ago||
[dead]
goda90 12 hours ago||
I believe this is the planned gallery app. I've already been using it: https://github.com/IacobIonut01/ReFra
grapheneos 6 hours ago||
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.
aussieguy1234 10 hours ago||
Just tried this out. I may soon be cancelling by Google Photos subscription...
ticoombs 7 hours ago||
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

ravenstine 11 hours ago||
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.
Cider9986 11 hours ago||
I agree FUTO is the best right now but it's not open source so they won't.
arximboldi 9 minutes ago|||
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
Groxx 10 hours ago||||
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.

mrob 10 hours ago|||
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

Groxx 9 hours ago||
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.

grapheneos 6 hours ago||
Immich doesn't use the FUTO license because they acquired it and it was already under a copyleft open source license.
idle_zealot 10 hours ago||||
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.

mitxela 8 hours ago||
Alternatively they could ask FUTO for a commercial license.
HybridStatAnim8 8 hours ago||
Maybe, but there are better candidates GrapheneOS is more interested in.
jazzyjackson 10 hours ago|||
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?
wolvoleo 9 hours ago|||
[dead]
dsr_ 11 hours ago|||
Heliboard is good, customizable, and actually open source - GPL3.
HybridStatAnim8 8 hours ago|||
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.

sha666sum 1 hour ago||
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.
sublinear 10 hours ago|||
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.

prmoustache 4 hours ago|||
Autosuggestions are nice to have but there is no autocorrection that really works well in my experience regardless of OS.
NewJazz 10 hours ago||||
I turn off automatic autocorrect except for "I". I can use it manually when I need it (jot often).
armadyl 10 hours ago|||
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.

broodbucket 10 hours ago|||
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.
hellcow 3 hours ago|||
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.

MrDrMcCoy 8 hours ago||||
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.
Cider9986 2 hours ago||
Same. Used to use GBoard, not FUTO is as good so no reason to.
dns_snek 3 hours ago|||
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.
Geezus_42 9 hours ago|||
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.
HybridStatAnim8 8 hours ago|||
They cannot. The license FUTO uses is not open source and is incompatible with being bundled with GrapheneOS.
matheusmoreira 10 hours ago|||
Why not Unexpected Keyboard?
yellowapple 4 hours ago||
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.
mightysashiman 2 hours ago||
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.
Cider9986 13 hours ago||
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

kotaKat 12 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."

Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt Jive?

benwaffle 8 hours ago|
None except Jio in India and various carriers in China
andrepd 12 hours ago||
There are excellent FOSS gallery apps already, like the Fossify suite. Why not use them I wonder?
grapheneos 7 hours ago||
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.
HybridStatAnim8 12 hours ago|||
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.

graemep 11 hours ago|||
Its not part of the OS so why would it affect the Graphene OS license? Its an app, not a library.
HybridStatAnim8 7 hours ago|||
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.
Cider9986 11 hours ago|||
The preinstalled apps are part of the OS.
gray_-_wolf 10 hours ago|||
That cannot be true, when I install e.g., Ubuntu system, there are plenty of applications installed for me, with incompatible licenses.
grapheneos 7 hours ago|||
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.

Cider9986 5 hours ago||
There's 5 licenses :o
novafunc 9 hours ago||||
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 4 hours ago|||
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.

exceptione 47 minutes ago||
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.

HybridStatAnim8 7 hours ago|||
It is true, and if Ubuntu is shipping apps as a part of the OS with incompatible licenses, that is a crime.
microtonal 3 hours ago|||
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.)

Cider9986 6 hours ago|||
Not a crime a civil matter.
yjftsjthsd-h 10 hours ago|||
IANAL, but I would expect that to fall under "mere aggregation"
gkoz 11 hours ago|||
Can the Linux kernel be included in the OS?
grapheneos 7 hours ago|||
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.
HybridStatAnim8 7 hours ago||||
Yes, the GPLv2 license does not have the same restrictions GPLv3 does, it does not necessitate making the code it is bundled with GPLv2.
microtonal 3 hours ago||
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)

palata 10 hours ago|||
Linux is GPLv2, though. Not sure if that makes a difference here.
DANmode 9 hours ago||
Media handlers are a security nightmare, might lead you to the right answer if it isn’t it.
drnick1 11 hours ago|
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.
grapheneos 8 hours ago||
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...

bigstrat2003 4 hours ago||
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.
Cider9986 11 hours ago||
[flagged]
grapheneos 8 hours ago|||
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.

Cider9986 7 hours ago|||
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.

montyanne 2 hours ago|||
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.

gib444 1 hour ago||
Agreed
gib444 1 hour ago|||
You need to stop the flagging ring operation of any mild questioning or criticism Daniel – it's a very bad look for the project, and also against the acceptable behaviour on this site

Flagging is not for what you perceive to be incorrect information or things you disagree with or to shut down conversation. You always reply to a comment to clear it up – that's enough. And of course organised flagging is totally unacceptable.

There are enough instances now I will compile a list and email the moderators who can hopefully correct your behaviour

BearOso 9 hours ago|||
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.
grapheneos 8 hours ago||
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

More comments...