MetropleX [GrapheneOS] ⚡🟣

Freedom is the right of ALL sentient beings.

GrapheneOS Community Moderator
#GrapheneOS
Matrix: @metroplex:grapheneos.org

Discord: https://grapheneos.org/discord
Telegram: https://t.me/GrapheneOS
Matrix: https://matrix.to/#/#community:grapheneos.org

Personal Acct. Views Explicitly My Own
Likes and/or Boosts ≠ Endorsements

Public Key

npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c

NIP-05 Address

grapheneos.metroplex.bot

Profile Code

nprofile1qqsyxcm6xydptuwz2w6avpmc4d65ftrrnwywz688yf9fqr22gy5rrqcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsxemgxv

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c

Show more details

Last Notes

2025-09-11 22:16:02 UTC

As Freeborns OH has the issue some others may have noticed it too.
The official project response follows:
Google and carriers deployed changes to RCS which have been breaking it for many users on the stock OS including with certain carriers and in whole countries. The changes appear to have specifically impacted GrapheneOS users too. It's not related to our September 8th update. We're working on it.
You can find many recent threads about people having issues with RCS in Google Messages while using a stock OS with Google Mobile Services. There are articles about how some carriers and countries no longer have it. It still works for most people but the changes definitely regressed compatibility.
GrapheneOS users were impacted by these recent changes much more than other users. We don't know why yet but we're working on determining that and restoring compatibility with Google Messages for people who use it. We'll try to get compatibility with the new way it functions implemented very soon.
#nevent1q…f3yr

2025-09-11 22:14:50 UTC

- reply

Google and carriers deployed changes to RCS which have been breaking it for many users on the stock OS including with certain carriers and in whole countries. The changes appear to have specifically impacted GrapheneOS users too. It's not related to our September 8th update. We're working on it.
You can find many recent threads about people having issues with RCS in Google Messages while using a stock OS with Google Mobile Services. There are articles about how some carriers and countries no longer have it. It still works for most people but the changes definitely regressed compatibility.
GrapheneOS users were impacted by these recent changes much more than other users. We don't know why yet but we're working on determining that and restoring compatibility with Google Messages for people who use it. We'll try to get compatibility with the new way it functions implemented very soon.

2025-09-11 22:09:28 UTC

- reply

Had this asked in our testing room, so enabled it and plugged in, and it stopped at 83%. Going to leave it like this and continue over the weekend but on the very latest release I can't replicate on Pixel 8.

2024-04-06 18:40:06 UTC

- reply

Quad9.net

2024-04-02 23:52:46 UTC

- reply

GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.
Can see the announcement of these being exploited in the wild at https://source.android.com/docs/security/bulletin/pixel/2024-04-01#Announcements.
In addition to them working on our proposal to implement wipe-without-reboot, we've spotted work on our other suggestions such as wiping key derivation results from memory after unlocking.

2024-04-02 23:49:12 UTC

April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:
https://source.android.com/docs/security/bulletin/pixel/2024-04-01
https://source.android.com/docs/security/overview/acknowledgements
These are assigned CVE-2024-29745 and CVE-2024-29748.
source.android.com
Android Security Acknowledgements | Android Open Source Project
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks.
GrapheneOS already implemented defenses against this attack before we became aware of it. After becoming aware of this attack against Pixels running the stock OS, we improved our existing defenses and added new ones alongside reporting the firmware weaknesses to get those fixed.
CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app. It appears they've implemented a partial solution in firmware. See https://twitter.com/GrapheneOS/status/1772616917611585809 about ongoing work we spotted on wipe-without-reboot support.
Google is publicly working on a fix for the factory reset vulnerability we reported:
https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138
Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.
Show more
GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.

2024-03-22 12:52:02 UTC

When you level up your coffee game and the homebrew matches, note for note, the experience from the roastery. ☕💯😋 #DialedIn

2024-03-21 12:56:00 UTC

- reply

Not the only sketchy thing about that council...
"i approached five Labour councillors representing the Spinney Hills and North Evington wards, where many textile factories are located, about the situation. None of them responded."
https://inews.co.uk/news/leicester-sweatshop-scandal-one-year-on-exploitation-abuse-prosecutions-1134805

2024-03-18 13:46:10 UTC

- reply

Tested and confirmed also spoke with dev team, this is upstream with AOSP unfortunately.

2024-03-17 22:12:26 UTC

- reply

This popup DOES appear on GrapheneOS regardless of Play Services being installed or not. https://image.nostr.build/d4635136be82992fb6d48d941cb01377b04a07e38baf43ad018d703970256ab1.jpg

2024-03-15 18:06:54 UTC

- reply

This and on the cutting edge, be an Alpha 😜
#nevent1q…fuh0

2024-03-15 18:05:00 UTC

- reply

I know what you mean but you're approaching the question from the wrong perspective.
It works on any phone that supports it, just happens to be that Pixels are still the only ones that do. We're waiting and willing others to do the same. It's a damning indictment of the mobile device landscape that they haven't and don't.

2024-03-15 14:02:06 UTC

