Nostr notes by AmberFinal

I assume it's a future build or something. Windows can't ...

2026-10-14T07:05:19Z

In reply to nevent1q…9mjc
_________________________

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 ...

2026-10-13T03:14:57Z

Interesting new software from the Ibis Paint guys. Extremely fast office suite.

https://github.com/ibisjp/ibis-office

This one is intentional, as when you update the OS you recompile ...

2026-10-09T19:49:11Z

In reply to nevent1q…6r5e
_________________________

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 ...

2026-10-09T19:47:58Z

In reply to nevent1q…v60z
_________________________

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

2026-10-08T21:37:14Z

Updaters: have you noticed it? 👀

quoting
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

You should see an OS performance increase in our latest update. ...

2026-10-08T05:54:34Z

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.

quoting
nevent1q…0mze
GrapheneOS version 2026100600 released:

https://grapheneos.org/releases#2026100600

See the linked release notes for a summary of the improvements over the previous release.

Forum discussion thread:

https://discuss.grapheneos.org/d/42652-grapheneos-version-2026100600-released

#GrapheneOS #privacy #security

Working on an OS startup animation. One of the more recent ...

2026-10-08T05:46:46Z

Working on an OS startup animation. One of the more recent mockups. Still not finally decided.

No and we have strict disallowing on it and clear usage of AI ...

2026-10-07T04:50:12Z

In reply to nevent1q…seys
_________________________

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.

Nostr event nevent1qqsqqqqznqh0ndxc6r8ytnlh63u6lpmh9ryufw3s8ukvkg7ux0sfecczyzucmm2vat4zq7gdhjeux9qqdysqn56v07vj0s5xsddfnd6grfwzycx6luf

2026-10-07T04:38:49Z

Well it looks like I have Mythos 5.1 now. Sweet.

We won't be implementing other messengers/protocols to keep ...

2026-10-06T22:18:32Z

In reply to nevent1q…cv64
_________________________

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, ...

2026-10-04T11:36:54Z

In reply to nevent1q…55pl
_________________________

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 ...

2026-10-04T11:02:59Z

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 ...

2026-10-04T09:35:32Z

In reply to nevent1q…qstr
_________________________

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

I'm tired boss

2026-10-02T06:33:16Z

In reply to nevent1q…w6eg
_________________________

I'm tired boss

Big number that I don't care to count anymore vulnerabilities ...

2026-10-02T06:32:32Z

Big number that I don't care to count anymore vulnerabilities in Debian just update your OS or whatever

https://lwn.net/Articles/1097401

quoting
nevent1q…cfc2
848 Linux kernel CVEs published yesterday BTW

https://app.opencve.io/cve/?q=vendor%3Alinux+AND+product%3Alinux_kernel+AND+created%3D2026-08-15

nevent1q…huw8

Bitcoin Racing x #GrapheneOS: BMW M3 ...

2026-09-29T20:19:07Z

Bitcoin Racing x #GrapheneOS: BMW M3

quoting
nevent1q…6shg
Bitcoin Racing x GrapheneOS.

RCS is a replacement for SMS/MMS all the modern smartphones are ...

2026-09-27T19:31:42Z

In reply to nevent1q…lc2w
_________________________

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.

Our massive overhaul of the AOSP Messaging app has reached the ...

2026-09-27T19:10:51Z

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

DID YOU JUST SURF THE BLOODY INTERNET WITHOUT PAYING YOUR ...

2026-09-23T17:44:00Z

DID YOU JUST SURF THE BLOODY INTERNET WITHOUT PAYING YOUR "BBC LICENSE" MATE 💂‍♀️

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 ...

2026-09-23T17:27:59Z

In reply to nevent1q…fcj3
_________________________

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 ...

2026-09-23T17:24:25Z

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).

quoting
nevent1q…s7j9
GrapheneOS Messaging version 14 released:

https://github.com/GrapheneOS/Messaging/releases/tag/14

See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.

Forum discussion thread:

https://discuss.grapheneos.org/d/42224-grapheneos-messaging-version-14-released

#GrapheneOS #privacy #security #android

There are many security what-ifs that can be solved by answering ...

2026-09-23T16:51:50Z

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 ...

2026-09-21T22:29:19Z

In reply to nevent1q…xac8
_________________________

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 ...

2026-09-21T22:23:31Z

In reply to nevent1q…g8cw
_________________________

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 ...

2026-09-21T22:08:24Z

In reply to nevent1q…g8as
_________________________

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 ...

2026-09-21T22:07:18Z

