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.

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

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

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

#m=image%2Fjpeg&dim=757x1600&alt=Tron+Arcade+Cabinet&blurhash=%5BC7%5EfdbEDzoh%7ECjsE0of-cWCIyf4k%2BWDRWWUKRoJr%3AbIJBjZxBfkSvjusEj%3FnMj%5BbdbGv%23WWS%7Efk&x=a61b6df50a4f2b4c173aac4ed94aad772790c39760f0bb29fdb29cb02eaa4d49

Can confirm beautiful work, beautiful experience.

nostr:nevent1qqspcke6g5geskzwd8utn6sp6umufcrpjjjn3r9melum6p8p33d4mlqpp4mhxue69uhkummn9ekx7mqzyqlhwrt96wnkf2w9edgr4cfruchvwkv26q6asdhz4qg08pm6w3djgqcyqqqqqqgptkznc

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?

Denizens of Nostr, please give a warm welcome to a fellow GrapheneOS Community Team member:

nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm

Give them all your GMs GNs and PVs 🤪

No just disables biometrics.

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

Yes

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.

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.

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.

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.

The 'good' value is as low as your convenience level allows.

I've used 4 and 8.

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.

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

#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

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

Not much longer...

#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

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.

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.

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.

Merry Christmas! ⛄👼🎅🎄🎊

MERRY CHRISTMAS EVERYONE!

#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

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.

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.

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?

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

#m=image%2Fgif&dim=502x246&blurhash=ZEHLF_0K00_2oLxt9ZD%25j%5B%7ECtR_2D%25IVtRIVM%7CNG01%252_2xuRjM%7BjFM%7CofpcRPIU%25MNGt7RjNGof&x=6ed07b52dd05b0564ece249aa0119ab67f83a8428f067b733834515ca1a37d59