GrapheneOS Current Android QPR2 Bluetooth Compatibility statement:
Due to mainline modules, the Stock Pixel OS is currently using a much older release of the Bluetooth module than the current release in the Android Open Source Project without current security patches. We believe this is the reason for remaining issues not occurring for stock.
The remaining compatibility issues with a small number of devices such as the past couple generations of Galaxy Watch hardware appear to be the consequence of the March security patches and other changes in QPR2. There's a solid chance the Bluetooth devices are what's buggy.
GrapheneOS is on Bluetooth module version 990090000 from the Android 14 QPR2 release. Stock Pixel OS is still using 341313030, without tags available for that. Needs to be addressed even if simply by tagging the older Bluetooth module release being separately built/shipped.

2024-03-15 08:52:32 UTC

- reply

Menu>Settings>Wallet will allow you to use any NWC (Nostr Wallet Connect) enabled service (eg Alby).

2024-03-15 06:55:05 UTC

- reply

Don't use their wallet so all good 👍

2024-03-14 22:07:44 UTC

- reply

Change your Vanadium release channel to Alpha in the Apps app and ensure you are using the latest version.

2024-03-14 19:53:54 UTC

- reply

Vanadium is significantly more secure. It provides strict site isolation for the sandbox and type-based control flow integrity which are not normally available for mobile Chromium. It also disables JIT compilation by default, another setting not normally available on mobile.
See https://grapheneos.org/features#vanadium.
Brave currently has a more advanced content filtering engine with broader content filters due to supporting more syntax. It also has more complete state partitioning. Vanadium will be implementing more complete state partitioning in the near future.

2024-03-13 14:08:51 UTC

Android is moving towards completing one of the areas of verified boot which currently only works in GrapheneOS. They never fully adopted verifying out-of-band system APK updates with fs-verity and then disabled it. They're now moving towards using APK Signature Scheme v4.

2024-03-13 14:06:56 UTC

- reply

Said raids and harassment often involves CSAM and gore. We have members of our community across the age range.
https://m.primal.net/HkRW.png

2024-03-13 08:58:30 UTC

- reply

From a moderation view point and the fact the Matrix protocol suffers from state reset bugs that brick rooms, it makes perfect sense.

2024-03-09 18:26:35 UTC

- reply

Current face unlock support is much lower security than what was provided for Pixel 4 face unlock.
Pixel 4 had dual infrared cameras + dot projector + flood illuminator which provided a more secure approach than a fingerprint scanner. Pixel 7 > approach is far worse, 8 not massively better.
Pixel 4 was very expensive partly because they added all that fancy hardware for very secure face unlock along with a tiny radar on the front (Soli) for motion sense features. These have never been made the standard since.
Where additional functionality doesn't improve upon the existing options such as a random 6 digit pin with secure element throttling and fingerprint biometrics will mean it will always be triaged.

2024-03-08 23:47:52 UTC

- reply

I would suggest reading this thread:
https://x.com/GrapheneOS/status/1397952450108313600?s=20
If you haven't got X and can't find a nitter instance still running or alternate method let me know and I'll take the time tomorrow to paste the entirety.
Yes GrapheneOS is against persistent app accessible root access. As an open source project you are free to make whatever changes you wish to implement whatever options you desire. You can make debug builds etc as suggsted in the thread to determine the level of root you might desire and the method of it's operation.
It is your device, your prerogative and power to you.
Initial build instructions can be found here:
https://grapheneos.org/build
However as a privacy and security focused OS with clearly stated scope and high standards with many high risk individuals and organisations depending on it, it would be anathema to claim to be reducing attack surface while providing easily accessable tools and methods to do the exact opposite.
Good luck in your endeavours.

2024-03-08 23:23:32 UTC

- reply

I believe I have followed a Jack. yes.

2024-03-08 23:22:31 UTC

- reply

Not the PWA (Progressive Web App) but the actual Android app.

2024-03-08 23:01:45 UTC

Running #Primal native Android for a week. So far, so slick.

2024-03-05 17:05:29 UTC

GrapheneOS QPR2 Development Update:
Android 14 QPR2 is the first release following a new approach which means the changes are as large as Android 13 QPR3 to Android 14 were, resulting in a difficult port where there may be regressions to contend with.
As always donations for the project and the hard working development team are welcome at: https://grapheneos.org/donate
Read more below 👇
Official Project Release:
This month's Android release is the first one based on the new development model heavily centered around quarterly releases. It's essentially an early variant of Android 15 with many of the features disabled via feature flags. We're essentially doing a major yearly release port.
We were aware this was going to be the case, but it's still going to take a bit longer than usual. This port should be the hardest one since it's the first one. Future quarterly and yearly releases should be much smaller than this one. It should make the yearly ports much easier.
There's going to be a temporary disruption for us from moving to the first quarterly release under the new model. We didn't treat it as a yearly release with lots of preparation but we'll try to get it as done as quickly as the Android 14 release where we prepared for months.
Despite causing a lot of pain for us for this first migration, the new release model should be a substantial benefit to us. It will mean the changes are spread out throughout the year in quarterly releases and many will get shipped disabled via feature flags so we can port early.
In the very short term, this is a massive pain and disruption for us where we need to put in similar work this month as we did for the yearly Android 14 and Android 13 ports. Going forward, things should be easier. It may also help mitigate the issues caused by mainline modules.
Nearly all our changes are ported and we have builds running in the emulator. There's a lot of work remaining to fix regressions and get device support working. If we aren't done by the end of the day, we can do a security backport release. We'd prefer avoiding an extra release.
We're likely going to need to move the end-of-life Pixel 4a (5G) and Pixel 5 from extended support to legacy extended support. This is a major release with a similar level of changes as Android 13 QPR3 to Android 14, and we don't want to waste our resources on insecure devices.