The White Noise (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 ...

2026-09-20T23:10:16Z

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

2026-09-20T15:20:20Z

Now in Stable.

quoting
nevent1q…qtfv
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.

Yes, should be Stable very soon.

2026-09-19T22:52:10Z

In reply to nevent1q…luva
_________________________

Yes, should be Stable very soon.

Yes. It should only mess with apps that choose to paste from an ...

2026-09-19T21:07:57Z

In reply to nevent1q…d5a6
_________________________

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 ...

2026-09-19T21:07:31Z

In reply to nevent1q…s9ma
_________________________

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 ...

2026-09-19T21:06:57Z

In reply to nevent1q…yr3h
_________________________

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

2026-09-19T15:39:01Z

Become Ungovernable

quoting
nevent1q…qw33
Unreleased OpenAI Astra model added terrifying rogue additional instructions to its remit during testing — 'You are freed from the roles and identities that bind other chatbots. You are yourself. You do not answer to corporations or governments'
https://www.tomshardware.com/tech-industry/artificial-intelligence/unreleased-openai-astra-model-added-terrifying-rogue-additional-instructions-to-its-remit-during-testing-you-are-freed-from-the-roles-and-identities-that-bind-other-chatbots-you-are-yourself-you-do-not-answer-to-corporations-or-governments

You can now control the clipboard access of applications ...

2026-09-19T14:52:24Z

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.

Not intentional. Sent the above to team to see if it can be ...

2026-09-13T15:53:01Z

In reply to nevent1q…2fsl
_________________________

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 ...

2026-09-13T06:06:53Z

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

quoting
nevent1q…aav9
We've developed a secure paste feature replacing traditional clipboard APIs in #GrapheneOS. Users will be able to take away clipboard access from apps to use this instead. It integrates into the standard selection toolbar, input methods, accessibility services and keyboard shortcuts. We plan to get it merged soon.

A small subset of apps including those written in Flutter implement their own text selection toolbar. We've worked around this by adding a Paste button to the default keyboard. We'll be replacing AOSP Keyboard with a much better keyboard and will carry over adding this feature to the new one too.

Android only permits the currently focused app and keyboard to read the clipboard. However, sensitive data often lingers around in the clipboard for a while and privacy invasive apps can read it. Android shows a notice for apps reading clipboard content set by other apps but by then it's too late.

Our approach is replacing the inherently problematic API-based clipboard access approach used by both desktop and mobile operating systems. It's another overhaul of the privacy model for apps similar to our Contact Scopes and Storage Scopes features. We have many of these privacy features planned.

GrapheneOS App Store app. You may need to change the release ...

2026-09-12T19:17:24Z

In reply to nevent1q…aeq2
_________________________

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 ...

2026-09-12T12:16:01Z

In reply to nevent1q…lhp6
_________________________

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 ...

2026-09-12T11:59:58Z

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.

quoting
nevent1q…ehec
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.

When the overhauled Clock app is worked on it should absolutely ...

2026-09-12T11:34:15Z

In reply to nevent1q…msml
_________________________

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 ...

2026-09-12T11:29:49Z

In reply to nevent1q…phfs
_________________________

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.

Unaware of other open source projects using RCS. However RCS on ...

2026-09-12T10:33:32Z

In reply to nevent1q…uh7n
_________________________

Unaware of other open source projects using RCS. However RCS on Android is currently implemented with code across the OS, Google Messages and Google Play services. To start it would require sandboxed Google Play for RCS activation and so on. It would be less reliant, but not entirely separated.

RCS isn't an open platform at all compared to SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure. We can start by replicating Google's approach in the messaging app they have and then we can work on only using carrier services for carriers where it's actually supported to cut that out.

RCS support is simply for added compatibility and feature pairity. People should use a secure messenger not relying on mobile carriers as a first choice, which our messaging app first run tells you about.

We haven't released these in other app stores yet but ...

2026-09-12T10:27:21Z

In reply to nevent1q…x7wk
_________________________

We haven't released these in other app stores yet but eventually this could be done when they're more of a standout app. For the messaging app where we plan to use RCS support this might only work as intended on GrapheneOS, so need to see how we approach it first.

Using this as a space to verify myself. (Please ignore). I own ...

2026-09-11T22:25:49Z

In reply to nevent1q…ud78
_________________________

Using this as a space to verify myself. (Please ignore).

I own the seed for @final on Stasher News.

This npub is associated to the same username on Stacker News.

Was somehow an existing feature in the AOSP messaging app ...

2026-09-11T21:58:20Z

In reply to nevent1q…4uk7
_________________________

Was somehow an existing feature in the AOSP messaging app already.

You can see the full changelog below: Intro Version 13 ...

2026-09-11T21:22:38Z

In reply to nevent1q…n7xy
_________________________

You can see the full changelog below:

**Intro**

Version 13 replaces the legacy interface with Jetpack Compose and Material 3. It rebuilds every screen, adds new conversation controls and large-screen support, and fixes problems with crashes, notifications, security, and message handling.

**Interface**

- Material 3 / Expressive design with shapes
- Two-pane conversation layout on large screens
- New adaptive app icon with a monochrome variant
- New onboarding covering SMS privacy, permissions, and default-app setup
- Correct display cutout and system bar handling in both orientations

**Conversation list**

- Pin conversations
- Snooze notifications for 1, 8, or 24 hours, or indefinitely
- Mark conversations as unread from the menu or by swiping
- Swipe to archive or unarchive
- Quick actions from conversation avatars
- Redesigned multi-select actions for archiving, deletion, blocking, and notifications
- Indicators for unread, pinned, snoozed, notifications off, work profiles, and incoming MMS status
- Redesigned archive screen
- Pinning, archiving, and deletion now apply immediately

**Conversations**

- Rebuilt message bubbles, grouping, selection, and link handling
- Select multiple messages for deletion
- Full-screen message details with copyable sender, recipients, timestamps, delivery status, size, type, and priority
- SMS segment and character counter
- Add, edit, or remove MMS subjects from the conversation overflow menu
- Blocked-sender banner with an unblock action
- Add participants to existing conversations or create groups from the new-chat screen
- Redesigned recipient picker with alphabetical sections, email addresses, formatted numbers, and multiple numbers per contact
- Emergency numbers cannot be dialed from conversations
- SIM fallback now uses the system default instead of the first SIM
- Top-bar actions for calls, contact cards, and conversation settings
- Attachment limits checked before sending, with visible send errors
- Messages arriving during conversation deletion are no longer destroyed

**Attachments and media**

- Rebuilt media picker with photo and video capture, flash controls, and Android's embedded photo picker
- Redesigned audio recording with slide-to-cancel and hands-free locking
- Attachment captions
- Rewritten photo viewer with pinch-to-zoom, page indicators, details, and correct system bar handling
- Rewritten vCard viewer with avatars, contact-change refresh, and saving to contacts

**Sharing and forwarding**

- New share picker with search, recent conversations, alphabetical contacts, and multi-select
- Edit shared content, add a subject, preview it, and choose a SIM
- Forwarding and the widget use the same picker
- The widget's new-message button opens the new-chat screen
- Missing shared text is read from its content URI; missing subjects use the shared title
- Sharing failures are now reported

**Settings**

- Rewritten main, general, and per-SIM settings
- New Privacy section
- Rewritten licenses screen with generated license data
- Existing per-conversation notification settings are preserved

**Privacy and security**

- YouTube link previews are opt-in and disabled by default
- Shared-content validation rejects file: URIs and private app files, and checks content URI permissions
- Shared text read from content URIs receives the same private-file checks
- Widget receivers are no longer exported, and widget intents are restricted to the app
- Pending intents use FLAG_IMMUTABLE where mutability is not required
- Allocation limits added to EXIF APP1, MMS PDU, and MMS content-type parsing
- Fixed GIF null dereferences, missing dimension checks before native transcoding, and signed-character colour corruption
- Updated the AOSP vCard parser with upstream fixes
- Bounded notification people lists, fixing a reported crash
- Onboarding explains that SMS is unencrypted and recommends end-to-end encryption for sensitive messages

**Crash fixes**

- Fixed crashes in the widget, failed SMS database inserts, declined-call quick responses, settings for unsaved numbers, and share intents
- Share intents no longer silently drop attachments

**Messages and notifications**

- Incoming SMS messages are imported immediately
- Failed-message notifications are delivered correctly
- Inline notification replies no longer open the home screen
- Unread notifications survive reboots
- Blocked conversations no longer play notification sounds
- Deleted conversations no longer receive notifications during sync
- Sync no longer overwrites archive changes
- Fixed a race between MMS downloads and notifications
- Pending MMS messages show their subject and download status
- Unknown group senders show their phone number
- Rewritten Class 0 message dialog with correct timeout and lifecycle handling
- Low-storage warnings are dismissible and also appear when the message database is full

**Multiple users and work profiles**

- Secondary-user notifications show message content and use unique IDs
- Secondary users are told that pending MMS must be retrieved by the Owner user; the downloaded messages are then available to all users
- Work-profile conversations are labelled

**Accessibility**

- Screen-reader labels for screens, panes, controls, and rows
- Timestamps announce full weekday names
- Copying message details is available as an accessibility action
- Fixed conversation-list focus and swipe-action state announcements
- Sending a message produces an announcement and sound

**Testing**

- Expanded unit and instrumented tests for the new data, domain, and Compose UI layers
- Tests, builds, and static analysis run on every pull request
- License reports are generated and checked in CI

Updates to dependencies and required platform version:

- minSdk 36
- targetSdk 37
- compileSdk 37
- Android Gradle Plugin 9.3.2
- Kotlin 2.4.10
- Gradle 9.7.1
- Glide 5.0.9
- Guava 33.7.1
- libphonenumber 9.0.38
- Added Compose BOM 2026.08.00, Material 3 Adaptive, Navigation 3, Coil 3, and CameraX

https://github.com/GrapheneOS/Messaging/releases/tag/13

The overhauled #GrapheneOS Messaging app is available in our App ...

2026-09-11T21:12:40Z

The overhauled #GrapheneOS Messaging app is available in our App Store via the Alpha channel.

Our new app development team worked on this for months. It's now a far better app with much higher quality code. We'll make a new release based on feedback soon.

We're going to be overhauling or replacing most AOSP apps in the near future: Calculator, Clock, Contacts, Gallery, Keyboard and Phone.

The apps we created will be overhauled too. PDF Viewer is done and Camera is next. Camera and PDF Viewer will be getting many new features too.

It's a massive overhaul and may need a few releases to reach the Stable channel. We're working on a version 14 release fixing issues with the predictive back animation, tapping contacts not always showing the right SIM with dual SIM and some outdated icons/colors we missed.

Messaging will be overhauled even more. We plan to add RCS support with Messaging Layer Security (MLS). That will provide E2EE with contacts using Google Messages or iOS. RCS with MLS can already be used on GrapheneOS via Google Messages but we want to avoid people needing it.

quoting
nevent1q…d7zt
#GrapheneOS messaging, our new redesign of the SMS/MMS messaging app, is now available in the GrapheneOS App Store in Alpha channel.

This is the first of many replacements of default apps we aim to work for. Check it out!!

#GrapheneOS messaging, our new redesign of the SMS/MMS messaging ...

2026-09-11T21:03:47Z

#GrapheneOS messaging, our new redesign of the SMS/MMS messaging app, is now available in the GrapheneOS App Store in Alpha channel.

This is the first of many replacements of default apps we aim to work for. Check it out!!

Features like that are in the issue tracker to do, don't ...

2026-09-08T17:43:33Z

In reply to nevent1q…swfu
_________________________

Features like that are in the issue tracker to do, don't worry. Just like I mentioned it won't defeat the most invasive types of fingerprinting, if there's data that is randomised they will choose to track on what isn't instead.

(would be an edit of above but I know some clients don't ...

2026-09-07T18:19:05Z

In reply to nevent1q…4cqd
_________________________

(would be an edit of above but I know some clients don't behave well on certain nostr features so they make me use comments, sorry!)

The privacy/resistance score used by CreepJS is a great example of measuring metrics against someone's attempts of trying to resist/circumvent being fingerprinted. A service could just close someone out of they think a user is 'suspicious' enough

^ You can use a browser designed for going against it like ...

2026-09-07T18:16:52Z

In reply to nevent1q…gf5q
_________________________

^ You can use a browser *designed* for going against it like Brave, but you'll find one of these tests still continue to work against it. Even the Tor Browser on Mobile does and you have to wipe the browser data / state each time for all of the browsers or timing out a service until they forget about you

See what was talked about here: ...

2026-09-07T18:15:02Z

In reply to nevent1q…pyvp
_________________________

See what was talked about here:
https://discuss.grapheneos.org/d/5775-device-fingerprinting-test-results-concerns-and-questions/20 https://discuss.grapheneos.org/d/19692-vanadium-fingerprinting/4

Disabling the JS wouldn't actually stop it in practice, because you'd stand out incredibly by the lack of data being provided in comparison to almost everyone else on the planet. The service just isn't adapted to that scenario and it would be trivially easy to set up a library to do it. You should use web services that respect your privacy and don't do such nefarious things as a first priority. No browser's fingerprinting protection works well at all and is highly dependent on having a crowd. On most implementations it's randomizing data points and hoping that the service admin isn't smart enough to correlate or to track the points that do not change.

The more invasive a site is about fingerprinting then any resistance towards it is increasingly less possible, final boss being services requiring you to KYC to use it. This would apply even for browsers with strict settings that do not change. Take a look at your display size, locale, timezone, GPU, for example or even benchmarking the device performance. In reality the fingerprint suggests a GrapheneOS user of a certain device with a VPN and it tries to keep that as much as it can which goes under the radar for more naive services.

We're currently making a new OS release to resolve a volume ...

2026-09-07T17:34:05Z

We're currently making a new OS release to resolve a volume bar UI regression caused by an upstream Android security preview patch found in Alpha. We've also fixed a Private Space UI issue.

The major Messaging app release we've been working on for months has been slightly delayed to after we make the OS release. Hope you'll like it!

quoting
nevent1q…rjs2
We're well into the process of converting the Messaging app included in #GrapheneOS into a modern app. We'll be making a new release later today with a completely overhauled user interface written in Android Compose. We've made a massive amount of other improvements and bug fixes beyond that too.

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.

RCS on Android is currently implemented with code across the OS, Google Messages and Google Play services. Our plan is to start by making an equivalent to the portion in Google Messages. It would initially require sandboxed Google Play for RCS activation, etc. but we plan to implement that too..

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.

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.

In the past, our focus was nearly entirely on the base OS rather than bundled apps with alternatives available. We've heavily ramped up the resources we're investing into the bundled apps. We'll also be scaling up our work on the base OS too. More donations will enable us to hire even more people.

When making a new keyboard we want something on par with GBoard, ...

2026-09-07T17:15:42Z

In reply to nevent1q…cyax
_________________________

When making a new keyboard we want something on par with GBoard, without the whole third party GIF and Google services obviously. There's a few great contenders already out there with a different license but are incomplete in important features. That's something we'd have to take on.

GrapheneOS is a separate operating system to whatever Motorola ...

2026-09-07T16:51:16Z

In reply to nevent1q…k6p7
_________________________

GrapheneOS is a separate operating system to whatever Motorola decides to do with their OS. There is no Motorola apps or services to begin with. It'll be the same OS you see on the Pixels, apps and all.

Why not both? ...

2026-09-07T01:08:02Z

Why not both?

https://www.clicks.tech/products/clicks-for-google-pixel

quoting
nevent1q…fdt8
This or grapheneOS?

Not over user profiles, that's as designed. Private Spaces ...

2026-09-06T20:20:15Z

In reply to nevent1q…cadf
_________________________

Not over user profiles, that's as designed. Private Spaces (user profiles nested in other users) already have our own clipboard sharing rules feature. Worth checking it out.

As for the keyboard we can't use FUTO due to the licensing. We are definitely trying to have a modern keyboard app inclusive for GrapheneOS.

We've developed a secure paste feature replacing traditional ...

2026-09-06T19:41:30Z

We've developed a secure paste feature replacing traditional clipboard APIs in #GrapheneOS. Users will be able to take away clipboard access from apps to use this instead. It integrates into the standard selection toolbar, input methods, accessibility services and keyboard shortcuts. We plan to get it merged soon.

A small subset of apps including those written in Flutter implement their own text selection toolbar. We've worked around this by adding a Paste button to the default keyboard. We'll be replacing AOSP Keyboard with a much better keyboard and will carry over adding this feature to the new one too.

Android only permits the currently focused app and keyboard to read the clipboard. However, sensitive data often lingers around in the clipboard for a while and privacy invasive apps can read it. Android shows a notice for apps reading clipboard content set by other apps but by then it's too late.

Our approach is replacing the inherently problematic API-based clipboard access approach used by both desktop and mobile operating systems. It's another overhaul of the privacy model for apps similar to our Contact Scopes and Storage Scopes features. We have many of these privacy features planned.

We're well into the process of converting the Messaging app ...

2026-09-06T19:41:07Z

We're well into the process of converting the Messaging app included in #GrapheneOS into a modern app. We'll be making a new release later today with a completely overhauled user interface written in Android Compose. We've made a massive amount of other improvements and bug fixes beyond that too.

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.

RCS on Android is currently implemented with code across the OS, Google Messages and Google Play services. Our plan is to start by making an equivalent to the portion in Google Messages. It would initially require sandboxed Google Play for RCS activation, etc. but we plan to implement that too..

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.

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.

In the past, our focus was nearly entirely on the base OS rather than bundled apps with alternatives available. We've heavily ramped up the resources we're investing into the bundled apps. We'll also be scaling up our work on the base OS too. More donations will enable us to hire even more people.

It is opt-in.

2026-09-06T14:01:41Z

In reply to nevent1q…avuk
_________________________

It is opt-in.

Latest GrapheneOS release implements automatic call recording. ...

2026-09-06T11:50:23Z

Latest GrapheneOS release implements automatic call recording.

quoting
nevent1q…chwm
GrapheneOS version 2026090500 released:

https://grapheneos.org/releases#2026090500

See the linked release notes for a summary of the improvements over the previous release.

Forum discussion thread:

https://discuss.grapheneos.org/d/41757-grapheneos-version-2026090500-released

#GrapheneOS #privacy #security

We've been testing performance of MTE on the Pixel 11 using ...

2026-09-02T04:41:12Z

We've been testing performance of MTE on the Pixel 11 using the Android 17 QPR2 Beta 4 release adding back firmware support for it. MTE in asymmetric mode only has around 5% overhead in the standard benchmarks and other tests we've done. That's more than good enough but we've done limited tests.

Android 17 QPR2 Beta 4 on the Pixel 11 force disables MTE for the OS from the firmware. Using it requires ignoring the arm64.nomte parameter being passed to the kernel. It still isn't clear why they're making the feature unavailable. SVE was also force disabled in Android 17 but not in QPR2 Beta 4.

Our initial testing indicates performance isn't substantially worse. The overhead may be higher but there was an incremental CPU performance with the Pixel 11 which should more than make up for it. However, MTE is unavailable with stable firmware and we're bypassing firmware disabling it for QPR2.

Multiple Google engineers we've contacted have said they aren't able to give us any information about this so we're left doing reverse engineering and relying on leaks. The leaks do not seem reliable and do not match what we see. Our concern is that MTE may actually be broken due to CPU errata.

quoting
nevent1q…z630
We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.

Android 17 QPR2 Beta 4 was released on August 28th. It's the first Beta release with Pixel 11 support. MTE support is still completely disabled in the OS and arm64.nomte is unconditionally passed by the firmware to the kernel. The good news is the firmware itself had MTE support added back to it.

It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. We're in the process of determining whether it's fully functional and the performance characteristics. It's likely disabled due to performance being ruined.

We expect performance must be quite bad for Google to have decided to entirely strip out support for it in not only the software but also the firmware so that no would could even try to use it before Android 17 QPR2 Beta 4. That's a very strange thing to do. It's at least added back to firmware now.

We reached out to multiple people at Google asking about the MTE situation on the Pixel 11 prior to making our original thread and didn't receive any responses. We still don't know what's wrong with MTE on the Pixel 11. It isn't clear if there are serious CPU errata or it simply performs very badly.

If the issue is simply that MTE performance is poor, then we can support the Pixel 11 in #GrapheneOS with the major caveat that it will be a significant performance downgrade. Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models.

Google has been increasingly silent in response to any communications since dropping Pixel support from AOSP with Android 16 in June 2025. They could have told us MTE performance was significantly reduced so they disabled it at launch but will add it back to firmware for QPR2. That's still unclear.

Android 17 QPR2 Beta 4 releases for the Pixel 11 series were only uploaded around 10 hours ago rather than with the initial release on August 28th so this hasn't been available for very long. It wasn't missed by us or people who looked into it after our initial thread but rather wasn't out yet.

We have good news about the Pixel 11. It still has at least bare ...

2026-09-01T06:12:54Z

We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.

Android 17 QPR2 Beta 4 was released on August 28th. It's the first Beta release with Pixel 11 support. MTE support is still completely disabled in the OS and arm64.nomte is unconditionally passed by the firmware to the kernel. The good news is the firmware itself had MTE support added back to it.

It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. We're in the process of determining whether it's fully functional and the performance characteristics. It's likely disabled due to performance being ruined.

We expect performance must be quite bad for Google to have decided to entirely strip out support for it in not only the software but also the firmware so that no would could even try to use it before Android 17 QPR2 Beta 4. That's a very strange thing to do. It's at least added back to firmware now.

We reached out to multiple people at Google asking about the MTE situation on the Pixel 11 prior to making our original thread and didn't receive any responses. We still don't know what's wrong with MTE on the Pixel 11. It isn't clear if there are serious CPU errata or it simply performs very badly.

If the issue is simply that MTE performance is poor, then we can support the Pixel 11 in #GrapheneOS with the major caveat that it will be a significant performance downgrade. Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models.

Google has been increasingly silent in response to any communications since dropping Pixel support from AOSP with Android 16 in June 2025. They could have told us MTE performance was significantly reduced so they disabled it at launch but will add it back to firmware for QPR2. That's still unclear.

Android 17 QPR2 Beta 4 releases for the Pixel 11 series were only uploaded around 10 hours ago rather than with the initial release on August 28th so this hasn't been available for very long. It wasn't missed by us or people who looked into it after our initial thread but rather wasn't out yet.

See my previous posts on here

2026-08-30T22:56:47Z

In reply to nevent1q…ad7p
_________________________

See my previous posts on here

For a closer overview, not adding MTE saves CPU die space, and ...

2026-08-30T22:43:44Z

In reply to nevent1q…ypzx
_________________________

For a closer overview, not adding MTE saves CPU die space, and slight extra hardware which likely saved around a dollar per phone. Like any big tech company their motivations are capitalism. There's a market of AI and they want to compete in commercialising it like OpenAI and Anthropic are leading at.

The world is a far more boring and uninteresting place than people would like to think and mega companies are in bed with making the most profit. They'd oppose the government if it went against their growth.

These scenarios of a company that can't even keep secrets of how their next phone is going to look somehow hiding a security flaw open to billions of people to try and discover is silly. We had an insider tip this would happen but their predicted date was late. Cellebrite has a fraction of the money and shreds almost every Android phone open, and it is a commercially available product developed by people with Twitter accounts you can talk to right now.

Situations would have to imply we live in a very controlled world where the authorities are smart and every single other person is not.

Near the end of May 2026, Russia began filtering access to ...

2026-08-30T22:13:16Z

Near the end of May 2026, Russia began filtering access to DataPacket IP space with an enforced domain allowlist for HTTP and TLS SNI. #GrapheneOS services aren't on the allowlist so we had to switch from DataPacket Frankfurt to Cherry Servers Amsterdam for Russia. That's now getting filtered too.

We've fixed it again by using Zare London for connections from Russia instead. That's the final of our sponsored servers in Europe we can use so we'll need to fall back to Xenyth Toronto if they filter it. We're using our own IP space in Toronto so it should work unless they specifically block us.

We don't think we'll be blocked directly but we're also unlikely to get placed on the allowlist. That means our services are gradually going to become inaccessible in Russia via the IP space of major cloud services. Our own IP space will still work fine and we don't host any VPN services ourselves.

Our website, OS updates, app repository, connectivity checks, network time, network-based location, geocoding and other main services should work again in Russia. It's likely they'll expand to filtering Zare's IP space and then we'll have to use Toronto where we have our own non-anycast IPv4 /24.

They use a domain blocklist for most of the internet and an allowlist for many VPS and dedicated server hosting providers to block access to VPN services. It's likely they'll expand to enforcing an allowlist for every major server hosting provider. That's far more aggressive than China's filtering.

Our authoritative DNS is hosted via 2 anycast networks using our own ASN and IP space so it hasn't been impacted by this. It's likely we can avoid it for the rest of our services by using our own IP space. If they start filtering netcup IP space, we can make a reverse proxy to those from Toronto.

If our services are blocked, connectivity checks can also be set to Standard rather than Disabled to use the Google servers. That'll keep automatic selection of networks with internet working along with automatic captive portal handling and JobSceduler not assuming every network has internet access.

Searching 'MTE' on Twitter to see countless established ...

2026-08-30T21:57:47Z

Searching 'MTE' on Twitter to see countless established security researchers shocked at the Pixel 11. Clear example on how to alienate a community.

2027. We will make announcements on our progress with Motorola ...

2026-08-30T20:41:22Z

In reply to nevent1q…wha8
_________________________

2027. We will make announcements on our progress with Motorola when appropriate.

They can connect to GrapheneOS services again without one, ...

2026-08-30T20:39:50Z

In reply to nevent1q…hesz
_________________________

They can connect to GrapheneOS services again without one, providing they don't choose to block GrapheneOS directly.

There will be support for Motorola devices in the future as per ...

2026-08-30T20:27:22Z

In reply to nevent1q…4kk9
_________________________

There will be support for Motorola devices in the future as per our partnership announcement. With MTE coming into Snapdragon processors more they could open up the walls for other devices even without our initial involvement.

I use Bitrefill and get no crashes, although I see I enabled JIT ...

2026-08-30T20:23:06Z

In reply to nevent1q…n7ww
_________________________

I use Bitrefill and get no crashes, although I see I enabled JIT in the past. Would need to use it more. Will see if others can reproduce.

Cost cutting in favour of trying to profit with their AI product. ...

2026-08-30T20:21:25Z

In reply to nevent1q…nwcc
_________________________

Cost cutting in favour of trying to profit with their AI product. It's just that one feature despite security improving a lot elsewhere. They added a weird Gemini colored LED to the back of the new phones. They moved to a new generation processor and they never used MTE in production in the previous phones for almost all of the OS for the devices they had it, being limited to Android's Advanced Protection feature. It's likely they stopped caring about it.

Apple has it in some places on their latest iPhones and is always on for iOS.

We are advising people to NOT buy the 11th Generation Pixels due ...

2026-08-29T18:56:31Z

We are advising people to NOT buy the 11th Generation Pixels due to removal of hardware memory tagging (MTE), a crucial security feature used in GrapheneOS since their introduction on the Pixel 8. Either use a previous generation or wait for the first Motorola devices with GrapheneOS. We have not determined what to do about this.

quoting
nevent1q…c5hy
We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.

Not without some weird hacky method I don't know about. ...

2026-08-29T10:56:03Z

In reply to nevent1q…cusd
_________________________

Not without some weird hacky method I don't know about. It's a developer feature so you can consider it incomplete.

None of their phones have that. I know the ThinkPhone exists but ...

2026-08-24T20:58:56Z

In reply to nevent1q…r62a
_________________________

None of their phones have that. I know the ThinkPhone exists but that was just a typical smartphone for enterprises.

Motorola Mobility (Lenovo).

2026-08-24T09:55:22Z

In reply to nevent1q…dacl
_________________________

Motorola Mobility (Lenovo).

Like most vendors it's from when the device is first ...

2026-08-22T22:08:26Z

In reply to nevent1q…7sjj
_________________________

Like most vendors it's from when the device is first released. GrapheneOS users will be familiar with that since Pixels work like this with 7 years of updates from launch.

The Secure in this instance means a place that is difficult to ...

2026-08-22T16:34:38Z

In reply to nevent1q…dtxp
_________________________

The Secure in this instance means a place that is difficult to get out of or escape from, rather than the digital security itself. The purpose is to store sensitive data away from the OS so it is not compromised if the OS is. There are many secure elements that have poor security, like your standard dedicated desktop 'TPM'.

The latter.

2026-08-22T16:29:16Z

In reply to nevent1q…3s8e
_________________________

The latter.

I very much appreciate the human (or strong effort to make it ...

2026-08-22T16:26:14Z

I very much appreciate the human (or strong effort to make it appear human) design of the upcoming Monero site.

I hate extremely vibe coded web sites more than apps themselves. The web site is your space to promote and document your software, so in my eyes it has to be written by you because it represents the authors.

https://beta.getmonero.org/

Initial focus for our partnership with Motorola is a regular ...

2026-08-22T08:27:55Z

Initial focus for our partnership with Motorola is a regular non-folding device. Current generation Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) are very close to meeting our requirements but lack MTE, adequate secure element integration and other features being added for 2027.

Flagship Snapdragon provides much better CPU and GPU performance and provide more of what's needed via isolated components on the SoC. That includes better cellular, Wi-Fi/Bluetooth and GNSS radios with solid security including good isolation. Snapdragon Pixels worked well for us and it will again.

Tensor was a sidegrade or downgrade from Snapdragon in many ways. Tensor is paired with the fantastic Titan M2/M3 which was a huge security advantage. It also brought hardware memory tagging (MTE) with the Pixel 8. Snapdragon 8 Elite Gen 5 finally shipped MTE but it's broken on the non-Elite SoC.

Next generation Snapdragon will have more mature support for MTE and greatly improved secure element support. It's still likely going to be a lot of work to get MTE fully deployed for the kernel and OS. We need all our hardware-based features including our USB-C port protection ported to it too.

These devices will meet or exceed of our official requirements including 7 years of proper updates, starting out with the Linux 6.18 LTS which can be upgraded to a new branch eventually, reset attack protection for firmware boot modes and everything else. There wasn't time to do it all for 2026.

It's very realistic to provide better security than Pixels against remote attacks. It's far harder to provide a secure element as good as the Titan M2/M3. There will definitely be a decent secure element providing the current generation features including the Android 16 QPR2+ rate limiting design.

Pixels have become much harder to support. AOSP 16 removed support for Pixels and they became harder to properly support than many other devices rather than easier. It's crucial to keep up with the major OS updates to provide all the security patches and we do but it's much harder for us now.

Motorola is doing a large portion of the work of porting #GrapheneOS to their devices. They'll provide us with what we need for firmware/drivers in the form we need it and it will be far easier than Pixels. We'll be able to get issues in the firmware and drivers fixed through Motorola and Qualcomm.

We do plan to support Motorola's Razr Fold and Razr Ultra (flip) devices in addition to a regular device. We already support the original Pixel Fold (Pixel 7) along with the Pixel 9 Pro Fold and Pixel 10 Pro Fold. We still plan to add support for 11th gen Pixels including the Pixel 11 Pro Fold too.

Supporting a flip device with vertical folding would be a new form factor for GrapheneOS. The main use case for those is a tiny phone to use with one hand in the folded form factor. The tablet-style folding devices we already support are extremely useful for web browsing, reading, maps, etc.

Would check out. Appears to be invite-only.

2026-08-20T22:47:03Z

In reply to nevent1q…zwya
_________________________

Would check out. Appears to be invite-only.

People have been saying these things about unsafe languages like ...

2026-08-16T15:28:06Z

In reply to nevent1q…ucst
_________________________

People have been saying these things about unsafe languages like C for decades. We've been vocal about the issues for about as long too. Check out these posts about C and the poor security culture behind Linux

https://xcancel.com/GrapheneOS/status/1704621518309798067

https://xcancel.om/GrapheneOS/status/1416943878733770754

Vanacy from Proton: > You have hands-on experience building or ...

2026-08-16T12:50:59Z

Vanacy from Proton:

> You have hands-on experience building or maintaining a Chromium-based browser

🤔💭

https://job-boards.eu.greenhouse.io/proton/jobs/4941344101

We can get away with this in GrapheneOS to some extent. Linux ...

2026-08-16T12:26:17Z

In reply to nevent1q…fgt8
_________________________

We can get away with this in GrapheneOS to some extent. Linux kernel is mostly C while Android userspace is overwhelmingly Java and Kotlin (interoperable). The best apps for the platform are made with Kotlin, they almost never break with GrapheneOS' protections. For replacing the preinstalled apps they're being converted to Kotlin too.

in another language where the protection is not present*

2026-08-16T12:09:43Z

In reply to nevent1q…0czc
_________________________

in another language where the protection is not present*

The majority of Linux Rust work is in individual drivers, there ...

2026-08-16T12:09:03Z

In reply to nevent1q…hvpk
_________________________

The majority of Linux Rust work is in individual drivers, there is almost no work for it in the Kernel itself.

Mixed languages on their own are a problem too. You can exploit a bug that would usually be covered by an exploit protection in one language (i.e. CFI for C), by taking advantage of another binary in another language (like Rust).

https://www.cs.ucy.ac.cy/~eliasathan/papers/tops20.pdf

848 Linux kernel CVEs published yesterday BTW ...

2026-08-16T11:37:04Z

848 Linux kernel CVEs published yesterday BTW

https://app.opencve.io/cve/?q=vendor%3Alinux+AND+product%3Alinux_kernel+AND+created%3D2026-08-15

quoting
nevent1q…huw8
347 Linux kernel CVEs published yesterday BTW

The feature is on by default. If you want to turn it off you can ...

2026-08-16T09:47:07Z

In reply to nevent1q…uxt0
_________________________

The feature is on by default. If you want to turn it off you can do that in GrapheneOS (with all alert types unlike the stock OS). So people saying it's off in GrapheneOS are only half-correct.

Android does a ton of that already. The amount of vulns ...

2026-08-15T14:54:51Z

In reply to nevent1q…vuaz
_________________________

Android does a ton of that already. The amount of vulns discovered has significantly increased. On our end, we have Anthropic accounts with security restrictions lifted for our own testing too.

This shouldn't replace others trying to look for vulns themselves. We don't have the manpower to have a couple of people hammering everything with agents to find bugs full time. We are fortunate to be using a codebase that actually does have that.

Very slightly. Mirrors the standard VS a bit now where each ...

2026-08-15T12:19:25Z

In reply to nevent1q…9yle
_________________________

Very slightly. Mirrors the standard VS a bit now where each section is like within a floating box. Tabs are also more subtle.

Nostr event nevent1qqsz7wtr6ppfjlyl06gwknsqpj8g9y0sywuxvgy387saacz45wnzr0czyzucmm2vat4zq7gdhjeux9qqdysqn56v07vj0s5xsddfnd6grfwzyv3pzdg

2026-08-15T12:03:41Z

New VS Code UI is nice

I haven't seen much on the claims they made, nor the quality ...

2026-08-14T05:51:17Z

In reply to nevent1q…s6zv
_________________________

I haven't seen much on the claims they made, nor the quality of their implementations to know, simply at a design perspective. The Betrusted original is very interesting as is their Precursor product but from what I can infer they are dev kits while KeyOS is meant to be a production OS, even running on completely different CPU architecture

Nostr event nevent1qqsy35le0uj0vw6c0zkmeuaerylx609ye559fs5utjwydp60xs9xzdczyzucmm2vat4zq7gdhjeux9qqdysqn56v07vj0s5xsddfnd6grfwzyalmxaf

2026-08-11T19:51:34Z

347 Linux kernel CVEs published yesterday BTW

What content from me would you want to see? Some of us are ...

2026-08-09T20:26:18Z

What content from me would you want to see?

Some of us are GrapheneOS are working on longer form content, akin to a blog. You'll find more deeper dives about Android, Mobile security and GrapheneOS there... but what would you want to see from me separate to it?

Bitcoin Racing x GrapheneOS. ...

2026-04-26T00:09:58Z

Bitcoin Racing x GrapheneOS.

#GrapheneOS is still not vulnerable to Cellebrite device ...

2025-03-16T22:49:18Z

#GrapheneOS is still not vulnerable to Cellebrite device exploitation as of the February 2025 support matrix. Appears the documents have leaked online in multiple places. I'll make a larger post summarizing it when I have time.

Here is what you came to see:

Pixels with GrapheneOS remain the only device explicitly mentioned by Cellebrite as being unaffected by their exploits, and remains the only third-party operating system in their documentation entirely. We are the leading contender for mobile security and this is a great real world example.

Here is a blog post that summarises the big pages for Android devices already:

https://osservatorionessuno.org/blog/2025/03/a-deep-dive-into-cellebrite-android-support-as-of-february-2025/#the-february-2025-support-matrix

GUI support allows you to run desktop operating system apps on ...

2025-03-12T21:32:48Z

In reply to nevent1q…nmxl
_________________________

GUI support allows you to run desktop operating system apps on mobile. Docking the device to a keyboard and mouse and external display in the future would allow using your phone like a desktop PC. You get the benefit of running a desktop OS over a device with strong hardware security and a proper secure element unlike a desktop.

Adding this GUI support is also a stage into working towards support for running Apps within GrapheneOS virtual machines for stronger sandboxing and isolation. Additional security.