How can we get nostr:npub10r8xl2njyepcw2zwv3a6dyufj4e4ajx86hz6v4ehu4gnpupxxp7stjt2p8 zap store on graphene nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm 👀
We don't plan to bundle apps at this time, we keep a blank slate to reduce trusted parties on install. We recommend users to get an app store of their choice by themselves. The Play Store and Accrescent are in our app store app because we vet these apps.
Most users don't use any cryptocurrency, they're just ordinary individuals most of the time. We have quite a broad range. Outside of BTC or XMR the most significant after those two is probably ETH, Vitalik Buterin himself uses GrapheneOS. To my knowledge he's one of our largest donors too but not entirely sure on the numbers?
I'm still around! 👋 I burned the last key due to some important changes and I'm on more secure devices. I am letting the official project account Mastodon bridge do the responses where possible. The whole team uses that and they can be around when I'm busy.
Facebook shipped buggy stack overflow detection in the Hermes JavaScript engine used by React Native:
https://github.com/facebook/hermes/issues/1535
It breaks when the default stack guard is 64k instead of 4k. The standard 64-bit ARM Linux ABI requires 64k. So far only 1 person noticed a broken app.
We're going to be temporarily reverting a change in today's release of #GrapheneOS before Facebook's broken code reaches more apps. We tried lying to apps about the stack layout to hide this change but that breaks compatibility much more. We'll have to detect the Facebook library instead.
Not particularly important since we weren't planning on switching to standard 64k stack probes instead of 4k stack probes to avoid risk. However, it's nicer if it's larger to cover 3rd party code without stack probes. Very minor compared to other things blocked by app compat.
The main feature that's blocked due to third party app bugs is enabling hardware memory tagging by default for all user installed apps. That works fine but catches many memory corruption bugs. We might put the toggle into the setup wizard so that most users end up enabling it.
We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.
We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.
Enabling ShadowCallStack for Vanadium worked well but caused issues with WebView-based apps, likely due to anti-tampering code. This would be nice even on the recent devices with PAC and MTE until we have stack allocation MTE enabled... which is blocked due to app bugs for now.
New change to #GrapheneOS website.
You can now see which device has which releases in Alpha, Beta, and Stable channels. This let's you know what release you'll be on depending on the channel you used.
Facebook shipped buggy stack overflow detection in the Hermes JavaScript engine used by React Native:
https://github.com/facebook/hermes/issues/1535
It breaks when the default stack guard is 64k instead of 4k. The standard 64-bit ARM Linux ABI requires 64k. So far only 1 person noticed a broken app.
We're going to be temporarily reverting a change in today's release of #GrapheneOS before Facebook's broken code reaches more apps. We tried lying to apps about the stack layout to hide this change but that breaks compatibility much more. We'll have to detect the Facebook library instead.
Not particularly important since we weren't planning on switching to standard 64k stack probes instead of 4k stack probes to avoid risk. However, it's nicer if it's larger to cover 3rd party code without stack probes. Very minor compared to other things blocked by app compat.
The main feature that's blocked due to third party app bugs is enabling hardware memory tagging by default for all user installed apps. That works fine but catches many memory corruption bugs. We might put the toggle into the setup wizard so that most users end up enabling it.
We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.
We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.
Enabling ShadowCallStack for Vanadium worked well but caused issues with WebView-based apps, likely due to anti-tampering code. This would be nice even on the recent devices with PAC and MTE until we have stack allocation MTE enabled... which is blocked due to app bugs for now.
TLDR: Tech 'journalism' sensationalizing something that happens on every other Android device to be a Pixel 9 issue to scare people away from Pixels into less secure platforms.
GrapheneOS statement regarding a highly misleading and inaccurate article from Cybernews about the Pixel 9 'phoning home'
Tor Browser users, please update your browser.
https://blog.torproject.org/new-release-tor-browser-1357/
Latest update patches a remote code execution vulnerability confirmed to be exploited in the wild.
Also, this is outdated and we published the July version as well. These docs don't reflect newer iOS versions or iPhone 16
GrapheneOS version 2024100800 released:
https://grapheneos.org/releases#2024100800
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/16321-grapheneos-version-2024100800-released
#GrapheneOS #privacy #security
New GrapheneOS update out now folks. Contains this month's security patch level and some fixes with memory tagging by patching some Android memory bugs.
GrapheneOS features don't just stop exploitation of vulnerabilities, but uncovers potential vulnerabilities in apps.
I have not tested this. nostr:nprofile1qqsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0afj73p can you provide some insight here?
That npub was burned, I don't use that one anymore.
(Check GrapheneOS forum profile for npub so you don't click a sketchy from me.)
It's not something we come across, but we are aware Orbot has some problems, that's why a Tor VPN app is being redone (not by us) in the future.
We are aware of leaks caused by some VPN apps and we keep making patches to fix it but they end up breaking said apps and force us to revert. It's predominantly an app issue, look at the posts on my old npub about Mullvad to get what I mean here.
Latest build added a second-generation leak prevention mechanism but for it's for multicast leaks: https://grapheneos.org/releases#2024092900
I'd contain Tor usage in its own profile so I don't see this happen. I guess if it happens right when Orbot is connecting, give it a few seconds after connecting before doing something?
Top of Stacker News, thank you so much.
cc: nostr:nprofile1qqsyawyrzrttfmv4cmtx5w2m85702kdct7hv3amfrkhagpdf9cz46mgprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpydmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef08ankcmmzv9kr6ctvds20l3q3 believe I mentioned making a post like this to you before, here it is.
#GrapheneOS: The Purpose, The Strategy, and The Why [Article]
This post explains a bit about the development approach, reasoning and strategy behind GrapheneOS security innovation and how power users protect themselves.
Using an app that locks with the OS credential like Phoenix Wallet in GrapheneOS allows you to trigger the device duress password when starting the app because the duress feature also extends to any OS credential input. This doesn't extend to apps exclusively doing their own implementation of a PIN though.
The older generation face scanning hardware was far more robust and secure and the current face unlock options are far less.