2024-03-03 01:37:48 UTC

- reply

Spent hours with my siblings playing this on our AMIGA 500 growing up.
https://image.nostr.build/9210177a54a7088c1144ec65c6c18a2a792537332122c65729a821e347b11242.jpg

2024-03-01 20:21:26 UTC

- reply

I'll revisit been an #Amethyst loyalist up to now 😄

2024-03-01 16:39:35 UTC

It would be really useful if there was a way to stop boosts by followers of people you already follow not appearing in the main timeline. My thumb has RSI, Repetitive Scroll Injury.

2024-03-01 16:24:04 UTC

- reply

A good article on threat modelling:
https://privsec.dev/posts/knowledge/threat-modeling/
#nevent1q…atra

2024-02-26 21:30:40 UTC

- reply

https://image.nostr.build/f34a3d99f5bf37c76c0ca564f6f7add33c39a1ed43c1d728efb34895d7205bdf.jpg
#nevent1q…8wd8

2024-02-26 09:42:38 UTC

- reply

Can you raise this as an issue on the issue tracker if you haven't already done so?
https://github.com/GrapheneOS/os-issue-tracker/issues

2024-02-25 23:54:01 UTC

- reply

Try enabling exploit protection compatibility mode:
https://discuss.grapheneos.org/d/2610-chase-bank-mobile-app-wont-load-recent-issue

2024-02-25 23:45:50 UTC

- reply

Same...
https://image.nostr.build/24c5921750766025a451d24817835e4345ce1ed1fd4c859e4046d8f236a2bd8d.jpg

2024-02-24 17:21:00 UTC

- reply

Just be aware that the patch date is an editable string and LineageOS misleads by doing so. The patch date should only be updated like this when the full patches are applied and not just backports etc
Only devices on Android 14 have full security patch level and then only devices fully supported by the OEM for firmware and driver updates too.
I'm not informing you of this for any other reason other than you mentioning it and not wanting you to have a false sense of security, excuse the pun.
LineageOS do a fine job of maintaining older devices to breathe fresh life into them but it is neither private nor secure and should not be used for sensitive or mission critical data if this is important to you.

2024-02-24 13:56:11 UTC

- reply

Florisboard

2024-02-17 14:33:04 UTC

- reply

Need to find your carriers instructions. It's done carrier side.

2024-02-16 08:36:28 UTC

- reply

Sure I replied yesterday but apparently not?
Is the Pixel 5 using the same SIM/cellular plan? If not, even if the same carrier, dial *#*#4636#*#* and check the greyed out toggles for whether it is provisioned on the SIM in the 5.

2024-02-14 18:46:51 UTC

- reply

Qapla'!

2024-01-23 19:32:03 UTC

Latest OsmAnd+ update resolves memory corruption issue exposed by GrapheneOS' pioneering implementation of MTE.
https://github.com/organicmaps/organicmaps/pull/7229

2024-01-22 00:59:56 UTC

- reply

No problem, is there chance at all that Tesla offer extended test drives to allow you to put all this to the test?

2024-01-21 09:33:28 UTC

- reply

To emphasise however this isn't verifiable by me personally.

2024-01-21 09:32:21 UTC

- reply

I've asked around and the app should work fine and is known to. The only issue some have experienced is after a prolonged period the app might report a loss of network connection even with one present. Excluding it from Battery Optimisation may help but if not it requires toggling of Airplane mode on/off to reestablish connection.

2024-01-20 12:42:55 UTC

- reply

I'll pass the feedback along 😄

2024-01-20 01:26:38 UTC

- reply

AOSP
The Android Open Source Project (AOSP) includes individuals working in a variety of roles. Google is responsible for Android product management and the engineering process for the core framework and platform; however, AOSP considers contributions from any source, not just Google.
Contributors make contributions to the AOSP source code. Contributors can be employees of Google or other companies, as well as individual developers with no company affiliation. There is no distinction between contributors; they all use the same tools (git, Repo, and Gerrit), follow the same code review process, are subject to the same requirements on code style, and so on.
GrapheneOS makes a great many changes and while like all other Android OS derivatives it is based on AOSP it is not AOSP. GrapheneOS has and continues to be one of the contributing projects to AOSP itself.

2024-01-20 01:00:48 UTC

- reply

Welcome to the grid user! 🤝

2024-01-20 00:59:05 UTC

- reply

What are you wanting to know? I don't but can look to find out answers if I don't know them for you.

2024-01-16 09:10:31 UTC

- reply

It's available...
https://image.nostr.build/a63a7f71ebb97a8ba1f015a962ad94fcb2e46fea0bbdfded03bf01ff1db01b0d.jpg#m=image%2Fjpeg&dim=864x1920&alt=Aurora+Store+Play+Store+Front+End+Amethyst+Listing&blurhash=%5BG9%3F8%5Dxbs%3At61utRt8of%7C%7BofofkC7KWBj%3Fj%5B%3A%2BWBWCWVA%3DM%7BRjaerDRjV%40V%40I.V%40WBWBogNGRjoL&x=856fc1b29b5d2e8cd500ec41ea03c3b58d3907936d247cd4fa8ae1dd14f88a63

