Last Notes
I assume it's a future build or something. Windows can't in the second version.
Interesting new software from the Ibis Paint guys. Extremely fast office suite.
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/d97c01bddc36e09af97967a29dfee36e869821532aee02e48daad007eab007d3.png
https://github.com/ibisjp/ibis-office
This one is intentional, as when you update the OS you recompile apps that have been changed at runtime. This would usually be done just-in-time but it is ahead of time in GrapheneOS for security purposes.
For those wondering. Boot animations can be split to an intro, a loop, and an outro. What you're seeing is an intro and the loop artificially repeated a few times. Once the OS is ready to start, that loop will be interrupted, so you do not need to worry about boot speed.
Updaters: have you noticed it? 👀
#nevent1q…0r0a
You should see an OS performance increase in our latest update. In upcoming releases there will be much more too including a way to possibly decrease memory usage from our secure app spawning feature.
#nevent1q…0mze
No and we have strict disallowing on it and clear usage of AI generated writing/media. Frontier AI models across many providers are mostly used for reviewing human authored code for issues.
Well it looks like I have Mythos 5.1 now. Sweet.
We won't be implementing other messengers/protocols to keep the platform agnostic for whatever users choose to use. RCS is just to be closer to the Stock OS in capability but we wouldn't recommend people to use that for sensitive communications, hence the warning when you first open Messaging.
Shouldn't be much of an issue after release 2026100200, although Pixels aren't the best phones for this either.
Android 17 QPR1 was released for Pixels on September 15. It has a regression in the Pixel kernel driver tree causing stuttering, lag and outright freezes under memory pressure. It impacts #GrapheneOS too since we updated the firmware/drivers but now we fixed it ourselves.
Google is taking increasingly long to implement and ship fixes for major issues in Android. We're having to expand our workload to include handling basic updates, testing and quality control for the entire operating system. We have rapidly growing resources and we'll handle it.
Pixel 11 series received a bug fix release near the start of September 2026 with the 2026-09-01 patch level. That update wasn't Android 17 QPR1 and also doesn't include the September 2026 Pixel firmware/driver security patches. Perhaps they noticed this issue and cancelled it.
Standard Android and Pixel updates have a severe issue with delays. It usually takes 2-3 months for Google to ship fixes for both severe regressions and security issues. They often get the issues fixed in days but the release engineering and testing process is completely broken.
Major Android releases including Android 17 QPR1 go through a long public testing period. It typically takes Google at least around 4 to 6 weeks to ship fixes for even the most severe issues. They either cancel the release (Pixel 11) or ship a broken release (everything else).
Here's our fix for the awful Android 17 QPR1 regression causing lag, stuttering and freezes:
https://gitlab.com/grapheneos/kernel_pixel_6.6/-/commit/ed5a9b87d99b45618fa55b3d6b53094cbd784b9f
It's so severe that it's causing processes to be killed for stalls. It's unclear when Google will ship a fix for the issue. December 2026 wouldn't be a surprise.
Due to this major Android 17 QPR1 regression, we've been looking into reducing memory usage. We found a way to eliminate most extra memory use from our secure spawning feature without any significant downsides. We'll try to get that huge improvement shipped before November 2026.
Nope, the sole developer has other priorities they want to work on before renovating the user facing app. They also work on changes in different branches of the repo, so all the latest changes do not go to `main` branch until production.
See their blog from a couple of days ago:
https://accrescent.app/blog/posts/a-tale-of-too-many-protocols/
Most of their work is building a delta updates library and backend server for app submissions.
https://github.com/accrescent/server
https://github.com/accrescent/ina
Big number that I don't care to count anymore vulnerabilities in Debian just update your OS or whatever
https://lwn.net/Articles/1097401
#nevent1q…cfc2
It could be implemented in the future as an enhancement.
Bitcoin Racing x #GrapheneOS: BMW M3
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/5eaa2b13005d3b1a208044ad5911a841bcf6df30b703f25a7a4f8658775b4e4e.jpg
#nevent1q…6shg
Lifelong 'Grand Theft Auto' fan excited to play the first 'Grand Theft Auto' game released in his lifetime
It's a brand new feature. Just a couple updates ago. Paste Only is not the default setting for compatibility. You already get alerts for if an app used the clipboard anyhow so you know which ones misbehave.
We mentioned we will work on having this not depend on Play Services eventually, which would then depend on carriers' support instead.
People should be using a secure instant messenger app over SMS/MMS or RCS in general anyway, as you wouldn't be depending on having your phone connected to a carrier just to use that service.
RCS is a replacement for SMS/MMS all the modern smartphones are incorporating that has end to end encryption of message contents (note: see privacy issues with cellular providers overall). The issue is they're not as open as the predecessor.
if support for RCS begins with a Play Services requirement, then people who don't install RCS will only have SMS/MMS, it's that simple. We won't be bundling Google apps or services into GrapheneOS. They need to choose it.
What's the point of it? Will RCS become a standard of chat across all mobile os'es? But if yes we can't rely on play store services.
@nprofile…radp exists as a messenger with MLS end-to-end encryption with Nostr as an identity/network layer. These RCS services depend on carrier infrastructure too.
Our massive overhaul of the AOSP Messaging app has reached the Stable channel in our App Store after 3 releases. It's well on the way to becoming our own high quality #GrapheneOS Messaging app instead. There are still parts of the interface to overhaul including widgets and important features to add.
Full support for RCS with all of the additional features it brings including proper group chats, media, opt-in read receipts and much more is going to be the largest project. We'll also be adding RCS end-to-end encryption via Messaging Layer Security (MLS) compatible with Google Messages and iOS.
RCS support will be provided via an optional dependency on sandboxed Google Play for activation. In the longer term, we plan to make a fully standalone implementation requiring the carrier to support it. We probably won't make an alternate implementation of using Google's own system for this.
Finishing the user interface overhaul, resolving many minor issues and adding important features including search are going to be the priority before getting to RCS. In the meantime, Google Messages is already fully supported on GrapheneOS including RCS with E2EE via MLS:
https://grapheneos.org/usage#rcs
This is the announced. No information to provide yet on when we will actually support the phone. Wait for when there is official announcements.
Yes, it's in the issue tracker. New features can be implemented when the overhaul of all the existing app functionality is considered complete
Side of Burritos released a video demonstrating a malicious app with no added permissions compared to stock Android collecting clipboard data automatically. Our new clipboard control features in GrapheneOS protects such a thing from happening.
https://youtube.com/watch?v=tGTwnru_9ZU
DID YOU JUST SURF THE BLOODY INTERNET WITHOUT PAYING YOUR "BBC LICENSE" MATE 💂♀️
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/fc76cd4719e80afb9898e31eba86b009edfe17aeb8c099f3540ccfb1258d7305.jpg
https://inews.co.uk/news/bbc-licence-fee-could-scrapped-for-internet-charge-4782353
I don't use a Fitbit to know. I wouldn't use any of these items if they required internet access to begin with.
(I replied to this slowly, I don't see all replies easily because Le Nostr)
This update adds on many bug fixes and significantly improves the performance of our overhauled default SMS / MMS messaging app, most notably, large conversations (tested to 80k texts) now open 350x faster than before (~0.10 seconds from over 35 seconds).
#nevent1q…s7j9
There are many security what-ifs that can be solved by answering "POCs or GTFO" by the way.
They weren't raiding synogogues rather synagogues were apparent victim targets.
(I have little to say on this matter beyond the vetted response in the article)
Yes, used Amethyst since I started. Not used Dark Wisp to know but I guess I'll just take your word for it.
This also leads me to mention Phoenix Wallet, while I do not use it so much, it's developed in a similar fashion and it was lightning FAST. I miss using it!
The @nprofile…radp app transition to Kotlin and Jetpack Compose is really good. It's such a smooth, fast messenger. Even more so when I expect most apps relating to Nostr or BTC to be quite sluggish. There is a significant leap in usability for apps that are designed for a platform's native language and libraries.
Get free pentesting by designing your new web app frontend with Bootstrap 1.0 so it looks old and unmaintained
Now in Stable.
#nevent1q…qtfv
@nprofile…cw4j any clue how this is handled in Graphene?
#nevent1q…cx4n
Yes, should be Stable very soon.
Yes. It should only mess with apps that choose to paste from an external app automatically for whatever reason.
The default is just as it is on AOSP for now. The other setting is Paste only which blocks that access.
Scroll down and it should be there. If its not, you likely don't have the latest update distributed and you should have it installed soon.
Become Ungovernable
#nevent1q…qw33
You can now control the clipboard access of applications individually in #GrapheneOS. This makes apps only able to see data if the user manually pasted it, with exception of the clipboard item originating from the same app attempting to paste.
You can go into Settings -> Security and Privacy in Owner to control clipboard access globally.
You can also go into individual applications in any profile to control that individual app's access.
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/24a6fdb462fc182e8e81069c0cb4cf041f28d6534f89d31ac71fa3d92600c9c5.jpg
Not intentional. Sent the above to team to see if it can be recreated. Some VPN apps may not be playing well to the tighter leak protection. I assume User Profiles are fine?
Secure paste has been merged into #GrapheneOS to provide a replacement for focused apps being able to read the clipboard:
https://github.com/GrapheneOS/platform_frameworks_base/pull/435
#nevent1q…aav9
GrapheneOS App Store app. You may need to change the release channel to get it early (see the three dots at the top right).
GrapheneOS is open source so we expect access to that code to be available to anyone including who we don't like. There have been malicious forks. Someone could easily mirror the code to GitHub had it not been there already. Someone can also automated mirror the repos from our GitHub and GitLab elsewhere if they don't like the platforms.
For a lot of open source projects, finding the talent is harder than funding. GrapheneOS is getting kinda popular now so there's a fan base and funding behind it even if it comes at a consequence of getting mentioned on mainstream news for clicks and hype.
The best developers are obviously living the dream with big tech salaries which no one can blame them for taking it. We have enough to hire multiple people, it's just they need to fit what developers want and have the GrapheneOS attitude and 'culture'.
When it comes to open source software, the corporates funded with state money who want to find vulnerabilities in your software for their advantage are often far more qualified, resourceful and committed to their objectives than the limited project developers are.
You must be more cautious about having both a secure design and a secure implementation of the design of your software at the earliest possible stage of software development. This increases the time and effort to discover a vulnerability or can close out entire classes of vulnerabilities. We have seen how massive projects are weighted down from development standards of the late 90s and 00s that makes them have thousands of CVEs every release.
https://www.phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000
Check out some of the open-source AI tooling from Cellebrite to improve their workflows and automate in researching mobile device vulnerabilities.
https://github.com/cellebrite-labs/ghidra-rpc
https://github.com/cellebrite-labs/ida-bridge
https://github.com/cellebrite-labs/ida-docs
https://github.com/cellebrite-labs/ida-porter
You can have opinions on the issues of LLMs (and I have several), but that comes with having to accept an adversary is accelerating how to harm you with that technology.
#nevent1q…ehec
When the overhauled Clock app is worked on it should absolutely be, it's just the AOSP apps are that old from when standards of what Kyiv was a mess. There's also some time zones that are missing there.
You can see the individual pull requests for how many people have worked on the app and that there's people discussing what to do. There's people involved in every step or the development testing for quality. Here's the largest:
https://github.com/GrapheneOS/Messaging/pull/109
The leading apps dev has around a decade and a half of experience in developing on the Android platform alone. His contributions so far have been incredible.
We have a broad access to many LLMs for security testing, including cyber-enabled models for dual-use. It's not actually writing the code of GrapheneOS much. It would be poor to willingly dumb ourselves down when companies such as Cellebrite are devoting teams to creating AI tooling to reverse engineer mobile devices to try and exploit them.
