Final

Operations staff @ GrapheneOS Foundation.

Posts my own and not endorsed by my employer. AI slop and Nostr DMs ignored.

Email: [email protected]
Matrix: f1nal:grapheneos.org

Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

NIP-05 Address

[email protected]

Profile Code

nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsppamhxue69uhkummnw3ezumt0d5qs6amnwvaz7tmwdaejumr0dstg9rtd

Publishing to

nostr.mom

nos.lol

nostr.bitcoiner.social

relay.mostr.pub

Author Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

Show more details

Last Notes

2026-09-12 12:16:01 UTC

- reply

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

2026-09-12 11:59:58 UTC

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

2026-09-12 11:29:49 UTC

- reply

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.

2026-09-12 10:33:32 UTC

- reply

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.

2026-09-12 10:27:21 UTC

- reply

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.

2026-09-11 22:25:49 UTC

- reply

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.

2026-09-11 21:12:40 UTC

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.
#nevent1q…d7zt

2026-09-11 21:03:47 UTC

#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!!
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/d811b40a6bdf940ff89a8dd5a3c3008afd8f7daafdead66a2184e18dfb5213cb.jpg

2026-09-08 17:43:33 UTC

- reply

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.

2026-09-07 18:19:05 UTC

- reply

(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

2026-09-07 18:16:52 UTC

- reply

^ 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

2026-09-07 18:15:02 UTC

- reply

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.

2026-09-07 17:34:05 UTC

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!
#nevent1q…rjs2

2026-09-07 17:15:42 UTC

- reply

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.

2026-09-07 16:51:16 UTC

- reply

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.

2026-09-07 01:08:02 UTC

Why not both?
https://www.clicks.tech/products/clicks-for-google-pixel
#nevent1q…fdt8

2026-09-06 20:20:15 UTC

- reply

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.

2026-09-06 19:41:30 UTC

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.

2026-09-06 19:41:07 UTC

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.

2026-09-06 14:01:41 UTC

- reply

It is opt-in.

2026-09-06 11:50:23 UTC

Latest GrapheneOS release implements automatic call recording.
#nevent1q…chwm

2026-09-02 04:41:12 UTC

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.
#nevent1q…z630

2026-09-01 06:12:54 UTC

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.

2026-08-30 22:56:47 UTC

- reply

See my previous posts on here

2026-08-30 22:43:44 UTC

- reply

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.

2026-08-30 22:13:16 UTC

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.

2026-08-30 21:57:47 UTC

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

2026-08-30 20:41:22 UTC

- reply

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

2026-08-30 20:39:50 UTC

- reply

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

2026-08-30 20:27:22 UTC

- reply

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.

2026-08-30 20:23:06 UTC

- reply

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.

2026-08-30 20:21:25 UTC

- reply

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.

2026-08-29 18:56:31 UTC

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.
#nevent1q…c5hy

2026-08-29 10:56:03 UTC

- reply

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

2026-08-24 20:58:56 UTC

- reply

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

2026-08-24 09:55:22 UTC

- reply

Motorola Mobility (Lenovo).

2026-08-22 16:34:38 UTC

- reply

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

2026-08-22 16:29:16 UTC

- reply

The latter.

2026-08-22 16:26:14 UTC

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/

2026-08-22 08:27:55 UTC

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.

2026-08-20 22:47:03 UTC

- reply

Would check out. Appears to be invite-only.

2026-08-16 15:28:06 UTC

- reply

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

2026-08-16 12:50:59 UTC

Vanacy from Proton:
> You have hands-on experience building or maintaining a Chromium-based browser
🤔💭
https://job-boards.eu.greenhouse.io/proton/jobs/4941344101

2026-08-16 12:26:17 UTC

- reply

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.

2026-08-16 12:09:43 UTC

- reply

in another language where the protection is not present*

2026-08-16 12:09:03 UTC

- reply

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

2026-08-16 11:37:04 UTC

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

2026-08-16 09:47:07 UTC

- reply

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.

2026-08-15 14:54:51 UTC

- reply

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.

2026-08-15 12:19:25 UTC

- reply

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

2026-08-15 12:03:41 UTC

New VS Code UI is nice

2026-08-14 05:51:17 UTC

- reply

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

2026-08-12 23:23:59 UTC

- reply

The Xous distro that the Passport Prime uses has the right idea from a design standpoint. Microkernel, memory safe languages used throughout, mandatory sandboxing for apps. Xous is mostly designed for embedded systems. Obviously implementation is a different thing to rate compared to just the design. I also haven't looked into the hardware as much. I would take it as one of the better offerings the HWW market has right now.
Secureblue has a server distro, hardened CoreOS. I would assume a lot of these bitcoin one-click server dashboard distros aren't as hardened to such an extent. Perhaps it's a room for improvement for these projects.
A lot of defence corps sell their own OSes with the above as marketing, 'STOP OS' by BAE Systems comes to mind. Good luck being able to copy of it yourself though.

2026-08-12 02:19:20 UTC

- reply

Linux has had days where hundreds of CVEs come up at once for a while. I reposted times it's happened before. It's not so unique.

2026-08-12 02:15:25 UTC

- reply

I'll get heat for this but I don't believe in the David vs. Goliath narrative people have for Linux as some sort of bastion against 'big tech'. It's one of the most used OS/kernels in the world, mostly by big tech and their employees motivate most of its development. It's only because it's open source.
I think if people cared enough about competition they'd invest it into improving things like Qubes OS, Secureblue (a novel hardened Linux distribution) or a jump to newer OSes like making Redox OS more available to people.

2026-08-12 02:10:49 UTC

- reply

The hardware macOS runs on is far more secure than other laptop/desktop platforms and macOS is the only OS available for it which uses most of the hardware-based security features. The issue is you're completely hard locked on Apple then. Choosing a desktop OS today is a losing battle.
Desktop OSes in general fall behind on adding security design / features that have been researched for decades. Linux distributions are incredibly behind on this and no one should be expected to configure things like SELinux to make it comfortable. Linux is a gigantic monolithic kernel written almost entirely in a memory unsafe language. It's good to have many vulns but having hundreds discovered over days will become unsustainable.
A lot of the mobile OSes started development decades after the desktop, there was far more research on secure OS design by that point and so a better foundation to run on.

2026-08-11 19:51:34 UTC

347 Linux kernel CVEs published yesterday BTW

2026-08-10 07:38:26 UTC

One of the so-called 'missing' CVEs (CVE-2015-6609) was discovered by the founder and original lead developer of GrapheneOS in *2015*. The methodology here was so poor it is making false measurements for vulnerabilities the project disclosed.
https://source.android.com/docs/security/bulletin/2015-11-01#acknowledgements
#nevent1q…qypy

2026-08-09 21:27:38 UTC

- reply

Seen this actually, this is good! But it's about half of what I want. I'd have to cut out a lot of the test / recommendation fluff. Id want a search result to go straight to a visual map than a big grading system and recommendations list. Big sidebar on the right for the wallet/tx info.
I want to easily make many different types of visualisations and maps for transactions and wallets, have them exportable for documents and other media. I've been ripping off of Chainalysis' own coverage and mempool for inspo.
https://www.chainalysis.com/blog/violent-crypto-wrench-attacks-2026/

2026-08-09 21:08:38 UTC

Amazing we don't have a major open competitor to Chainalysis reactor. We have explorers, but nothing to such a level. When it comes to visualisation it seems top notch, and you need excellent visuals when doing incident reviews. Id love to have an explorer that also was bundled with aliases, (public) identifiers for addresses and so on.

2026-08-09 20:26:18 UTC

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?

2026-08-09 20:04:44 UTC

- reply

When building something I also do give it the same one quick check. If you build a threat model (architecture diagram and a list of threats and countermeasures you implemented against them) it can provide some excellent detail. Even if someone isn't security conscious, the more it knows about your software the better.

2026-08-09 20:00:25 UTC

I think Bitcoin Design doesn't get enough attention, so I want to give it some, as I am using it for reference myself.
https://bitcoin.design/

2026-08-09 19:55:04 UTC

- reply

I am not into podcasts but this one was really good. The Mempool Research coverage on this was excellent.

2026-08-07 19:33:43 UTC

This paper is inaccurate slop. It makes a large number of clearly inaccurate claims about GrapheneOS and presents results which are verifiably false. It's filled with nonsense which appears AI generated. > The Clone Strikes Back: Efficient Vulnerable Code Detection in Custom Android-based Systems
The authors wrongly believe GrapheneOS has diverged from the Android Open Source Project (AOSP). The starting point for GrapheneOS is the latest stable release of AOSP with all of the AOSP security backport commits applied. Our changes to AOSP repositories are maintained as cleanly rebased patches.
Our AOSP changes are reviewed and improved on an ongoing basis. It's not only the code being improved but also commit structure. We're always preparing for porting to the next stable release. It's handled as if our AOSP changes are being prepared for submission to the project for the first time.
We start fresh with each stable release of AOSP. All our changes are ported to the new source tree. There's no merging process but rather porting and submitting the changes to the new source tree. Major changes are often required including entirely rewriting certain features for the new release.
This entire paper is based around a misconception. The authors wrongly believe we need to identify and incorporate all of the upstream changes into GrapheneOS. It's our changes we need to make sure to fully and correctly port to each new release of AOSP, not the other way around as they believe.
The authors should have seen that each of releases has all of our changes to AOSP repositories cleanly rebased on top of the latest stable release. We do make substantial changes to AOSP but it can all be reviewed as a set of patches applied on top of the latest AOSP release with zero merge commits.
Android Security Bulletins are a list privacy and security patches backported to older releases of the OS. These aren't the privacy and security fixes made in the development branch but rather incomplete backports. Far more fixes made in the development branch and the approach is often different.
Android's development branch can do major refactoring and rewrites. It can make privacy and security improvements requiring substantial changes to the code. It can fix weaknesses requiring backwards incompatible changes. The backports don't even attempt to cover Low and Moderate severity patches.
The authors of the paper took the diffs from the Android Security Bulletins and created tooling to look for the changes made by those diffs being missing. They present the findings where they manually confirmed lines of code don't appear to be present as if those are missing patches in GrapheneOS.
They should have easily figured out GrapheneOS releases are based on the latest AOSP release. They should have used their tooling on AOSP itself as a control. They would have gotten the same results for AOSP and GrapheneOS if they used versions from the same date. Instead, they're misleading people.
If they checked the latest AOSP release at the time, they would have seen there's no actual difference in what their tooling finds between AOSP and GrapheneOS. The code they identified as not present in GrapheneOS wasn't in the latest AOSP release at the time. It also doesn't show anything is wrong.
Many of the security issues fixed by Android for older releases aren't present in recent releases due to rewrites and changes to the code. Fixes in the development branch are often difficult to backport with major changes or entirely different approaches being needed. Backports are their own thing.
It's common for the initial attempt at fixing a privacy and security issue to be incomplete or incorrect. These changes sometimes even introduce new vulnerabilities. There are often multiple rounds of partial fixes. Truly fixing it often requires major changes or rewrites impractical to backport.
This paper is built around an incorrect understanding of how GrapheneOS is based on AOSP and Android's security patches. All of the patches included in Android at the time were shipped by GrapheneOS. If any of what they found was an actual issue, which is doubtful, then it was missing in AOSP too.
Aside from the incorrect premise and methodology, the paper is filled with many other inaccurate claims about GrapheneOS. Look at this example:
>For instance, GrapheneOS eliminates unnecessary background processes and applies exploit-hardening techniques to reduce CPU and battery usage.
Did a human truly write that sentence? We aren't aware of any background processes we've eliminated compared to AOSP. Our exploit protections certainly don't reduce CPU, memory or battery usage. We do take great care to minimize the overhead and provide toggles for features with a substantial cost.
The paper is filled with statements which sound reasonable to non-experts but are nonsense. We wouldn't be surprised if most of the paper and code was LLM generated. There are many strong signs of it and it's hard to believe humans wrote all of this. We think it should be investigated further.
There are 4 authors listed for this. The person listed 3rd is a Senior Research Scientist in the Platforms Security and Privacy team at Google. It's published as part of the 2026 IEEE 11th European Symposium on Security and Privacy (EuroS&P). What happened here?
computer.org/csdl/proceedings-article/euros-p/2026/107400b376/2ixHNEzWcYE
Google published Android as an open source project and it succeeded based on it. For years, they've been engaging in illegal anti-competitive tactics to gain control over what was an open platform supposedly governed by a group of companies rather than Google. That includes the Play Integrity API.
Play Integrity API is pushed based on the false premise that it's a security feature. In reality, it's a core pillar of an illegal anti-competitive business model and clearly harms security. It bans GrapheneOS despite it being far more secure than anything they certify including far better patching.
This paper pushes Google's false narrative of alternatives to Google certified Android not providing standard patches and protections. A Google researcher being directly involved as an author is scandalous. The claims made by the paper about GrapheneOS are clearly false and it needs to be retracted.
The paper links to a GitHub repository with code, data and a copy of the paper. It's strange they apparently never thought to run this against the AOSP release which the GrapheneOS release they tested was based on. There are 0 differences in most of the relevant code...
https://github.com/Demeter2025/AndroVET/tree/main

2026-08-06 20:19:32 UTC

For those curious and for added context, we were able to get multiple accounts granted cyber verified access from Anthropic. In the future, it would be good to obtain sponsorships from companies to provide current or future security researchers with more tokens.
#nevent1q…pn7e

2026-08-06 20:05:17 UTC

- reply

With COLDCARD there's a ton of hype around how someone found the major vuln by scanning the codebase with an AI agent after the incident, but AI agents have been publicly available for years and people did post they saw it before, just no one exploited it. Maybe they did not know how to.
Also according to their statements Coinkite used frontier models and supposedly could not find it... all about the user.

2026-08-06 20:01:57 UTC

- reply

This won't entirely replace human reviews yet. The high point of an AI agent's capabilities is only slightly over the capability of it's user. Actual research orgs have vulnerability disclosures exponentially increase with AI while an average dev will mostly just close out simple security deficiencies. Creating a PoC for exploiting a vuln is also resourceful.
Serious vulnerabilities held under embargo on Android have increased massively. You can see our changelog on the security preview patches per release and see how the list gets bigger even when some vulnerabilities get removed from the list as they become part of AOSP.

2026-08-06 19:50:50 UTC

We should call software less buzzwords. Something that's 'Cypherpunk', 'sovereign' and 'freedom' actually tells me nothing about their properties.

2026-08-04 03:38:30 UTC

- reply

Android / GrapheneOS have a cryptographically secure pseudorandom number generator which apps can use: https://developer.android.com/reference/java/security/SecureRandom
You would use this to help create entropy.

2026-08-04 03:27:14 UTC

Met someone who had their coldcard cracked in the first wave, they were late to realise it. A seriously awful situation.
My funds are safe as I do not use one, but feels different actually seeing it in the action.

2026-08-04 03:22:19 UTC

- reply

Other VPN apps work fine. Something wrong with Orbot particularly? Unsure if they have even full support for Android 17.

2026-08-04 03:21:12 UTC

- reply

If we want to implement something deniable, it has to be a different approach. Virtualization and amestic systems come to mind.

2026-08-04 03:16:27 UTC

- reply

runs https://github.com/Coldcard/firmware/commit/37e4af5451c260c1e7d429fe8972c4cb5e68ee59

2026-08-04 03:13:43 UTC

- reply

better

2026-08-03 07:54:47 UTC

- reply

Making easy access to your code also goes a long way. libngu made many mistakes:
- not on the ColdCard GitHub org, so harder for people to find
- git commit history looks like this:
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/f515a1ae400222d28dbc04f6d5926b2b6e7121f89650f0a388e777d4d9f7b345.jpg

2026-08-02 00:41:12 UTC

Chromium fork devs: We shall name it
*throwing dart at periodic table*... Gallium
Firefox fork devs: Introducing the Gooch Browser

2026-08-01 22:10:36 UTC

Contrary to popculture and internet trend narratives, the majority of cyber attacks are not sophisticated. Behind some of the worst cyber attacks are what an industry worker would refer to as a common security deficiency.
These are flaws that are very common and are regularly discussed. These things could be:
- Delayed or no security patching
- Missing second factor authentication
- A misconfiguration or using a insecure configuration, whether it be crypto, application settings, etc.
- Insufficient or lack of access control
- Lack of due diligence or awareness from the victim
- Insufficient logging or monitoring
- Lack of transit or at-rest encryption
Equifax, one of the worst data breaches in modern times, was thanks to them not performing security patching on Apache Struts which allowed a threat actor to exploit a known vulnerability. GTA 6 was leaked from a staff member being socially engineered. Snowden perhaps could not have done his whistleblowing if the NSA has stricter access control.
The best threat actors use the easiest way in to get what they want. The big letter agencies do not jump through hoops and set up big conspiracies rather they exploit software the same way a professional researcher would try to. This also makes an operation far less attributable, because a common security deficiency could be exploited by anybody.
When you regularly see coverage about North Korea ('Lazarus') compromising cryptocurrency companies or users, they are often exploiting these same easily explained weaknesses. If something is too secure, many will easily decide to find a victim that is easier to compromise. What makes them so dangerous isn't their technical capabilities rather than they have far more time and resources because they are state sponsored. They will *never* be held accountable.
When you cover all of these deficiencies and more, your tech is probably more secure than 99.9% of people. Now you go from being a victim of a common attack, to something that would need to be bespoke and targeted.
When working on security or privacy focused software, think long and hard about the quality of the implementation of your functions. You could have many features, but they may not be helpful if their implementation is poor. A poor implementation of a feature may introduce weaknesses compared to not having the feature introduced at all. Less can truly be more.

2026-08-01 21:37:09 UTC

- reply

Really sad to see this is caused by a common security deficiency, either a missing or incorrect configuration. Sensitive crypto operations should not be allowing a fail open.

2026-08-01 21:32:14 UTC

- reply

People 'verify' source code far less than people actually believe. The audience of people who actually can are less than people think too. The entropy code was likely read by many people, many times. It means most did not actually understand what was written. Larger projects pay for AppSec teams to do assurance testing / 'audits' because just having visible source code isn't equal to an audit.
Suspected and known malware get a more documented, deep analysis by security firms compared to most open source projects.

2026-07-30 23:08:47 UTC

- reply

An HDD, they don't have wear levelling. Some SSDs may disable wear levelling at the significant cost of drive lifespan.

2026-07-30 23:05:44 UTC

Exploiting the OS becomes drastically easier after being granted access to a profile. USB becomes available, every radio can be turned on and an app can be installed with every permission granted. Developer options and ADB would need to be available to pretend to be Owner...
Forensic extraction software without exploits for locked device is common and not closely guarded. Users these tools only need to follow simple on-screen instructions. Developers of the tools are aware of alternative operating systems. GrapheneOS features have to work when known.
Cellebrite and other forensic data extraction companies included information on GrapheneOS in their documentation years ago. That includes it being covered in Cellebrite's tables documenting available capabilities:
https://androidauthority.com/cellebrite-leak-google-pixel-grapheneos-security-3611794/
The more recent tables are similar.
training.magnetforensics.com/w/courses/15-gk200-graykey-examinations
> An awareness module focused on anti-forensic operating systems and applications, with particular attention to GrapheneOS — its privacy and security features, supported devices, data-wipe behaviors, and the handling and seizure considerations these devices introduce.
reddit.com/r/embeddedlinux/comments/1josb0i/embedded_linux_jobs_monthly_thread_april_2025/ml3schx/
> Company: Magnet Forensics
>
> [...] experience in both embedded Linux, and also FPGA gateware. Deep understanding of the USB protocol and stack is a major differentiator - experience here sets you apart [...]
>
> Technologies: [...] #GrapheneOS, [...]
We make privacy and security tech. Privacy and security involve defending against adversaries actively adapting and improving. Companies developing offensive security tech including remote exploits and data extraction tools are aware of GrapheneOS. It's made with that in mind.
#nevent1q…4tnh

2026-07-29 21:28:39 UTC

In response to recent suggestions mentioning it:
> If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism.
https://veracrypt.io/en/Wear-Leveling.html
The decoy profile concept many have suggested for years is far more flawed than this. It wouldn't hide the presence of other profiles and would be trivially identified. Basic forensic software on a laptop would identify it without exploits. It would also make exploits far easier.

2026-07-28 03:39:35 UTC

- reply

We don't make features designed to trick people with no technical skills because people who were compromised ALWAYS underestimated the capability of the threat that targeted them. You shouldn't rely on slight of hand or pretty tricks, you should just have *more security*. GrapheneOS is becoming far more popular and recognizable so you can't guarantee you will be trusted that your 'decoy' is legitimate to someone.
All enforcement agents use widespread commercially available forensic extraction tools. You don't need to be smart to use it. Please Google screenshots of Cellebrite UFED, a child could navigate it, it is that simple. It doesn't need a special device and you can run it on a laptop.
It uses ADB to perform extraction and a secondary user does not have access to configure the features. There is zero deniability designed with the user profile approach and that's why it wouldn't be considered with many implementations people make up. Owner also hosts critical OS functions, so it cannot be wiped. It would require a massive redesign on how the OS users and filesystem encryption is laid out.
Virtualization is the way to go for something like this.

2026-07-28 03:29:44 UTC

Because I am seeing discourse on the Elon app about it, see this old reply:
#nevent1q…p9x9

2026-07-27 21:44:13 UTC

- reply

It's trivial to detect an alternate profile without access to developer options and the main ADB shell. It will be detected as part of standard forensic data extraction. Wiping secondary profiles can be easily detected too. Everyone is going to know the feature exists if it's broadly deployed.
A deniability feature would need to be set up very differently to what people think it should be like.
With GrapheneOS being able to run and use Virtual machines, we'd want to work on a feature where there is a virtualized GrapheneOS in the future where it could be set up like this.

2026-07-26 16:46:42 UTC

- reply

Duress makes all data unrecoverable. The entire disk on Android OSes are encrypted and duress instantly wipes the Secure Element and SSD encryption metadata. Data on the Secure Element is one of many parts that derives the credentials to decrypt data.
FBE on Android provides separate encryption credentials for profiles, so deleting a profile deletes all data on it permanently.
See this article for a detailed overview: https://osservatorionessuno.org/blog/2026/05/demystifying-phone-unlocking-tools-a-technical-overview/

2026-07-26 11:25:49 UTC

#GrapheneOS has strong defenses against data extraction. It heavily builds upon the standard security features provided by Android 17 and the most secure hardware available for Android. Currently, only Pixels provide the hardware security features and updates required by GrapheneOS. That's going to change in 2027 thanks to our partnership with Motorola Mobility and progress being made by Qualcomm.
Disk encryption provides strong protection for data. Even the most sophisticated attackers aren't going to be directly breaking it. They either need to exploit the OS while in After First Unlock state or brute force the PIN/password.
Android 16 QPR2 calls for a secure element implementing rate limiting ramping up delays. It's 4 hours after 10 and 41 days after 15. Only 20 attempts are allowed. For usability, It rejects the most recent 5 unique failed attempts early to avoid wasting attempts on repeated errors. GrapheneOS only supports devices implementing the latest generation secure element rate limiting.
https://source.android.com/docs/security/features/authentication/rate-limiting
The secure element on the supported devices also has insider attack resistance. That's implemented by requiring the Owner user to successfully authenticate before the secure element firmware can be updated. A valid signing key and greater version number aren't enough alone. The purpose of this is preventing any government from bypassing the rate limiting by coercing the creation of a firmware update removing the rate limit.
Pixels have used a secure element with an internal timer implementing rate limiting and insider attack resistance since the Pixel 2 launched near the end of 2017. Here's a post about this from back in 2018:
https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html
The secure element and integration into the OS has become far better since then, but it shows this goes back a long way and isn't a new feature.
GrapheneOS also raises the character limit for passwords from 16 to 128. This enables using high entropy diceware passphrases not depending on the secure element rate limiting.
To make a strong passphrase convenient to use without ruining it with biometric unlock, GrapheneOS adds an optional 2nd factor fingerprint PIN. We reduce the allowed fingerprint attempts from 20 to 5 and failure to enter the correct 2nd factor PIN counts towards it. This enables using 6-8 random diceware words as the main unlock method required in Before First Unlock and fingerprint+PIN using a short PIN for convenience. Using a valid fingerprint prompts to enter the 2nd factor PIN which is needed to complete unlocking the screen and hardware keystore.
GrapheneOS greatly improves the exploit protections for the OS with hardened memory allocators and other features. It heavily uses hardware-based security features including hardware memory tagging (MTE) to protect against exploits. A partial overview of those protections is here:
https://grapheneos.org/features#exploit-protection
GrapheneOS adds specialized protection against attacks with physical access too. For example, it blocks new USB connections at a software and hardware level by default while locked and disables USB data as soon as there are no active USB connections.
GrapheneOS shipped a locked device auto-reboot timer back in June 2021. It can be set between 10 minutes and 72 hours. We enabled it by default using 72 hours and then lowered it 18 hours. It automatically returns the device to Before First Unlock state due to our memory zeroing as part of tearing down the OS and booting. We got Pixels to add memory zeroing for booting the firmware fastboot mode in April 2024. Apple and Google added a locked device auto-reboot timer in iOS 18.1 and Android 16. For Android, it can be enabled with the Android Advanced Protection Mode. Our implementation is better for multiple reasons but it's a useful feature regardless.
Android uses separate encryption keys for each secondary user and Private Space. GrapheneOS adds support for putting both back into Before First Unlock state without a reboot via end session for secondary users or toggles for either to do it by default. It's still much better for the device to be rebooted to get the main user back at rest, completely clear leftover data from RAM and block secure element updates.
Our duress PIN/password feature is a minor feature fitting into the bigger picture. It wipes the device when it's entered in any OS prompt for the current profile's PIN or password. It will wipe the device when entered into the authentication prompt for changing a sensitive setting or anything else requiring it, not only the lockscreen. It works across every profile including secondary users and Private Spaces, not only the main user.
There are multiple ways to use the duress PIN/password feature including writing it down on a phone case or a paper kept in a wallet. People should carefully consider how to use it in an actual duress situation where there can be physical or legal consequences for wiping the device. GrapheneOS doesn't require it to protect data from being extracted from the device, but it takes recovering it completely off the table even with the PIN/password for each profile on the device.
GrapheneOS doesn't depend on the duress PIN/password to protect user data. It's one of the tools it provides among the major privacy and security improvements it offers as a whole. Our features page provides an overview of what GrapheneOS offers compared to standard Android 17. It covers most of the major features we provide and many of the minor ones but there's also a lot more beyond it. Our release notes are a lot more exhaustive since we make sure to cover everything when it's added, changed or removed.
https://grapheneos.org/features
https://grapheneos.org/releases#changelog

2026-07-23 22:45:37 UTC

- reply

According to the defendant's motion to suppress in this case, the authorities refused to read him his rights and also made extreme, unfounded accusations such as checking for CSAM (which was never implicated to be under their possession nor was the defendant ever indicted for it, it is not in any court docs) to try and coerce them into unlocking their phone. It appears he chose the Duress knowing he was not given his rights. I would be interested to see how this case develops.
Authorities CAN and WILL lie to you to try and incriminate you even if you have done nothing wrong. Do not talk to them, do not discuss your day and if you are in a questioning then exercise your right to remain silent and get a lawyer.

2026-07-23 22:34:26 UTC

https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

2026-07-23 18:10:33 UTC

- reply

Relevant
#nevent1q…acc6

2026-07-23 18:06:33 UTC

432 Linux vulnerabilities in 24 hours (2026-07-09)
https://lore.kernel.org/linux-cve-announce

2026-07-22 18:26:01 UTC

- reply

GrapheneOS does not create identifiers for users nor track them. All services we do host require the minimum for that service to function, for example when requesting an OS update we would only be able to see an IP address checking an update for a certain phone model.
Android has an "Advertising ID" but this is Play Services dependent and can be deleted in their settings.

2026-07-19 17:38:28 UTC

Join Josh from Side Of Burritos and our Community Manager spring-onion in a live conversation about everything #GrapheneOS on July 20th!
PDT - 10:00 / 10:00 AM
EDT - 13:00 / 1:00 PM
UTC - 17:00 / 5:00 PM
BST - 18:00 / 6:00 PM
CEST - 19:00 / 7:00 PM
AEST - 03:00 / 03:00 AM / July 21st
To accommodate for different preferences the stream will be available simultaneously on both YouTube and a self-hosted instance of Owncast. Additionally, we will also be watching for your questions and comments in the media channels within our Discord and Matrix chats.
https://youtube.com/watch?v=56-DCAHU29Y
https://sideofburritos.com/live/
https://grapheneos.org/contact#community-chat

2026-07-08 19:03:57 UTC

New #GrapheneOS PDF viewer update with swipe gestures for pages and also a full migration to Kotlin.
#nevent1q…4xrh

2026-06-30 20:01:35 UTC

- reply

Yes, Android 17 blocks loopback access across profiles for tougher isolation.

2026-06-27 13:45:13 UTC

- reply

It's a known issue because the AOSP apps are old. When they get replaced with new ones having the latest VCF spec will be on there.

2026-06-27 13:42:39 UTC

- reply

From what I know the Accrescent developer had a lot of personal stuff going on (not bad! just that they're busy). They're doing a lot of stuff behind the scenes for it as seen on the GitHub org. I can ask but I can't make any guarantees and he possibly might not want to make exceptions at this stage.
https://github.com/accrescent

2026-06-27 13:37:30 UTC

- reply

What like? I assume most of them will be Android 17 limitations.

2026-06-26 05:32:14 UTC

- reply

Later next year