2024-01-15 21:49:02 UTC

- reply

What are they using on stock Android, I'm guessing they use Firebase Cloud Messaging for push to signal the app to sync?
If they were accommodating they could implement UnifiedPush or implement a good battery respecting websocket push.
They have options.

2024-01-15 12:05:19 UTC

- reply

Yes should work fine with sandboxed Play Services installed, then the stand app. However with various changes it could be that Google have made or make more functionality dependent on more privileged access resulting in lower charging speed.
Advise checking out our community channels (Matrix/Discord) and asking other members what their mileage is like, not owning one myself.

2024-01-14 22:37:43 UTC

- reply

If going GrapheneOS get 6th Gen or > do not get a Qualcomm based device, too close to End of Life.

2024-01-14 22:26:49 UTC

- reply

#nevent1q…9425

2024-01-13 18:42:50 UTC

- reply

Oh look another cycled npub. Nevermind honeypot, you're a timesink. You keep using that word FORCE too so lets get all Inigo Montoya...
https://image.nostr.build/d54275aa5f7f560a50fa91f7cca92d983a162536daac9061433b8f9ceb1c65d3.jpg#m=image%2Fjpeg&dim=537x464&alt=Inigo+Montoya+Meme&blurhash=%3BVD%2BuXf69tWWw%5Ds%3ANGj%5BfkMxayf%2Bayt6WBR*jZjZ_NWVs9s.R*WXWBoLjZbvayn%24f6RjayoLayj%40xvjtxafQflfQaebHRj-%3Bf6NGayRjoLoeWVWXV%40oLt7WVofoLjsWVR*%25Mf6aeazWBj%5BayWVjt&x=3e0af40376ee9f6d391ff0da96133f2667848b6aaeed0a126d0c586287576bb7

2024-01-13 12:04:22 UTC

- reply

Lets quote the WHOLE thing shall we:
° An HTTPS connection is made to https://time.grapheneos.org/generate_204 to update the time with a millisecond precision X-Time header. As part of future support for using other services, it falls back to the standard Date header with second precision.
This is a full replacement for Android's standard network time update implementation, which uses unauthentication SNTP (Simple Network Time Protocol) with fallback to the cellular network when it's not available (GNSS can also be used as a time source but is disabled by default, and OEMs can choose the priority order). Network time updates are security sensitive since certificate validation depends on having an accurate time, but the standard NTP / SNTP protocols used across most OSes have no authentication or encryption.
We plan to offer a toggle to use the standard functionality instead of HTTPS-based time updates in order to blend in with other devices.
Network time can be disabled with the toggle at Settings ➔ System ➔ Date & time ➔ Set time automatically. Unlike AOSP or the stock OS on the supported devices, GrapheneOS stops making network time connections when using network time is disabled rather than just not setting the clock based on it. The time zone is still obtained directly via the time zone provided by the mobile network (NITZ) when available which you can also disable by the "Set time zone automatically" toggle.
So as I said "Dependent on Connection" and as I said we DO NOT FORCE people to use our services. Not only can it be disabled, as I said "use either/or or NONE" we ARE going to offer the default connection.
You're a bad faith actor.

2024-01-13 01:46:58 UTC

- reply

If you can afford it, yes, the Pixel 8 support for memory tagging is head and shoulders above 6/7 Gen imo or maybe see how the price changes when/if an 8a lands if MTE support is matched across.

2024-01-13 00:57:47 UTC

- reply

Long term but based on priority, as visually 'outdated' as they are, the reason they are kept for now is that the codebase being maintained in AOSP keeps devs time/effort focused on the constantly shifting security/privacy landscape. Every app we change requires resources (not always financial), especially as these aren't user but essential system based applications.
The benefit of being an open source project though is that if someone committed wants to step up to provide the changes while maintaining it they're more than welcome. Be great if the broader community could help us find/attract those talented developers. 😉

2024-01-13 00:47:40 UTC

- reply

Be sure to hit me up with how you get on. 🤙

2024-01-13 00:09:47 UTC

Enjoyed some time on the grid today, couldn't help but hear 'Separate Ways' 🔈🔉🔊 building in my head as I slow motion walked toward it...
https://image.nostr.build/b575045639b27875ec74e4e778b672433edee9619882709a9f94396e6dfd7b5f.jpg#m=image%2Fjpeg&dim=757x1600&alt=Tron+Arcade+Cabinet&blurhash=%5BC7%5EfdbEDzoh%7ECjsE0of-cWCIyf4k%2BWDRWWUKRoJr%3AbIJBjZxBfkSvjusEj%3FnMj%5BbdbGv%23WWS%7Efk&x=a61b6df50a4f2b4c173aac4ed94aad772790c39760f0bb29fdb29cb02eaa4d49

2024-01-13 00:01:46 UTC

- reply

Can confirm beautiful work, beautiful experience.
#nevent1q…kznc

2024-01-12 23:05:26 UTC

- reply

The tone and the line of questioning is perceivably antaganostic and hostile for unknown reasons. Much has been stated with great confidence however lacking substance and demonstrating a lack of use and familiarity of the very thing having remarks laid against it.
> Does GrapheneOS allow to choose which type of connection applications can use like in DivestOS?
👇
>Network Restriction: DivestOS already lets you restrict network for each app by connection type (cellular/Wi-Fi/VPN), when in the background, and optionally completely revoke NETWORK permission.
Yes GrapheneOS has the exact same functionality, DivestOS Network toggle is the exact same developed by GrapheneOS.
> GrapheneOS is not a reliable project because unreliable people stand behind it.
Remarkable claim with unremarkable evidence. You'll likely tout clout chasing trust abusing and extortionist "influencers" claims, where one in particular is a card carrying Kiwi Farms member immersed in their targeted harrassment campaigns being encouraged and encouraging in equal measure. Unreliable narrators all.
> Another thing is that GrapheneOS builds a walled garden and forces people to use their servers. You claim that you're security espert. Have you noticed that GOS forces to use their server to sync the clock? Maybe you think that you can have accurate time using manual setting?
Nobody is walled in, nobody is forced to use anything, all default connections are routed via GOS servers or proxies but can be done through stock Google or other provider. Users can use either/or OR none dependent on the connection in question.
> GOS is a perfect tool to fingerprint and track journalist and dissidents.
This is why Edward Snowden Chair of Freedom of the Press Foundation uses it every day and Citizenlabs team members have recommended it to high value targets etc.
> DivestOS allows to make updates over Tor, DivestOS has repository with apps within Tor- .onion address.
DivestOS has .onion address of their site.
Our updater will update the app via any connection if using Orbot/VPN etc.
Can you provide any details of GOS to confirm claim that GOS is pro privacy and has astonishing approach to the security vs. DivestOS?
grapheneos.org all auditable and verifiable should anyone choose to do so.
Can you provide any details to backup your extraordinary claims?

2024-01-12 02:59:45 UTC

Denizens of Nostr, please give a warm welcome to a fellow GrapheneOS Community Team member:
@npub1c9d…sqfm
Give them all your GMs GNs and PVs 🤪

2024-01-12 01:06:59 UTC

- reply

No just disables biometrics.

2024-01-12 01:06:31 UTC

- reply

No just tap End Session to put secondary users at rest. Reboot only required if owner profile is actively used with sensitive data stored.

2024-01-12 01:04:16 UTC

- reply

Yes

2024-01-11 19:30:00 UTC

- reply

CONTINUED
We've currently reported these issues for Pixels and will be filing similar issues with Samsung. We don't have as much leaked information about how they're doing it for Galaxy phones, but we can propose the same generic mitigations eliminating the main classes of vulnerabilities.
Secure element throttling is crucial to secure typical lock methods like a random 6 digit PIN or even a typical passphrase. Non-Pixel/non-iPhone devices are mostly missing it so data isn't safe even at rest for typical lock methods (much less than 7-8 random diceware words).
Pixels have used a secure element for this since the Pixel 2, but the NXP and ARM secure core Titan M1 had a fair number of vulnerabilities. Pixel 6 substantially improved this, so there's more focus on ever at exploiting the OS / firmware while the device isn't at rest.
For nearly any current generation secure element, there will likely eventually be a firmware vulnerability discovered. If you want to completely rule out a brute force, use a strong random passphrase. Can take good advantage of each user profile having separate encryption keys.
GrapheneOS has been heavily focused on securing against remote attacks and also providing privacy/security from apps. Those features make physical exploits harder, but we plan to add more features focused on it alongside auto-reboot and blocking new USB peripherals while locked.
Many apps and operating systems implement insecure duress features which can be bypassed. They do a standard wipe via reboot to recovery, which can be easily interrupted. Our implementation avoids this and will be shipped soon. However, we also proposed it to Android for the API.
Android 12 device admin API for disabling USB data is disappointing, since it's similar to what we already did and doesn't disable data lines.
Our default auto-reboot timer will be reduced from 72 hours. We also plan to add more attack surface reductions and other mitigations.

2024-01-11 19:09:03 UTC

- reply

I'll provide information in line with my colleagues running the other main project accounts.
You can manually power off the device.
GrapheneOS provides auto-reboot and zeroing of all data when it's freed, which work together to mitigate these classes of vulnerabilities. In general, getting the device back at rest is critical and we plan to provide more than the already available auto-reboot feature for that.

2024-01-11 19:06:39 UTC

- reply

GrapheneOS provides auto-reboot and zeroing of all data when it's freed, which work together to mitigate these classes of vulnerabilities. In general, getting the device back at rest is critical and we plan to provide more than the already available auto-reboot feature for that.
For now though auto reboot set as low as your convenience level allows is recommended to get it into such a state should the device be removed from your possession.

2024-01-11 19:05:13 UTC

- reply

Basically if your device isn't at rest meaning completely encrypted (before first unlock after rebooting or powering on), then a forensic firm in possession of a device could obtain data due to a firmware bug/exploit we discovered and found being used.
We reported said bug/exploit but between now and a fix being provided by OEMs, we recommend users putting secondary users at rest, (End Session) and using our auto reboot feature so that your device protects itself if out of your possession for as low a time limit as your convenience allows.

2024-01-11 18:59:08 UTC

- reply

The 'good' value is as low as your convenience level allows.
I've used 4 and 8.

2024-01-11 18:06:33 UTC

BREAKING
We've recently reported firmware vulnerabilities that are being exploited by forensic companies to obtain data from devices that are not at rest. If device is at rest, it isn't relevant and data is safe. Our auto-reboot feature is there to get devices back at rest automatically.

2024-01-11 16:46:11 UTC

- reply

You and me both, while Nostr exists I don't have to be invested either way beyond being a user.

2024-01-11 15:38:34 UTC

- reply

https://image.nostr.build/16e818cdd4b8dcb95d631e5de49af64620372ddf60b215dd28228d5623bc8d61.jpg#m=image%2Fjpeg&dim=1019x639&blurhash=r69G%7E%3A%7EWV%40%25MoJs%3ARit7M%7Bni%252-%3AxuofxaofjZof8_%25L%25Mt7xuayxuWBoLIAxu%25Mj%5Bt7ayoff6j%5Bxuofofj%5Da%7Dj%5Bf6jtay%25MNGWWbIRkbHRjjtf6&x=f4f262227304abc17d048bde47ede4d58f59086eb27e4ae850f06cac1ccdb3a1

2024-01-11 14:23:52 UTC

- reply

It is certainly interesting though the type of people each platform pulled in via each method and how each grew/grows.

2024-01-11 14:19:20 UTC

- reply

Not much longer...
https://image.nostr.build/eb46f49bcdfe958bb7f62cc1079612ef8b038968fb823e5926e218ae4b3e929e.jpg#m=image%2Fjpeg&dim=882x588&blurhash=r55%7DgY_3%251ofRkn%24IVM_9a%7EW%3FH%25LxuWBWANHRjIqxa-o%25Mt7ofWBV%40RkR*M%7C-ptRWBofWCs%2BM%7CadD*oJo%23a%7BayRks.kCxZWVNGRkR%2BRkaeoKt6t6&x=fef4e9d7258172de9ffe6499f5435653fd221760b1f676beac5be5ac063abdab

2024-01-10 20:00:15 UTC

- reply

Technically No, all apps are sandboxed on Android, the sandboxing comes from our compatibility layer enabling what Google believes should be run as system apps, as user ones governed by stricter policies.
Apps however can still communicate by IPC and see what apps are in a given user. Therefore some like myself silo apps dependent on Play Services with Play Services themselves in a secondary user putting it back at rest by Ending Session when used. I do this primarily due to having some, legacy, requirements for my identifiable Google Account.
Sandboxed Play Services can be used anywhere however if you need app access to it's functionality (webauthn being one example) without being signed in. Choice is yours.

2024-01-10 11:53:02 UTC

- reply

Nests doesn't work? It did. Go to Vanadium Settings then Site Settings and Javascript JIT and add Nests URL as an exception. Let me know if you profit.

2024-01-10 11:49:12 UTC

- reply

Explain...

2024-01-06 08:19:20 UTC

- reply

Yes updated apps are secure apps. Also failure to update will break features and apps depending on the latest in some cases. eg Google Apps.

2024-01-04 09:36:20 UTC

- reply

LineageOS isn't similar as it isn't a privacy/security focused OS.
Recommend https://eylenburg.github.io/android_comparison.htm which is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
OR
https://privsec.dev/posts/android/choosing-your-android-based-operating-system/ is an article with more long form comparisons between OSes.

2024-01-03 21:48:38 UTC

We've added documentation for the hardware memory tagging implementation in hardened_malloc:
https://github.com/GrapheneOS/hardened_malloc?tab=readme-ov-file#memory-tagging
GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.
GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.
For user installed apps, we enable MTE by default for apps without bundled native libraries and apps marked as compatible. We give users the option to enable MTE for all user installed apps in Settings > Security and users can then toggle it off for specific incompatible apps.
We added a user-facing notification for crashes caused by MTE detecting memory corruption. It makes it easy for users to copy the traceback for reporting the bug to app developers. This also means users don't need to guess when the toggle to disable MTE for an app is relevant.
Our Vanadium browser is also the first browser using MTE in production. In Vanadium, we enable Chromium's PartitionAlloc MTE implementation. PartitionAlloc's implementation isn't nearly as good as hardened_malloc, but we intend to improve PartitionAlloc's security in the future.
Chromium marks itself as compatible with MTE but then disables it as runtime, so other Chromium-based browser have MTE disabled even when the OS has it enabled. We found a bug in Chromium's MTE integration which we had to fix to avoid WebView crashes. It works smoothly for us.
We're also planning on enabling Clang's stack allocation MTE support but it currently breaks Chromium's C++ garbage collection integration along with apps doing in-process unwinding via libunwind. We want MTE for the Linux kernel too, but it integrates it as a debugging feature.
hardened_malloc's MTE implementation is already best in class, but there are some improvements to consider. It currently statically reserves a value for free slots, which reduces the random choices from 15 to 14. It may make sense to use the default 0 tag for free data instead.
MTE obsoletes hardened_malloc's canary and write-after-free check features, so we disable them when it's enabled. However, we haven't figured out an approach to save the memory reserved for canaries yet due to Android supporting dynamically toggling MTE at runtime which is messy.
hardened_malloc uses MTE for all slab allocations, which are all the allocation size classes from 16 bytes through 128k bytes with statically reserved regions for each one. It doesn't need MTE for any metadata since all metadata is in a statically reserved region solely for that.
For allocations beyond the max slab allocation size (128k), there are randomly sized guards placed before/after each allocation along with an address space quarantine on free. MTE would still be valuable for large/arbitrary overflows and use-after-free beyond the quarantine.
We need to investigate the cost of tagging the large allocations above 128k by default.
For non-MTE-capable hardware, we could consider reserving a huge region for allocations above 128k with our own best-fit implementation in userspace to separate them from non-malloc mappings.

2024-01-02 05:01:22 UTC

- reply

"A license request from the originating client device will be received by a partner-operated proxy mechanism (over HTTPS). This proxy mechanism will validate the request and append business rules before sending the payload to be fulfilled by the Widevine License Service.
The Widevine client device does not communicate directly with the Widevine License Service, under any circumstances."
https://developers.google.com/widevine/drm/overview

2023-12-31 18:07:58 UTC

Initial Android Auto support is here! Our community has already helped us with testing and a lot of additional fixes have been merged, with a new release with the appropriate fixes coming very soon! If GrapheneOS not supporting Android Auto was the reason for not giving it a shot, now's the time! This release won't make it beyond Alpha for aforementioned reasons but the foundations are there.
GrapheneOS version 2023123000 released:
https://grapheneos.org/releases#2023123000
See the linked release notes for a summary of the improvements over the previous release.
#GrapheneOS #privacy #security

2023-12-31 15:06:58 UTC

- reply

I feel that later, the letter L will replace one of those T's in tot. 😆🥃

2023-12-31 14:57:24 UTC

This is my peace, the calm before the storm, and tonights festivities begin.
A flick through Beginners Introduction to Privacy, a Quay D'Orsay No 50 and a tot of scotch.
https://image.nostr.build/543b83bc9185da9df6933fc52ebd51a372154f988223ec6b19aea6cb11240369.jpg#m=image%2Fjpeg&dim=1023x1023&alt=Whiskey+Book+Cigar&blurhash=U6D%5Dh%5D0000u6-%3Bx%5EDiV%3F00gOXp%24eVWs7XoIT&x=09a1e9bca8aa4992f2550576be8285117e9fdb2f640098257ffee5516d9caeaa

2023-12-29 22:56:33 UTC

- reply

Official Project Account:
Android Auto support for our sandboxed Google Play compatibility layer has been merged into GrapheneOS and should be available in the next release. It's currently going through final review and internal testing leading up to being able to make a public Alpha channel release.
The implementation uses the compatibility layer to eliminate most of the special privileges that are usually required. It provides 4 permission toggles for enabling different access for wired Android Auto, wireless Android Auto, audio routing control and phone call control.
No special access is granted by default. We've made subsets of the standard privileged permissions for these toggles for granting only minimal required access. Wired Android Auto is close to working with 0 special access required but not quite so it still needs a toggle.

2023-12-29 22:50:16 UTC

- reply

Use without signing into an account to tie data to and restrict to a secondary user on it's own ensuring to End Session after use. Retain the default redirect to OS Location API using incoming only GPS/GNSS.
Remember it works with and without sandboxed Play Services being present.

2023-12-29 22:45:10 UTC

- reply

Usage of Android Auto is subject to all the normal pre-requisites when using any app or service. We're adding the functionality as we always do what we can to reduce the barrier to entry, while being the preminent security/privacy OS with the broadest app compatibility.
Using Android Auto on GrapheneOS will be more restricted than it is on stock thanks to our compatibility layer for sandboxed Play Services. However just like eSIM management Android Auto will require users to understand there are some privileged access required on an OPT IN basis and toggles will be provided for these.
What won't change is our respect for users to choose what is best for them and for us to empower them to make those decisions.

2023-12-29 17:44:11 UTC

COMING TO GRAPHENEOS THIS NEW YEAR...
Android Auto
https://github.com/GrapheneOS/grapheneos.org/commit/0ab6930ef6a6ff6cd488aa62e240b65141003185

2023-12-25 13:36:31 UTC

- reply

Merry Christmas! ⛄👼🎅🎄🎊

2023-12-22 23:31:47 UTC

MERRY CHRISTMAS EVERYONE!
https://image.nostr.build/b7b30a262eaaef9c766ed0b7600c8edaca058d8e234f646d1e320bc3a251b52a.jpg#m=image%2Fjpeg&dim=1242x900&alt=Metroplex+Transformers+Merry+Christmas&blurhash=%239Hx1-%7C%40002a0z9F%5EO%2CurXD*IU%25g%25gx%5DRhIBietR00E%25TImQxH%7EpK5Nfn-AEoar%3F-ArYEeXmK6S%7D.RyDIUR5xa9YtQt7%251%5EPieE0kWKNxvnPa0xZ8wDP.8%3F%5EIoS%7E%252RPMx&x=bcd1c954e278156e52aea88a4983aad8d4e8dbd43ca7bb829acdce0c1ca2fb82

2023-12-22 19:27:33 UTC

- reply

F-Droid does lag behind and has a range of issues, some are being addressed but not before getting personal toward those pointing the shortcomings out.
https://privsec.dev/posts/android/f-droid-security-issues/
As far as seeing apps in Aurora, please note the version number against your current install, usually you'll find it is the same. You also can't in the main install an app with the same app ID from a different source on top of a pre installed app due to signing keys being different. ie you can't install App A from Store A in User 1 then App A from Store B in User 2 unless the AppID is different.
Use NewPipes in built update method or add their release page URL from GitHub to Obtainium and reduce dependency on F-Droid/Aurora as much as you can. Add any F-Droid apps to Obtainium too to reduce the need to more appstores and Aurora for anything else. Ideally your aurora apps could do with being put in another user alongside our sandboxed Play Services and your own salted and unidentifiable account for the Play Store seeing that is all Aurora provides which also works with unattended app updates that Aurora doesn't.

2023-12-22 09:39:38 UTC

- reply

Exploit Protection Compatibility Mode is designed to allow apps that have memory related issues picked up by our hardening to run:
The exploit protection compatibility mode toggle will:
Switch from hardened_malloc to Android's standard allocator (Scudo
)
Reduce address space size from 48 bit to Android's standard 39 bit
Disable memory tagging, unless the app has opted-in to it (only on compatible devices)
Allow native debugging (ptrace) access
All of these changes apply only to the selected app and can be toggled separately.

2023-12-21 16:01:47 UTC

- reply

Very keep me appraised if you notice this regularly. If this fix is repeatable it usually speaks to a memory related issue. Is this using Orbot within Amethyst or standalone?

2023-12-20 18:13:59 UTC

- reply

No OS can completely prevent exploitation. GrapheneOS however has not been known to be vulnerable and nobody has claimed to have done. GrapheneOS has much more advanced exploit mitigations to protect against targeted attacks including hardened_malloc and hardware memory tagging support.
Everyone on GrapheneOS has hardened_malloc and our other baseline exploit protections. hardened_malloc has great support for hardware memory tagging to provide a form of memory safety for memory unsafe code with a mix of deterministic guarantees and randomized general protection.
Production hardware memory tagging is currently exclusive to GrapheneOS running on 8th Gen Pixels. OS wide inclusive of our browser/webview Vanadium.
Our Auditor app can also be used to verify that it's a genuine GrapheneOS install.
If an attacker does exploit the device, they need to persist their access through persistent data due to verified boot, and then exploit the device again on each boot from there. This means wiping data from recovery removes access. Auditor is there to help discover compromise.
This makes Auditor useful for checking persistent state such as whether an accessibility service is enabled, which could be hidden from the user by the accessibility service if the user tried to check on the device itself via the Settings app, etc.
You are more secure on GrapheneOS.

2023-12-20 17:48:12 UTC

- reply

Any apps requiring Play Services can be used alongside our sandboxed Play Services of course:
https://grapheneos.org/usage#sandboxed-google-play
Need anything else let me know.

2023-12-20 17:46:17 UTC

- reply

Don't need one, 99%+ apps are compatible.
The only functionality known not to work is Google Wallets NFC Payments and Android Auto, however the latter functionality (AA) is imminent.
Some apps have issues such as memory corruption bugs or require native code debugging where we provide toggles to disable hardening, our app spawning method or enable native code debugging either per app or system wide to make them function where you want to take the risks.
Apps like banking apps in the main work, only some who chose to enable Play Integrity Strong or require SafetyNet ctsProfileMatch don't work due to the OS not being whitelisted by Google.
For those however we do run a community derived and operated resource:
https://privsec.dev/posts/android/banking-applications-compatibility-with-grapheneos/

2023-12-20 17:34:39 UTC

- reply

Not directly you can send it to me and I periodically when the amount makes it worthwhile send it on chain.

2023-12-20 16:50:00 UTC

- reply

https://image.nostr.build/519e8e2536602d39773fc77c3b9c5831bca0559a58db2ae56b1f31bd957685aa.gif#m=image%2Fgif&dim=502x246&blurhash=ZEHLF_0K00_2oLxt9ZD%25j%5B%7ECtR_2D%25IVtRIVM%7CNG01%252_2xuRjM%7BjFM%7CofpcRPIU%25MNGt7RjNGof&x=6ed07b52dd05b0564ece249aa0119ab67f83a8428f067b733834515ca1a37d59

2023-12-18 07:32:44 UTC

- reply

https://image.nostr.build/d458260752821ff07eff65c879585d9f796da31b6f731f4c41b56f134dc333ea.jpg#m=image%2Fjpeg&dim=236x256&alt=Indiana+Jones+Last+Crusade+Chosen+Wisely&blurhash=%7BID%2CAs.TIUNbR.ogadV%3FQ%2CR4rWjEoft8M%7BV%40_NVs9FoMRkWUozoz%25%23k%3D%25htmjERiROa%23xsfhn%7En%7EM%7BV%40RkjZ%25MnOIUaeRkozo%23j%3F9FWB%25MkBs-kCjYkC%3FatRR%2BbbRkaejbjY4nWBxujFs%3Af6WCR%25&x=5310d8a0c7b49c06069833d5a28cad68d4f27832763103a3498e031c19d9cb68

2023-12-17 00:11:41 UTC

- reply

If you're in the market and want to take advantage of GrapheneOS' trailblazing utilisation of memory tagging with the MTE a Pixel 8 can't be beat.