final [GrapheneOS] 📱👁️‍🗨️

Keeping the fight.

Community Moderator for #GrapheneOS

https://discuss.grapheneos.org/u/final

This is a personal account. I do not speak on behalf of GrapheneOS developers as a whole (nor am I) and suggestions shall not be endorsements.

Public Key

npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm

Profile Code

nprofile1qqsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujumn0wd68ytnzvuq3camnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdsn8455d

Publishing to

nos.lol

relay.nostr.bg

nostr.bitcoiner.social

Author Public Key

npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm

Show more details

Last Notes

2024-08-30 09:51:37 UTC

We've published an initial experimental release for the Pixel 9 Pro Fold on our staging site:
https://staging.grapheneos.org/releases#comet-stable
https://staging.grapheneos.org/install/web
Our preordered Pixel 9 Pro Fold for our device testing farm hasn't arrived yet so we'll be relying on others to test the early builds.
Everything from #GrapheneOS been ported for it already and there's nothing else to do for it without testing feedback from users. There's a high chance everything is already fine for it since we have production quality support for the other 9th gen Pixels and the original 7th gen Pixel Fold.

2024-08-29 22:01:08 UTC

New Auditor update with Pixel 9 Pro Fold support.
https://github.com/GrapheneOS/Auditor/releases/tag/84

2024-08-29 21:21:33 UTC

Next release for 9th generation Pixels will have further hardening with RANDSTRUCT enabled for the kernel with a deterministic seed (the commit timestamp).
RANDSTRUCT randomizes the order of data structures and function pointer tables at compilation based on a seed, so exploits need to be catered to specific seeds. We've made it deterministic to preserve #GrapheneOS reproducible builds by using the hash of the commit date as a seed so it changes the layouts with each base kernel change and we can make it per-device-model later too.
When other devices get Kernel 6.1 (the upstream is in testing) it can be possible for them to get it too.

2024-08-26 16:31:50 UTC

Great article from well known cryptographer Matthew D. Green about Telegram per recent events
https://blog.cryptographyengineering.com/2024/08/25/telegram-is-not-really-an-encrypted-messaging-app/

2024-08-26 15:35:41 UTC

- reply

SimpleX is the gold standard here. Signal is mentioned here since they were the subject of Telegram's campaigns. I would absolutely suggest SimpleX above anything else.

2024-08-26 15:30:25 UTC

- reply

Can't really be sure if it is gone, it's gone. Users should just hope for the best.
Deleting account on it's own would not delete their messages, they need to do that themselves, either by clearing DMs for both individuals or erasing their messages. If they want to delete their account, they should do that first. It's a user's choice to do that.

2024-08-26 15:27:58 UTC

- reply

Using GrapheneOS without one AND aeroplane mode enabled (which turns off the cellular radio) is more secure since you are reducing remote attack surface from the cellular radio, SMS and others. SIM card is just used as authentication to that network and you are still taking part in it so you need both. Even if you have a SIM, using Aeroplane Mode but still using WiFi except when you need data is good practice (you're still connecting to your mobile network provider for WiFi calling and more). This also helps against cellular network tracking.
This has a huge usability cost for some users. High risk individuals are expected to disable radios (Bluetooth, UWB, WiFi, Cellular) when they aren't using them. It's an added measure from people with added caution.
Obviously messengers like Signal are out of the question with no phone number, so SimpleX is the first choice for this.

2024-08-26 12:22:28 UTC

- reply

Matrix has issues with metadata, cryptography and numerous issues with stability. E2EE is default for DMs which is good, for big rooms with tens of thousands of people it is irrelevant anyways. We don't use E2EE on the public GrapheneOS rooms as it scales poorly.
We have some of the largest communities on all of Matrix and we have had to make new rooms numerous times due to stability issues and state resolution bugs. It can also be very slow on the network and so are the apps.
The multi-session adds a lot of complexity and cryptographers have told us Matrix have issues because of it.
See: https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/
There were several earlier rounds of Matrix cryptography vulnerabilities before. See https://nebuchadnezzar-megolm.github.io for one. This has happened repeatedly and we weren't impressed with their response which downplayed it.
We still heavily use Matrix ourselves and have our own server but we're less interested in keeping up with this. It's hard to move away from a platform with multi-session and both good desktop/mobile clients when most of the options don't have that and none combine it with great encryption. We'd like to be able to recommend Element/Matrix but it has these above issues and it gives a lot of metadata to each server. In E2EE Matrix rooms, message content and attachments are encrypted, but the server knows the time, sender, etc.
Still a better choice than Telegram though. As a decentralised service you need to trust your homeserver but that is completely down to you. I am assuming they act in good faith with this post but it is possible not every homeserver will.

2024-08-26 08:43:29 UTC

- reply

Unfortunately the security / privacy campaigning directly conflict against the developers and people working in the field. Many people who lead the campaign also don't advocate the right information. When people do care it's often they've done it incorrectly or been fed baseless accusations and scaremongering meant to slowly wear readers down into buying dubious products and software.
Even if people won't care about privacy yet, we'll be here with the work when they start to. There are people who dismissed our work or used something else before coming here, and some of those people are influential and provide noticeable public support now.
I don't have hard feelings towards people who either don't care or don't like certain projects or even GrapheneOS for whatever reason. If people get in trouble because their narrow-minded attitude thought they were untouchable then it's on them. They will be lessons for others to not follow their footsteps.
We win by being better than others.
#nevent1q…cnkk

2024-08-26 06:09:11 UTC

- reply

This is not a jab against Telegram hitting them when they are at their lows despite what a disappointing amount of users on Twitter have reacted to this with. All of us are GrapheneOS have used it in some way. However, it's founder being arrested is a very important time to remind people that because messages are not end-to-end encrypted except in a very specific circumstance, many users and average people are at risk. Telegram has almost a billion users and many do not understand this concept. If you hold something sensitive on Telegram and it's not encrypted, you MUST take appropriate action. This is a PSA to our users who use Telegram because we care about the safety of our users and community. The climate surrounding Telegram is moving towards being hostile, so talking about this is more important than ever.
There are many messengers not just Signal that are safer than Telegram simply because end to end encryption is mandatory. Signal is mentioned here because they are an unfortunate subject of Telegram's marketing campaigns. Influencers taking jabs at Signal when they are proven to only be able to provide only a timestamp of when an account was registered and last used in court is simply throwing stones from a glass house. Both require phone numbers yet Telegram gives away far more information about you.
Encryption and preventing access to metadata doesn't just protect users, it protects developers. You cannot be compelled to give away what you cannot access and you cannot be accountable to protect against what you aren't able to moderate. Develop unstoppable software that can survive without you.
https://signal.org/bigbrother/santa-clara-county/
We recommend only SimpleX for messaging outside of Signal/Molly at this time. For high risk GrapheneOS users who use it as a WiFi-Only device with no SIM, it is the best choice. Molly also allows multiple devices to use one Signal account, register on another device and link and you still won't need the number if you need Signal. If Session had PFS it would also be considered further, there is a tradeoff.
We aren't in a place and time to assess every communication method available to us, the market for messaging apps is becoming way too large.
#nevent1q…mcec

2024-08-26 05:11:32 UTC

- reply

Our 4th release for the Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL is now available. It adds two Bluetooth bug fixes missing from the temporary Android Open Source Project branch for 9th generation Pixels. One of those is a Bluetooth issue we reported.
See more about how #GrapheneOS exploit mitigations help identify vulnerabilities upstream which we report and improve Android security for everyone:
#nevent1q…9mh4

2024-08-25 15:07:12 UTC

- reply

Difficult to count how many people put themselves in trouble by not using the app in the way it should have been used... Recent events cannot make Telegram avoid scrutiny, the criticisms are more important than ever now if things do get worse.

2024-08-25 14:50:56 UTC

- reply

Telegram has serious issues but this is just a common, regurgitated type of scam site, same thing with Instagram 'DM viewer' sites.
https://www.trustpilot.com/review/tgtracker.com
Here is a site just like it that doesn't exist anymore, likely ran by the same people but a new domain.
https://web.archive.org/web/20210124115118/http://teletracker.org/
Anyone selling this capability out in the open wouldn't be smart.

2024-08-25 14:21:51 UTC

- reply

An iPhone and stock Pixel are around the same, but Pixels obviously gives you more freedom of apps, while Apple's online services are arguably better. There are pros and cons. You're at the bane of either Google or Apple if you use their services. For iPhone, Lockdown Mode exists for added security too but it messes with some browser and messenger functionality. Pixels let you install other OSes safely and easily which is where more private and secure options like ours can be installed onto.
https://grapheneos.org/
GrapheneOS runs on Pixels because they are the highest security platform commercially available to us. For other Android platforms, Samsung comes close but destroys hardware and security functionality on other OSes by an eFuse so we can't use them. Most other Android devices are insecure by being slow on updates and patches or with their hardware choices. Google quickly responds to our vulnerability reports while some haven't even tried to deal with issues we believe affect several other devices that we reported several months ago.
Pixel 8 and later are the best of them as they have hardware security features like MTE which previous generations don't have. They also get security updates for 7 years since launch. We are always open to working with other device manufacturers to hopefully go above what Pixel offers, or to provide an alternative. Most times they fall through because they want to do something different. We have strict demands.
Cellebrite Premium (phone extraction tool exclusive to police) documents say they can do iPhone access on every iPhone on latest iOS while for Pixels they can only hit the stock OS (not GrapheneOS who they DIRECTLY mention) and they cannot brute force the secure element. The stock OS on Pixels does not take full advantage of the security features available to them, like MTE, which is a game changer.
The Cellebrite docs provide a good insight on what device companies with massive budget have a harder time in exploiting:
#nevent1q…emts
Obviously it doesn't completely deny possibility of attacks. Technology is not impenetrable and people who think very powerful organisations is after them need to behave differently too.

2024-08-25 11:35:20 UTC

- reply

Follow good security practices, update software and use new and secure devices. Don't install apps or visit places you don't trust. Less is more, the more you add the more parties you have to trust.
Use a good messenger like SimpleX. Session has some cons like no perfect forward secrecy, but we give them extra props for being honest about that. Signal is the best mainstream choice by us but Molly is a hardened fork we suggest to users above it. You can get Molly via Accrescent app store which is in the GrapheneOS App Store, so there is a chain of trust between GrapheneOS and Molly. The phone number requirement is a con, but Molly allows running multiple devices on one account so you could even register the number on one device, move to a WiFi-only device and never use the number again.
Perfect Forward Secrecy means that even if an attacker gets the messages and later compromises your device to get the main decryption keys, they can't get the messages which no longer have the session keys on your device. Having messages stored on a server inherently is not a major issue providing it is encrypted, though usually most messengers don't anyway which is favorable. Session not having PFS is a flaw in this front.
The messenger needs an OS that is secure and up to date. The hardware also needs to be secure and receive patches. Desktop OSes like Windows and many Linux distributions are worse overall since they don't forcibly sandbox apps. Any other app can just access the data of your messaging app quite easily on these platforms. Assess if needing to share your messages to other devices like desktops are necessary before you choose to do it.
When using something like a messenger there is always the potential of a sophisticated threat having an exploit for it, the same way people do via Telegram, WhatsApp or others because the app is popular. A secure OS can prevent an exploitation of an app that may work on another OS. GrapheneOS using hardened_malloc, MTE, and other exploit mitigations is a huge help with this because some exploits or exploited apps will crash or not work. We have discovered vulnerabilities in OS components like Bluetooth because of our exploit mitigations crashing when there is bugs on certain Bluetooth devices.
Assure the person you speak to on the other end is also following good security practices. You are only as secure as the least secure person in a group. Don't contact people you don't know that well. Don't click links or open attachments to people you don't know or trust enough. You rely on trusting each person you message to be as honest as you are. If you are very high risk, people may choose to just have a separate device for that purpose too. If you're using something like Telegram or Discord, assume everything you said will be kept and seen by anyone. They are more like public forums than private one-to-one messaging.
High risk GrapheneOS users or those with physical device access as a risk can specifically look at this:
#nevent1q…6ltz

2024-08-25 09:32:27 UTC

- reply

Outside of Signal, @nprofile…cway is fantastic if you don't want a centralised messenger or a phone number requirement.

2024-08-25 09:27:12 UTC

- reply

There is a post on here where I went through that but I can't search my own posts on Amethyst.
Secure messengers depend on the device, if your device is not secure, your messages aren't either. Getting control of the device is getting control of the messaging app too. And doing the former is far easier and stealthier.
Messaging apps like Signal getting in on this requires a convoluted plan of the state and the developers to collude. Intelligence ops require the least people to know about it, and preferably no one in the general public. Changing the functionality of the app and server infrastructure to push it to everyone is too loud and risky for a state to perform. Hitting a target with a zero-click exploit to get access to the device and all the data is far easier and is stealthy. Nation states are certain to have exploitation capabilities for tons of computing platforms and apps, but it wouldn't be collusion since not even these software developers would even know they have it, they are state secrets.
Tucker (if he is actually telling the truth and isn't grifting) is a high profile person. He has a gigantic professional network and likely so would this Russian client he communicates with. It would be more realistic that intelligence targeting the Russian client or one of his network got out and revealed his plans. High profile individuals also get hit with spyware campaigns a la Pegasus all the time too. Any one of them can be a target.
Tucker isn't a digital security expert, he is a presenter. He isn't expected to understand what or what did not happen to him. It is possible it's not even a digital factor, someone in his social circle could have told off too.
We do have criticisms of Signal and we recommend hardened variations like Molly instead to our users. Signal is mentioned here because Telegram attacked them repeatedly despite performing far worse in security and privacy. We also trust them not to collude. The Signal app itself could have vulnerabilities exploited remotely just like any other messaging app, particularly in the media handling libraries or WebRTC. That's not a breach of Signal's encryption or a collusion. A secure hardware and operating system can significantly help to defend apps from remote exploits of vulnerabilities.

2024-08-25 08:27:04 UTC

Telegram has full access to all of the content of group chats and regular one-to-one chats due to lack of end-to-end encryption. Their opt-in secret chats use homegrown end-to-end encryption with weaknesses. Deleting the content from the app likely won't remove all copies of it.
Telegram has heavily participated in misinformation campaigns targeting actual private messaging apps with always enabled, properly implemented end-to-end encryption such as Signal. Should stop getting any advice from anyone who told you to use Telegram as a private messenger.
Telegram is capable of handing over all messages in every group and regular one-to-one chat to authorities in France or any other country. A real private messaging app like Signal isn't capable of turning over your messages and media. Telegram/Discord aren't private platforms.
A major example of how Telegram's opt-in secret chat encryption has gone seriously wrong before: https://words.filippo.io/dispatches/telegram-ecdh/.
The practical near term threat is for the vast majority of chats without end-to-end encryption: 100% of Telegram group chats and the regular 1-to-1 chats.

2024-08-25 08:25:38 UTC

- reply

Like the project account said, the Mastodon bridge is done automatically, we don't opt-in to do that nor do we have control of it.
Also Mastodon bridges are likely to miss posts in larger threads, so I post on them here myself just in case.

2024-08-24 20:55:27 UTC

- reply

Happy birthday!

2024-08-24 20:35:01 UTC

- reply

3a XL is completely end of life and is insecure. We don't keep releases for them anymore after providing harm reduction releases for a while. I'm not sure how Chromecast relates to this, sorry.

2024-08-24 20:29:31 UTC

- reply

GrapheneOS is a privacy/security focused mobile OS. You can read about it at https://grapheneos.org/

2024-08-24 20:26:35 UTC

- reply

The socials at the bottom of the page are for a unified project account or forums. With the way Nostr works sharing nsec between teams isn't good practice so we have separate.
Following the project accounts on other platforms are way faster with news, since I cannot always get announcements out on time if I am busy with something else.

2024-08-24 20:22:06 UTC

- reply

We have received donations through OpenSats before.
https://opensats.org/projects/grapheneos
Nowadays the page is changed to mostly mostly encourage donations directly to us.

2024-08-24 11:28:37 UTC

- reply

#GrapheneOS support for the Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL is now available via our official site in addition to our staging site.
https://grapheneos.org/install/web
Most users don't have any issues. 2 people reported an occasional Wi-Fi connectivity issue not happening for others. These are brand new releases and more will be ironed out.
#nevent1q…jt5a

2024-08-23 19:44:12 UTC

- reply

The first update for #GrapheneOS on the Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL is now available. It now has a full port of our hardware-level + software-level USB-C port control feature as a replacement for our legacy USB peripheral control feature: https://grapheneos.org/features#usb-c-port-and-pogo-pins-control.
Currently, the only known issue with support for 9th generation Pixels is all volume levels above 0% currently acting the same way. We're actively working on this and should have a fix for it available soon. Once that's resolved, we're already close to a production release.
#nevent1q…8hyh

2024-08-23 13:22:36 UTC

- reply

Work will start for it when it is available

2024-08-23 11:08:47 UTC

- reply

Experimental releases of #GrapheneOS for the Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL can already be installed with the web installer on our staging site:
https://staging.grapheneos.org/install/web
Can also use the CLI install guide with the releases listed on the staging site releases page.
Our USB-C port control feature with both hardware-level and software-level enforcement hasn't been ported to them yet. They temporarily have our old USB peripherals toggle not depending on changes to device-specific USB HAL and USB-C kernel driver. We aim to get this done soon.
These are production builds signed with the official keys with our standard update system. They'll get updated to future releases without needing to reinstall the OS.
For now, please report issues to our testing chat room rather than our issue tracker: https://grapheneos.org/contact#community-chat.
#nevent1q…zqgc

2024-08-23 05:11:59 UTC

- reply

We're working on resolving an early boot crash with 9th generation Pixels caused by porting our hardware-level USB-C port control to them. If necessary, we can partially omit this feature for an initial experimental release. Our aim is to have a public experimental release today but not a guarantee. #GrapheneOS
#nevent1q…c4n7

2024-08-22 13:08:31 UTC

- reply

Our initial port to the Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL is complete and is going to begin going through internal testing. There will likely be at least a few issues to resolve. We'll likely be able to publish a public experimental release in around 10 to 12 hours. #GrapheneOS
#nevent1q…cpk2

2024-08-21 07:40:19 UTC

- reply

The 8 to 9 don't have much of a difference in security compared from 7 to 8. Pixel 8 series is still one of the best choices by far.

2024-08-20 20:01:28 UTC

We've started work on adding support for the Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL. We haven't received our test devices yet but they should arrive within a couple days. Pixel 9 Pro Fold will be supported like the earlier Pixel Fold but it's launching later than the others.
#GrapheneOS on the Pixel 9 Pro Fold will be the first folding phone platform with hardware memory tagging support. The original Pixel Fold is a 7th generation device without these security features. We still need a new Pixel Tablet with ARMv9 CPU cores with MTE, PAC and BTI. They'll hopefully release one in mid-2025 when they release the Pixel 9a.
Pixel 9 Pro Fold is much better than the first generation Pixel Fold. There have been major advances for the folding screen and it has been widely reviewed as being a much better device. It also has a much broader launch. Likewise, it would be great to have a tablet with MTE and 7 years of support from launch instead of 5.

2024-08-17 19:43:26 UTC

- reply

Follow the links provided in this post to check the verified boot key hash. You can also use remote verification with Auditor to check it is a genuine install. You're free to remove the device after a single verification if you choose.

2024-08-17 18:00:54 UTC

- reply

Don't give into the pressure. Toxicity for this often comes from cognitive dissonance or from a deep discovering sense that they were misled or being too excessive about their approach. Certain security/privacy actions come with spending money and time and people aren't often willing to accept that their money or time was lost.

2024-08-17 17:45:25 UTC

- reply

Was meant to reply to this but eventually spun off into it's own off-topic ramble here:
#nevent1q…a048

2024-08-17 17:44:23 UTC

It's not a surprise the #security industry is plagued with bad actors, grifters, fraudsters, and even criminals. It's easy to lie to people to follow bullshit because security and privacy are extremely easy concepts people can understand at a basic level, despite being extremely complex and requiring dedication to understand at a higher level. This is exactly the same way physical and mental health is also used to sell pseudoscience.
We're in a space that attracts the fearful and paranoid, and the cold and hard truth is these types of people are easy victims because they always doubt every action they take. Anyone who can't reflect and accept their own approach will make it hard to develop an approach to stay with. It is easy to tell such people that the way they are doing things are wrong and convince them to do something else. You can reference something obscure and that is enough for some people.
Pushing security nihilism that trying doesn't matter isn't helpful either. It's harmful. Giving up means you'll never have an attitude to protect.
Bad actors in the security community market exactly like scammers, with:
- A sense of urgency, by saying they are not safe,
- An appeal to authority, referencing famous people,
- Playing on their emotions, like their fear or paranoia,
- Offering of scarcity or exclusivity, that everyone else is missing out or trashing other projects without valid evidence, and
- Referencing current or past events, often with misinformation.
Why does GrapheneOS or other open source projects go on the offensive then? Because people like these aren't competitors, they're threats. In our case, mobile security is extremely plagued with such people, selling dubious feature phones or repackaged old, insecure devices pretending they are endgame security. Some groups make apps or operating systems that don't add security benefit or reduce security. They're threats because they endanger people into believing that they are safer when they really are not.
It wasn't long ago that the mobile security market had criminals that were selling dubious services bundled onto devices like EncroChat, SkyECC, Phantom Secure and more. They enabled violent criminals and likely also scammed ordinary people in the process with a false sense of security. Hundreds of thousands of people were affected by their takedowns. Companies that used to resell these now try and forget they ever had.
Certain actors in the security industry also don't try and innovate security or privacy for the benefit of the world, but to benefit authoritarian regimes and a powerful, abusive elite class willing to pay them for their skills or the power they could leverage. The security industry is meant to be transparent and collaborative, with an unspoken but understood code of ethics to protect and attack to benefit business clients and users. But, some big organisations don't follow it. Forensic firms like Cellebrite sell exploits to regimes to allow data exfiltration, while mercenaries like NSO selling cyber attacks for customers to commit unlawful espionage against their political opponents and those who dissent.
Oftentimes the people with money in the bank sell security and privacy to try and whitewash their past actions. For example, Unplugged is founded by Erik Prince, a war criminal and illegal arms dealer of Blackwater fame, who also employ NSO employees that sold spyware to target political opponents, journalists and dissidents. This isn't the first ex-Defence industry mobile security LARP product and it won't be the last. It is worse that these companies often steal work from open source developers (like Unplugged stealing from Element and DivestOS' Hypatia) and provide nothing in return.
I will not be complacent in having such people produce their rot in the space we dedicate our daily life to. We'd rather quit than collaborate with opposition and it wouldn't have been the first time GrapheneOS had to do this.

2024-08-17 11:27:33 UTC

- reply

This is an unused app previously used for demo phones for display at phone stores. Android 15 already removed it. GrapheneOS hasn't bundled apps like this since 2015. You need a physical access and the device's password, or an extremely sophisticated remote attack with filesystem access to enable it. By that point, you have way more access and control than this app ever did.
The disclosing party (iVerify) sell a dubious app marketed to protect you against sophisticated remote attacks like Pegasus but cannot do what it claims. They also collaborated with Palantir, a surveillance company trying to sell "predictive policing" tech. It is a scaremongering tactic meant to market their dubious products.
#nevent1q…crf9

2024-08-16 20:11:13 UTC

- reply

A company that sells a security theater product that misleads people about detecting sophisticated remote attacks made a misrepresented claim that an unused, disabled app meant to run on Pixels for display in stores is an exploitable component. Mainstream media went with it without doing prior research.
Pixels cannot enable this app without physical access with ADB which requires the user's password, or a sophisticated remote execution exploit that would be more dangerous than the security implications they are trying to imply are.
GrapheneOS does not bundle this app and we were aware of it for years (2017 or earlier) so it's irrelevant to GrapheneOS users. It's scaremongering for marketing for a product that they can't even possibly do what they claim.

2024-08-16 19:58:34 UTC

This is a fake story: https://x.com/cryps1s/status/1824077327577591827
Turns out that getting security information from the CISO of a mass surveillance company trying to build a dystopian police state providing police with "predictive policing" software largely based on racial stereotypes is a bad move.
Trail of Bits iVerify EDR product runs in the standard app sandbox on iOS and Android. It can hardly do anything beyond static scanning of APKs. It's a crippled antivirus app marketed as detecting sophisticated attackers. It's a scam and Trail of Bits has lost all credibility. Trail of Bits is working closely with Palantir and is focused on getting government contracts. They've created a fake news story to promote their EDR product which has been propagated across mainstream media. Journalists didn't do basic due diligence and spread false marketing.
Verizon has a suite of low-level apps for Android devices to fully use their network. These are included on any Android device with full Verizon support. Pixels disable the packages unless a Verizon SIM is active. This is equivalent to having them installed/uninstalled on demand. One of the apps in this suite is the Showcase retail demo app for Verizon to show off phones in their store. It requires manually up the phone as a retail demo device. Verizon says they don't use it anymore. This demo app is where Trail of Bits / iVerify found an HTTP connection.
In order to exploit Verizon's demo app not verifying a signature for the downloaded config or even fetching it via HTTPS, it would already need to be set up to use retail demo mode. The contractors Verizon paid to implement it did a bad job, but it's not a Pixel security issue. Since it's an obsolete app that Verizon isn't using anymore, the stock Pixel OS already removed it in Android 15 which is visible in the Android 15 Beta. The other Verizon apps needed to fully use their network which get activated with a Verizon SIM are of course still included.
#GrapheneOS has been omitting these carrier apps since around 2015. This meant GrapheneOS users weren't able to use Sprint and can't use certain features on Verizon like Wi-Fi calling. Apple has a special deal with Verizon and implements what the control they want as part of iOS. The restrictions set in Verizon's carrier configuration and the functionality implemented by these apps is a major part of why they prevent installing an alternate OS on any device sold by Verizon. They want to control how people use features like tethering and Wi-Fi calling.
Every month, a bunch of real vulnerabilities are patched for Android on Pixels. A subset of these including all High and Critical severity issues in Android itself get backported to older Android releases for non-Pixels too. iVerify's finding isn't even a Low severity issue. Supposedly reputable news organizations including the Washington Post, New York Times, Wired, etc. are largely acting as press release distribution service for governments and corporations. If it fits a narrative they want to tell, there's no attempt to question or confirm it.
Trail of Bits employees should think over whether they want to be part of building a police state with pervasive surveillance as Palantir partners. You're not even working at a reputable security company anymore. Trail of Bits has become the charlatans they used to criticize.
#security #privacy

2024-08-15 21:24:14 UTC

- reply

#GrapheneOS has gone through each of the carrier apps included on each Pixel generation to determine their purpose and consequences of including or excluding them. Here it is being excluded from the new adevtool project for the late ProtonAOSP and GrapheneOS in 2021:
https://github.com/GrapheneOS/adevtool/commit/9c5ac945f#diff-95eb7b50f2781158146e721436d7c5d6f7421755906307a6b7a1f727bb20d53eR109
GrapheneOS has publicly posted about the carrier apps included on Pixels and their privileged permissions on numerous occasions. We talked about the ones which get enabled automatically based on using a SIM from a carrier rather than a disabled demo without an automatic trigger.
Here's a thread from 2017 posted from our project's previous Twitter account which was stolen by Copperhead in 2018:
https://x.com/CopperheadOS/status/903362108053704704
Incredibly important to note that this thread directly involves the CEO of Trail of Bits that's now claiming their iVerify team discovered these apps.
Stock Pixel OS no longer gives the same level of access to the active carrier. This disabled demo app was never a real part of the problem but it was part of the apps we referring to and excluding. We didn't claim credit for discovering this when we became aware of it in 2015.
Dan Guido, CEO of the company behind iVerify, has repeatedly called out charlatans in the infosec industry. It's incredibly hypocritical to use the same tactics and expect not to be held to the same standard. We're not doing anything he hasn't done himself many times before.
It's ridiculous to falsely claim something is a backdoor and then get upset your EDR software remotely monitoring devices and opening up new security holes is called malware. An app running within an increasingly strict sandbox trying to defend devices is an unworkable approach.

2024-08-15 18:21:04 UTC

Wired was manipulated into spreading misinformation to market Palantir and iVerify by misrepresenting a vulnerability in a disabled demo app as being a serious problem which could be exploited in the real world. They should retract the article but won't.
https://www.wired.com/story/google-android-pixel-showcase-vulnerability/
iVerify are scammers and anyone paying them money should rapidly stop doing it and remove their malware from their devices. The real security risk is giving remote code execution on your devices to one of these sketchy EDR companies lying about their capabilities and discoveries.
This is one of multiple carrier apps in the stock Pixel OS which we don't include in #GrapheneOS. We were aware of it already since we had to go through them and figure out why they exist. We could embrace this fearmongering and leverage it for marketing, but we aren't dishonest.
"iVerify vice president of research [...] points out that while Showcase represents a concerning exposure for Pixel devices, it is turned off by default. This means that an attacker would first need to turn the application on in a target's device before being able to exploit it."
"The most straightforward way to do this would involve having physical access to a victim's phone as well as their system password or another exploitable vulnerability that would allow them to make changes to settings. Google's Fernandez emphasized this limiting factor as well."
Wired should retract the article and explain how they're going to do better. They keep publishing this kind of fearmongering misinformation from information security industry charlatans. There are real remote code execution flaws being fixed in Android and iOS but they push this.

2024-08-11 17:37:57 UTC

- reply

Microsoft's disclosure article reports they cooperated to work a patch in March. It was already patched months ago when the article was was published.
There's nothing to suggest this vulnerability was ever exploited in the wild. This is also to do mostly with OpenVPN's own software which they have across multiple platforms rather than us.

2024-08-09 03:49:21 UTC

Organic Maps (a very nice offline-capable open source maps and navigation app) is now available on Accrescent by the way. I personally use this app myself so I recommend to give it a try.
If you download it and you previously installed it on Obtainium or an APK then it will appear as a separate app, this is due to Organic Maps using a different application ID for the app released on GitHub. GitHub downloads use 'app.organicmaps.web' instead of 'app.organicmaps'.
The Organic Maps team discusses this here: https://github.com/organicmaps/organicmaps/issues/8516
As for Accrescent, the maintainers still want to work on developing Accrescent features to allow scaling first rather than adding apps in bulk, but they are allowing apps to come. You are free to read the app requirements and documentation and ask to be added to an allowlist.

2024-08-09 02:46:05 UTC

- reply

Appears not every reply goes through the Mostr bridge but we said there was a WiFi reset option if that could help?

2024-08-06 05:08:20 UTC

#GrapheneOS version 2024080500 released.
This is an early August security update release based on the August 2024 security patch backports. This month's release of the Android Open Source Project and stock Pixel OS should be available later today or tomorrow and we'll quickly release an update based on it following this one.
• full 2024-08-01 security patch level
• suppress crash notifications for 2 harmless crashes occuring on service shutdown for the Android Bluetooth service and Pixel wifi_ext service
• enable memory tagging for the Pixel wifi_ext service again
• Settings: disable predictive back gesture in PIN/password input activities to fix an upstream Android vulnerability
• flash-all: remove unnecessary sleep after flashing AVB key
• flash-all: exit on errors
• flash-all.sh: avoid false negative for device model check
• flash-all.bat: pause before exiting after an error
• fastboot: add support for CLI install with the GrapheneOS optimized factory images format already used by the web installer (will reduce memory/storage usage for CLI installs and will reduce storage usage on the update servers by avoiding multiple factory image formats)
• hardened_malloc: update libdivide to 5.1
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.43
https://grapheneos.org/releases#2024080500

2024-08-03 10:27:49 UTC

#GrapheneOS version 2024080200 released.
This update is an improvement of the last update's attempt at fixing potential VPN DNS leaks in certain apps as the last ones broke certain apps like Proton VPN.
-prevent VPN apps from having leaks to non-VPN DNS servers while not yet strictly preventing leaks to VPN DNS outside the VPN tunnel due to multiple VPN apps including Proton VPN not connecting reliably with stricter enforcement (in a future release, we can do strict blocking by default with an opt-out toggle and a list of known incompatible apps such as Proton VPN until the compatibility issue is resolved)
- GmsCompatConfig: update to version 126
- GmsCompatConfig: update to version 127
- Camera: update to version 73
https://grapheneos.org/releases#2024080200

2024-08-01 23:04:27 UTC

- reply

This update has been locked to the Alpha channel and won't be progressed. We're going to be making another attempt at shipping DNS leak prevention for third party VPN apps. This last attempt resolved a lot of the compatibility issues with the previous approach, so we've made some progress. We don't what's wrong with Proton VPN and certain other apps for it to break this way.
#nevent1q…hd7y

2024-08-01 20:34:15 UTC

We've become aware of another company selling devices with #GrapheneOS while spreading harmful misinformation about it to promote insecure products. We're making our usual attempt at resolving things privately. However, we need to quickly address what has been claimed regardless.
Downloading and installing an app followed by entering sensitive data into it or granting it powerful permissions isn't a vulnerability/exploit. Accessibility service access can't be directly requested but rather has to be granted via Settings app in the accessibility section.
Accessibility service access is extremely powerful and essentially gives the same control available to the user to the app. This is explained with clear warnings. It's also not possible to enable it for an app not installed from a modern app store without an extra hidden menu.
Apps not installed through a modern app store have extremely dangerous settings including accessibility service access restricted. Users have to navigate to a semi-hidden menu to enable this. UI doesn't explain how to do it. It's a higher barrier than simply phishing info, etc.
Accessibility services are required by many users and the feature can't simply be removed. It's possible to disable this and other dangerous features for end users via a device management app. This is the right approach if you have a userbase you want to protect from themselves.
If you purchase a device with GrapheneOS, we strongly recommend booting it into recovery and wiping data before using it. Next, verify it's running genuine GrapheneOS:
https://grapheneos.org/install/web#verifying-installation
Due to complete verified boot, wiping provides the same assurance as a fresh install.
Our web installer is very easy to use. If you're able to use a web browser and follow basic instructions, you have the skill set required to install it:
https://grapheneos.org/install/web
However, if you do buy a device with GrapheneOS, you can verify it's the real deal without malware.
Simply going to a mainstream local business and purchasing a device to install GrapheneOS is the most secure way to obtain a device.
Consider the risk of buying a device from a company marketing to cryptocurrency users, and at least follow our wiping and verification advice.
Purchasing a device with malware installed is something we defend against. We provide a way to block this through verified boot and the verification process recommended on the site. But you can't prevent something like replacing battery with one including a standalone tracking device...

2024-08-01 09:10:11 UTC

- reply

This update is adding a new, improved patch to replace one that was initially reverted for making some VPN apps like Proton VPN stop working.

2024-07-31 22:32:13 UTC

#GrapheneOS version 2024073100 released:
• add back our change to prevent app-based VPN implementations from leaking DNS requests when the VPN is down/connecting but without enforcement for VPN apps without DNS configured to avoid breaking compatibility in rare cases (our previous implementation had to be reverted before it reached Stable)
• kernel (6.6): update to latest GKI LTS branch revision
• Camera: update to version 72
• Vanadium: update to version 127.0.6533.84.0
https://grapheneos.org/releases#2024073100
#privacy #security

2024-07-31 16:41:51 UTC

We're including a less strict variation of our previous VPN DNS leak prevention for third party VPN apps in the next #GrapheneOS release. The new approach only aims to prevent leaks in apps handling DNS configuration correctly. It should avoid causing the compatibility issues which blocked us shipping it before.
We shipped an even stricter approach in our 2024050900 release but compatibility issues were reporting during Beta testing so it didn't reach the Stable channel. It was reverted in 2024051500. Proton VPN may now be compatible with it but not all apps will be so we can't be that strict.
The hardest part of shipping privacy and security improvements is often fully preserving compatibility with the massive number of Android apps. We try to avoid needing toggles to work around compatibility issues, but we make an exception for apps with memory corruption bugs.

2024-07-31 15:16:45 UTC

- reply

nice

2024-07-31 06:12:49 UTC

arstechnica.com/gadgets/2024/07/loss-of-popular-2fa-tool-puts-security-minded-grapheneos-in-a-paradox/
The article unfortunately leaves out most of the points we made in the thread.
#GrapheneOS supports hardware-based attestation and it's entirely possible for Google to allow it as part of the Play Integrity API. They choose to ban using GrapheneOS.
Play Integrity API has no minimum security patch level and nearly all these apps use weak software-based checks that are easily bypassed by attackers. The hardware-based checks rely on trusting every key distributed to every certified Android device, which are often leaked.
Hardware-based attestation can be used for security purposes such as verifying device integrity with a pinning-based approach without the weakness of being vulnerable to leaked keys from the whole Android ecosystem since specific per-app keys in the secure element can be pinned.
Play Integrity API is claimed to be based on devices complying with the Compatibility Test Suite and Compatibility Definition Document. We have irrefutable proof that the majority of certified Android devices do not comply with the CTS/CDD. Play Integrity API is based on lies.
Essentially every non-Pixel device has important CTS failures not caused by CTS bugs. OEMs are cheating to obtain certification. Google claims GrapheneOS can't be permitted because we don't have a certification where they freely allow cheating and don't ban non-compliant devices.
Since Play Integrity doesn't even have a minimum security patch level, it permits a device with multiple years of missing patches. Hardware attestation was required on all devices launched with Android 8 or later, but they don't enforce it to permit non-compliant devices.
The reality is that the Play Integrity API permits devices from companies partnered with Google with privileged Google Play integration when they're running the stock OS. It's easy to bypass, but they'll make changes to block it being done at scale long term such as if we did it.
It does not matter if these devices have years of missing security patches. It doesn't matter if the companies skipped or improperly implemented mandatory security features despite that being required by CDD compliance. Failing even very important CTS tests doesn't matter either.
Google can either permit GrapheneOS in the Play Integrity API in the near future via the approach documented at https://grapheneos.org/articles/attestation-compatibility-guide or we'll be taking legal action against them and their partners. We've started the process of talking to regulators and they're interested.
We're not going to give Google veto power over what we're allowed to do in GrapheneOS. We comply with CTS and CDD except when it limits our ability to provide our users with privacy and security. Google wants to be in charge of which privacy/security features can be added. Nope.
Google's behavior in the mobile space is highly anti-competitive. Google should be forbidden from including Google Mobile Services with privileged access unavailable to regular apps and services. GrapheneOS sandboxed Google Play proves that hardly anything even needs to change.
Google should also be forbidden from participating in blocking using alternate hardware/firmware/software. They've abused their market position to reinforce their monopolies. They've used security as an excuse despite what they're doing having no relevance to it and REDUCING it.
Google is forbidding people from using a growing number of apps and services on an objectively far more private and secure OS that's holding up much better against multiple commercial exploit developers:
https://grapheneos.social/@GrapheneOS/112826067364945164
They're holding back security, not protecting it.
We've put a lot of effort into collaborating with Google to improve privacy and security for all Android users. Their business team has repeatedly vetoed even considering giving us partner access. They rolled back us being granted security partner access by the security team.
As with how they handle giving out partner access, the Play Integrity API serves the interests of Google's business model. They have no valid excuse for not allowing GrapheneOS to pass device and strong integrity. If app developers want to ban it, they can still do it themselves.
After our security partner access was revoked, we stopped most of our work on improving Android security. We continued reporting vulnerabilities upstream. However, we're going to stop reporting most vulnerabilities until GrapheneOS is no longer blocked by the Play Integrity API.
This year, we reported multiple serious vulnerabilities to Android used by widely used commercial exploit tools:
https://source.android.com/docs/security/overview/acknowledgements
If Google wants more of that in the future, they can use hardware attestation to permit GrapheneOS for their device/strong integrity checks.
Authy's response about their usage of the Play Integrity API shows their service is highly insecure and depends on having client side validation. Play Integrity is thoroughly insecure and easily bypassed, so it's unfortunate that according to Authy their security depends on it.
If Authy insists on using it, they should use the standard Android hardware attestation API to permit using GrapheneOS too. It's easy to do:
https://grapheneos.org/articles/attestation-compatibility-guide
Banning 250k+ people with the most secure smartphones from using your app is anti-security, not pro-security.

2024-07-30 21:44:35 UTC

#GrpaheneOS Camera version 72 released:
- use default CameraX camera selection to avoid compatibility issues with some multi-camera setups
- avoid video recording not working after audio permission change
- use CameraX to determine the video timer instead of a separate timer which can get slightly out of sync
- animate the start of video recording
- dynamically show/hide EIS settings based on current configuration
https://github.com/grapheneos/camera/releases/tag/72

2024-07-30 19:57:58 UTC

#GrapheneOS version 2024072800 released 2 days ago.
• avoid isolating eUICC LPA (eSIM activation) app from third party apps to allow carrier activation apps to work (we still block communication with Google Play to avoid sending telemetry data to Google services when sandboxed Google Play is installed)
• Pixel 8a: fix GNSS configuration to avoid occasional crashes of the service (Pixel 8a is currently the only Samsung GNSS device)
• Settings: don't allow disabling user installed apps when uninstall is disallowed
• Settings: drop code for supporting the legacy Settings UI
• Sandboxed Google Play compatibility layer: avoid infinite wait for GmsCompatConfig update when call to App Store fails
• enforce stack clash protection for x86_64
• enforce minimum 64kiB stack guard size for arm64 due to the standard stack probe size of 64kiB
• future proof our Bionic libc changes for dynamic 64k pages (hardened_malloc still doesn't support it)
• flash-all: remove unnecessary reboot after flashing Android Verified Boot (AVB) key
• kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.222
• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.163
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.92
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.42
• adevtool: update to latest carrier settings
• App Store: update to version 24
• Camera: update to version 69
• Camera: update to version 70
• Camera: update to version 71
• Auditor: update to version 81
• Auditor: update to version 82
• Vanadium: update to version 127.0.6533.64.0
• Vanadium: update to version 127.0.6533.64.1
• GmsCompatConfig: update to version 124
• GmsCompatConfig: update to version 125
• fastboot: add support for generating web installer optimized factory images zip for an improved web install approach not requiring fastbootd
• integrate generating web installation optimized factory images zip into release signing script
• split script/release.sh to remove dependency on build output and the OS source tree (see the new instructions for signing releases)
• rename script/release.sh to script/generate-release.sh
• add script/generate-releases.sh wrapper script
https://grapheneos.org/releases#2024072800

2024-07-30 11:08:05 UTC

We've developed a new factory images format optimized for web installation which avoids the need for fastbootd mode and greatly reduces memory/storage usage. The new approach is compatible with 5th gen Pixels and later. It's deployed on our staging site:
https://staging.grapheneos.org/install
We'd appreciate help with testing the new web installer on our staging site. It should reduce issues caused by low quality USB connections/drivers by avoiding switching to a different mode. It should also eliminate the need to install a fastboot driver on up-to-date Windows 11.
We'll wait for feedback from people using it successfully across different operating systems and devices.
Sections for working around Debian, Ubuntu and Windows USB deficiencies should be unnecessary other than the legacy extended support devices so we'll likely remove those.
#GrapheneOS

2024-07-27 09:26:50 UTC

Vanadium version 127.0.6533.64.1 released:
- enable per-site isolation for sandboxed iframes instead of per-origin isolation
- avoid rare uncaught exception from attempting to load content filters from the Vanadium Config app when native code isn't loaded yet
https://github.com/GrapheneOS/Vanadium/releases
#GrapheneOS

2024-07-26 15:23:07 UTC

- reply

GrapheneOS is an AOSP distribution and is compatible with Android apps. Currently the GrapheneOS App Store app mirrors downloads for the Google Play Store or Accrescent so users can download those stores safely if they want them. You're free to use something else though.

2024-07-26 15:18:35 UTC

- reply

The GrapheneOS Foundation monero address is here:
https://grapheneos.org/donate#monero
I don't need my own Monero at this time.

2024-07-26 15:16:12 UTC

- reply

Should specify Bitcoin ratio is higher because of the amount donated, not the amount of Donations themselves. Monero users donate more often, but Bitcoin users donate higher amounts.

2024-07-26 10:46:02 UTC

- reply

This time last year, the ratio for BTC:ETH:XMR:ZEC donations via donate page addresses are around 40:20:20:1. We received more donations via Monero than Bitcoin and nearly all of the ETH came from a single, gigantic donation enough to hire a full time developer. Outside of Lightning (not official) then Monero is the only consistent, reliable flow of small crypto donations. ETH gets some as well but not as much.

2024-07-26 09:36:11 UTC

- reply

#nevent1q…5sc6

2024-07-26 09:36:03 UTC

- reply

#nevent1q…5sc6

2024-07-26 09:34:44 UTC

Chromium has merged the WebAssembly interpreter submitted by a Microsoft Edge engineer:
https://chromium-review.googlesource.com/c/v8/v8/+/5509903
Once this reaches a Chromium stable release, Vanadium will support WebAssembly by default instead of requiring turning on JS JIT via drop-down site settings. Example of a site using it is Mutiny Wallet.
Chromium has a V8 Optimizer toggle for disabling the 2 optimized tiers of the Just-In-Time (JIT) compiler to greatly reduce attack surface. However, it doesn't disable baseline JIT and therefore still does dynamic native code generation. They did this to avoid breaking Wasm.
In Vanadium, our JIT toggle fully disables the JIT and therefore currently loses Wasm support. An increasing number of sites are depending on Wasm with no fallback to JavaScript. Most of these sites perform perfectly fine with only the fast V8 interpreter and no JIT compilation.
Vanadium has JIT compilation disabled by default as part of the security focus. This Wasm interpreter will be a nice usability improvement for sites depending on it with no fallback code since users won't need to toggle on the JIT compiler for the site unless it performs badly.

2024-07-25 23:28:51 UTC

Yes!!! Yes!!!
https://chromium-review.googlesource.com/c/v8/v8/+/5509903

2024-07-25 20:51:53 UTC

- reply

For those who can't read Twitter:
Here's an example of a "counterterrorism operation" by a U.S.-allied Western government targeting political opponents with NSO exploits:
https://citizenlab.ca/2022/04/catalangate-extensive-mercenary-spyware-operation-against-catalans-using-pegasus-candiru/
https://theguardian.com/world/2022/feb/17/more-polish-opposition-figures-found-to-have-been-targeted-by-pegasus-spyware
A more extreme example of a US ally doing a "counterterrorism operation" using NSO exploits:
https://en.wikipedia.org/wiki/Assassination_of_Jamal_Khashoggi

2024-07-25 20:45:43 UTC

Unplugged have doubled down on false claims about GrapheneOS security, pretending people cannot buy devices with GrapheneOS installed and pretending it's hard to install along with promoting their blatantly insecure products with false marketing.
https://x.com/_AndresSegovia/status/1813261339319804343
We have an existing thread going through many of their false claims and debunking them:
https://x.com/GrapheneOS/status/1808161048194671006
We also responded to their lies about GrapheneOS directly. They've read our posts and have chosen to continue peddling the same misinformation about GrapheneOS.
They keep pushing the false claim that Pixels supporting using another OS makes them less secure. The reality is that it's properly implemented in a secure way without adding any significant attack surface. The bottom of the barrel MediaTek Unplugged devices have awful security.
They still haven't ported to the initial release of Android 14 with Android 15 right around the corner. This means they're missing at least around a year of Moderate severity privacy/security patches and huge privacy/security improvements from the past year of Android releases.
Unplugged is using an SoC from MediaTek, a company known to have poor security practices, which fares poorly against real attackers and which has a history of repeatedly shipping actual backdoors. They're trying to portray that as more trustworthy and more secure hardware. Nope.
Unplugged was founded by Erik Prince, noted war criminal and illegal arms dealer. They make a point in talking about the involvement of their employees in enabling these kinds of operations:
https://x.com/GrapheneOS/status/1805592120259936338
That doesn't imply competence, but explains the lack of ethics.
They're trying to present themselves as if they were leaders in the field and switched sides, but they never were and simply want money.
Unplugged is an affinity scam in the same vein as the Freedom Phone. Unplugged has built their product out of open source projects, but without complying with the licenses from projects like DivestOS and while trying to harm open source. Claiming to be in the process of replacing some of the code they were caught stealing doesn't change much...

2024-07-25 11:30:53 UTC

- reply

This is mostly why GrapheneOS mods have separate key pairs rather than a project account.

2024-07-25 05:16:30 UTC

- reply

Agreed. Accrescent is prioritizing on developing to scale Accrescent in the future and try to provide features the users and app devs want instead of adding apps currently. Eventually the developer console signups won't be on a whitelist which will allow for many more apps to get added.

2024-07-23 03:09:47 UTC

Accrescent app store documentation and website have been updated to reflect the collaboration with #GrapheneOS.
If using Accrescent before this, the recommended method to verify Accrescent is to install it from the GrapheneOS App Store. This approach chains the signing verification of Accrescent to GrapheneOS itself, which can then be chained to a hardware-backed root of trust through the GrapheneOS verified boot and Auditor app.
You can learn more about the Accrescent security modeling here: https://accrescent.app/features

2024-07-22 21:42:08 UTC

For Signal users: Outside of just the security benefits for using Molly we discuss a lot about, you should also use it if you don't use Google Play Services, as the non-FCM push notifications in the original Signal app drains a lot of battery.
Molly FOSS has a much more efficient implementation of non-FCM push notifications and doesn't drain battery.
You can find Molly FOSS on the Accrescent app store (available in GrapheneOS Apps app) or from the project site.
https://molly.im/

2024-07-22 13:41:14 UTC

- reply

Transcribro, AppVerifier and BeauTyXT is by the same developer who worked on our Info app. Anyone looking for a voice input, app signature verifier or text / notes editor are free to use any of those.

2024-07-22 09:51:13 UTC

- reply

These tools/procedures are widely used for other reasons including at border crossings. They get training to use it. Law enforcement also often uses them illegally for unjustified search and seizure targeting those who have done nothing beyond crossing a border or journalism. The groups of people using tools from Cellebrite or competitors are often the ones breaking the law or using them for criminal reasons. Many of the people using these tools are criminals breaking the laws of the land.
Even if they say it's only for certain governments and law enforcement clients, it doesn't and won't stop them getting out. There are likely militias, juntas, or criminals in the world with access to these tools as long as they are powerful enough. If Cellebrite isn't available somewhere, something else will take it's place. If we can get documentation, someone far more powerful could get far more.
Defending against tools like these being only valuable to the criminals is a narrative for authoritarianism. Don't let them attack you this way.
#nevent1q…aw2x

2024-07-21 23:26:56 UTC

- reply

Regardless, when using an app store you are required to trust the app itself, the party who maintains the app, and the source of the apps. If your source to get the apps is from the same party who develops the app store, there is less parties to trust. It's a big reason we provide the option to install the apps like Markup, Android Auto, or Play Services directly from GrapheneOS as well. You'd only need to trust the apps and the developers rather than an arbitrary additional party just to get those apps specifically.

2024-07-21 21:56:03 UTC

- reply

I explained a bit about how the security modeling of Accrescent (new third party app store available in our Apps app) works here, if anyone is interested.
#nevent1q…v6vl

2024-07-21 21:47:21 UTC

- reply

Nostr or the like wont be involved for Accrescent, it's been designed to compliment GrapheneOS to be a private and secure app store in the same fashion that GrapheneOS is. There had been interests for us using Accrescent for a long time and this addition coming in a time where people are into using other app stores is just a coincidence. Accrescent has been in active development and maintenance since 2021 and we had expressed interest to mirror it in our Apps app for a while.
> Accrescent's catalog is maintained by a respected community member and checks dev signatures on a third-party database on Github. Correct me if I'm wrong.
This is not done through GitHub rather Accrescent's own hosted infrastructure. When you open the app it will download the current repository metadata JSON which has the app names, ID, signing cert hashes, etc.
> Users will be able to cryptographically verify an artifact came from a developer using nostr. They can do so directly, relying on a web-of-trust check, or indirectly via curators (choose your own walled gardens).
For Accrescent, apps are verified by key pinning of the apps and signing of the app store's repository data. The repository is signed by Accrescent and verified with the repository data public key (hard coded into the app) before it can be fetched. It has downgrade protection and also has a minimum revision hard coded to protect against being served old metadata on first use. It also can support key rotation.
Downloading an app will make the client check the signed repository metadata and compare the app's certificate hash, minimum version, and app name from the signed repository metadata. If any of the parameters do not match it will not install the app for you. For updates it does not matter as Android won't let you update apps with a different certificate than your currently installed version.
Minimum version protects against first install of an insecure, older version, and app name protects against malicious copycat apps.
When someone submits an app on the Accrescent developer console (whitelist only right now) for the first time, it will put a hash of their app's signing key to the repository metadata. This makes sure users are only downloading apps by the real developer.

2024-07-21 20:14:50 UTC

- reply

In January 2024, we reported several vulnerabilities being exploited by the XRY tool from MSAB to get data from Android devices including stock OS Pixels. In April 2024, Pixels shipped a reset attack mitigation we proposed preventing the whole attack vector. We plan to expand it.
Currently, non-Pixel devices are still vulnerable to these reset attacks. In June 2024, Android 14 QPR3 included another feature we proposed providing wipe-without-reboot support for the device admin wipe API. We shipped this early and use it in our duress PIN/password feature.
We also began triggering a full compacting garbage collection cycle in system_server and SystemUI when the device is locked based on info about these attacks. This releases memory for no longer allocated objects to the OS, where our generic zero-on-free feature clears all of it.
In the near future, we plan to ship support for adding a PIN as a 2nd factor to fingerprint unlock to enable users to use a strong passphrase combined with PIN+fingerprint secondary unlock for convenience. We have an initial implementation, but it needs more work before shipping.

2024-07-21 19:45:14 UTC

- reply

Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for overall Android devices. Other than the Titan M2 on the Pixel 6 and later not being successful to bypass brute force protection, it's largely just based on what they've had time to support.
https://image.nostr.build/722344fe8572d1f1b0f0f1a706d79d28727798684ccca26735c9649e2dc89f6a.jpg
https://image.nostr.build/f57098508137691a04584d96325786a9b131890ad8eba7d4770e8771063f6b1d.jpg
https://image.nostr.build/fc4dab33a45ed92b751f28093959a0a0e2f3b2c636e69900b36ad0555d43a0d9.jpg
https://image.nostr.build/dc2f3d85bb4a10ccfb6d17b6400f3658df4dbfe70db1fb539b0da3965741fee1.jpg
#GrapheneOS

2024-07-21 19:26:24 UTC

EXCLUSIVE: Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.
404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.
https://image.nostr.build/f042276d5b54561f39a1cf73f9e3dc5c0b8946c4744eb7a20445c859fcbdc7c3.jpg
https://image.nostr.build/df75e212117bed9ec8e1ae80c06ac78ab66dd981931a5f2c796803150856fbf9.jpg
https://image.nostr.build/24e57317d9f77fc17bb26485a319e28d02c0f36df2038681acae9d0ebc1c1bcb.jpg
Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked #GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.
https://image.nostr.build/6c2c963377aa75af248e5c4ce646df70f50e1d5eedb2184e4b27f63faffd44ee.jpg
https://image.nostr.build/33551de196f545a14b82051aa2a4a826fb84577821c60f4b9841508fb73af375.jpg

2024-07-21 12:54:52 UTC

- reply

If you are using a 6 digit or higher PIN then you rely on the secure element to protect you from brute force attacks. If such a component is exploited then it could be possible to brute force quickly/without a throttle. Using a strong passphrase (Diceware 7 random words, or random case letters, symbols and digits for 18 characters or better) makes this impossible.

2024-07-21 09:29:53 UTC

- reply

Issue: https://github.com/GrapheneOS/os-issue-tracker/issues/28
Current fork branch: https://github.com/u-fred/platform_frameworks_base/commits/issue28/
I'm not the contributor. Where to find could be subject to change.

2024-07-21 00:49:49 UTC

- reply

UPDATE: Someone has shared a newer version of the iOS table indicating Cellebrite caught up to iOS 17.5.1 or higher along with the iPhone 15 for the OS exploits.
It's common for them to fall behind by a few months for new iOS and Android versions. Android and iOS have no secure way to automatically get devices back into Before First Unlock from After First Unlock as GrapheneOS does so attackers can simply wait until they have an exploit.
We're currently waiting for one of our several sources to provide us with the new Android and iOS documentation. We aren't going to post the leaked iOS table in this thread because we can't confirm that it's authentic yet. We should have the new documentation quite soon though.
It's unfortunate that there was a whole bunch of secondary news coverage where it was misreported that Cellebrite was unable to exploit current iOS based on documentation from April 2024. It's July 2024 now, and they've had months to restore the capabilities broken by an update.
#nevent1q…af3p

2024-07-21 00:23:04 UTC

- reply

Yes, but it can also verify currently installed apps too.
Installing an app from an APK file is trust on first use. All apps are signed by a certificate from the app developer which the OS trusts. Apps can only update if it is both a newer version, and it is signed by the same certificate it came with.
Updates are verified by only allowing updates from that same developer's certificate. If it doesn't match, it will fail. This prevents installing a fake or malicious update.
AppVerifier checks the apps you installed are have the genuine certificate and package name from the developer. It can compare to keys you provide or it can check from an internal database of apps in the app if there is an entry for it.
DB can be found here: https://github.com/soupslurpr/AppVerifier/blob/master/app/src/main/kotlin/dev/soupslurpr/appverifier/InternalVerificationInfoDatabase.kt

2024-07-20 23:46:58 UTC

- reply

AppVerifier was based on a planned GrapheneOS feature for users to verify APK files based on their key fingerprint. The feature is currently stalled since relying on the clipboard isn't ideal. For now, users can use AppVerifier from Accrescent until we ship a built-in approach to this.

2024-07-20 23:44:39 UTC

- reply

The lead dev of Accrescent is a GrapheneOS user and contributor. It'll be a good place to publish apps especially for GrapheneOS users. AppVerifier, BeauTyXT (text editor) and Transcribro (private, on device voice recognition and keyboard) are from the same person who wrote our GrapheneOS Info app. Molly is a security-focused fork of Signal from another GrapheneOS user.

2024-07-20 23:32:24 UTC

- reply

Accrescent comes from within the GrapheneOS community and we're collaborating together.
Accrescent is in alpha and isn't yet open to any developers uploading their apps. It will have a lot more apps available in the future. It will become a full alternative to Play Store permitting closed source apps too, but you'll be able to filter to show only open source apps for users who want this.

2024-07-20 23:13:58 UTC

- reply

These details should tell you that if you consider these types of groups (sophisticated adversaries with limitless physical access) as a part of your threat model, then you should:
- Use the most recent phone you possibly can
- Upgrade your phone to the newest possible generation as soon as possible after release if you can help it.
- Use the latest version of GrapheneOS ASAP. Do not delay.
- Use a strong, high entropy passphrase to make bruteforcing the device credential impossible if secure element is ever exploited.
- Set GrapheneOS auto reboot time accordingly so encrypted data goes back at rest when the phone reboots, which makes AFU exploitation impossible. The lower the better.
- Enable duress password. Set it to something easy to trigger but not easy to misfire.
- Turn your phone off in a high risk situation, and trigger duress when in a duress situation.
- Disable your radios when not using them (turn off Wi-Fi, use airplane mode, disable NFC, UWB etc.) for attack surface reduction.
- Set an appropriate USB port control or disable the USB port so they aren't able to connect a device to it.
- Use user profiles (application data and user files within profiles are stored encrypted with separate credentials).
- Enable upcoming GrapheneOS security features like second factor authentication unlock when they come out.
- Communicate only over secure messaging. Some apps like Molly (Signal fork) have features to encrypt the app storage with a passphrase, which access to that app's data impossible even when a profile is compromised providing the passphrase is secure enough.
- Become disassociated to data. Learn to only keep files or other data as long as it is necessary. If you have no use for them for a long time, then back it up elsewhere, encrypted. Delete anything you don't have a use for in the present. Your data is not your memories.
- Remember that you are only as secure as the people you trust. If they do not meet your safety or security requirements, don't enable them to do things that could cause trouble.
#nevent1q…af3p

2024-07-20 22:29:47 UTC

We published the Cellebrite Premium documentation from April 2024 in May 2024.
Our thread properly explained the info in the tables including their inability to exploit Pixel 6 or later secure element and only partially bypass it on iPhone 12 or later at that current period of time.
Cellebrite was a few months behind on supporting the latest iOS versions. It's common for them to fall a few months behind for the latest iOS and quarterly/yearly Android releases. They've had April, May, June and July to advance further. It's wrong to assume capabilities didn't change for the later iPhones.
404media published an article about the leaked documentation this week but it doesn't go into depth analyzing the leaked information as we did, but it didn't make any major errors. Many news publications are now writing highly inaccurate articles about it following that coverage.
The detailed Android table showing the same info as iPhones for Pixels wasn't included in the article. Other news publications appear to be ignoring the leaked docs and our thread linked by 404media with more detail. They're only paraphrasing that article and making assumptions.
The person who shared it with 404media is one of our community members. We regularly get sent this kind of information. In the case of XRY from MSAB, we were able to report several Android vulnerabilities based on their docs which are now fixed on Pixels but not elsewhere yet.
We received Cellebrite's April 2024 Android and iOS support documents in April and from another source in May before publishing it. Someone else shared those and more documents on our forum. It didn't help us improve GrapheneOS, but it's good to know what we're doing is currently working.
It would be a lot more helpful if people leaked the current code for Cellebrite, Graykey and XRY to us. We'll report all of the Android vulnerabilities they use whether or not they can be used against GrapheneOS. We can also make suggestions on how to fix vulnerability classes.
In April, Pixels added a reset attack mitigation feature based on our proposal ruling out the class of vulnerability being used by XRY.
In June, Pixels added support for wipe-without-reboot based on our proposal to prevent device admin app wiping bypass being used by XRY.
In Cellebrite's docs, they show they can extract the iOS lock method from memory on an After First Unlock device after exploiting it, so the opt-in data classes for keeping data at rest when locked don't really work. XRY used a similar issue in their now blocked Android exploit.
#GrapheneOS zero-on-free features appear to stop that data from being kept around after unlock. However, it would be nice to know what's being kept around. It's not the password since they have to brute force so it must be the initial scrypt-derived key or one of the hashes of it.

2024-07-20 22:15:36 UTC

- reply

Accrescent is alpha software (in terms of features) and likely wouldn't be appropriate to distribute it wider without further improvement. It is the maintainer's choice. It would be better for the future.

2024-07-20 20:35:37 UTC

- reply

For outside GrapheneOS there's https://accrescent.app

2024-07-20 18:29:30 UTC

- reply

You will need to be on the latest GrapheneOS App Store, it may not have reached everyone yet. If you don't have it then try select Beta and update. You are free to set it back to Stable after updating.

2024-07-20 11:35:56 UTC

- reply

fyi I am aware of other projects using Hardened Malloc as well, for example this hardened Void Linux build has hardened malloc and other hardening:
https://0xacab.org/optout/plagueos
https://0xacab.org/optout/plagueos/-/wikis/Security-Considerations
https://0xacab.org/optout/plagueos/-/wikis/FAQ
It sounds very interesting butI (and I think anyone I know) have never used it though. Can't make a recommendation. Using smaller projects is at your own risk.

2024-07-20 11:28:09 UTC

- reply

The Chromium itself is still patched to disable data collection and opt-in metrics according to the developer and since it uses Vanadium patches I could attest to that. Always better to use the Chromium as a base and build with own patches rather than centipeding someone's fork like ungoogled-chromium. Since if they delay, then you delay.
These forks also aren't security hardened like Vanadium is, forks will just amateurly take out anything that mentions Google which leads to some regressions.
Secureblue is not endorsed but both have a similar user share and the maintainers are frequent GrapheneOS community members. It's listed as an example of other OSes using hardened_malloc on our site.
It's usable, but hardened_malloc will break certain apps the same way they do on GrapheneOS for security. Electron apps are an example. I don't daily-driver secureblue though and the barrier for entry is higher than it is to get started with GrapheneOS.

2024-07-19 22:34:04 UTC

- reply

Brave is a top choice when it comes to content filtering and state partitioning. A big issue with Brave is how much, in my opinion, random nonsense they want you to use with it. Fortunately it never bugs you again once you disable it, but there could be better.
Secureblue (security-hardened Fedora Atomic images) uses a hardened Chromium with Vanadium patches, but it's part of Secureblue for the most part. It also uses our Hardened Malloc.

2024-07-19 16:18:48 UTC

- reply

It's mostly used explicitly by GrapheneOS users. It's maintained by a supporting community member. Some strict security-focused users have been using it for a few years. I don't expect this to be the first choice app store for people due to how limited the app catalog is, but it is worth us mirroring on our App Store so users can get it quickly, and because it is the what we consider choice for security and privacy.
Future progress and adoption will hopefully change things

2024-07-19 16:03:17 UTC

- reply

While the app catalog is currently limited, it is the most private and secure option to get the apps that it has if you need them. Other apps we recommend like Molly (hardened Signal fork) also officially appear on Accrescent. Some popular apps you may recognise are AppVerifier, Aves Gallery, IVPN and ExifEraser (we do not make official ecommendations or endorsements for these apps or services, use at your own preference or risk).
We may add our own builds of certain third party apps but we aren't ready to do that yet. Would be a lot of work.

2024-07-19 15:56:04 UTC

- reply

Accrescent is by their own team, I don't work on it. We have now chosen to add the option to install on our Apps app. They are maintained by long-time GrapheneOS community members and it's been designed for GrapheneOS users. We have been aware of the app for a few years.
https://github.com/accrescent/accrescent
It was always in our interests to have a more secure app store option as we didn't want F-Droid. Users are still free to install another app store of choice as Accrescent isn't and won't be bundled into GrapheneOS itself.

2024-07-19 15:34:41 UTC

The #Accrescent security and privacy focused Android app store is now available in the #GrapheneOS app store.
Accrescent is a mobile security and privacy project that closely ties to our values. We hope the Accrescent project can benefit from having more users.
Accrescent features:
- App signing key pinning: first-time app installs are verified so you don't have to TOFU.
- Signed repository metadata: repository contents are protected against malicious tampering.
-Automatic, unattended, unprivileged updates (Android 12+): updates are handled seamlessly without relying on privileged OS integration.
- Designed for split APKs: downloaded APKs are optimized for your device to save bandwidth.
- No remote APK signing: developers are in full control of their app signing keys.
- No account required: users don't need an account to install apps, improving privacy.
https://image.nostr.build/0a5a749032e0fb2aecefd1cf258e1bba535b69f66bade881f2202bd3f481b320.jpg

2024-07-19 15:31:02 UTC

- reply

GrapheneOS turns 10 this year, quality work takes time and all of this definitely didn't pop out of nowhere suspiciously. IMO this has been the best past 12 months for GrapheneOS so far. Several vuln disclosures, duress password, Vanadium content filtering and more in a small span of time. We definitely appreciate people coming to support GrapheneOS in droves the past 12 months.
It wouldn't make sense for us to be malicious for many reasons, not every GrapheneOS team member is working in private (e.g. the founder) and we have a Foundation registered in Canada with multiple directors. We participate with the broader cybersecurity community with vulnerability disclosures and such. There's nothing wrong with concealing your identity but in our case, we have reputation and our professional lives on the line not to be evil. How we work is very different and open in comparison to real sting operations ran by governments or scam products owned by criminals.
We dont deny certain people want to break us. We will never say we are impenetrable, but we are aware our work is targeted by threats aligned with governments such as in the leaked Cellebrite documentation where they discuss their failures with GrapheneOS. These people deceit the public with vague and misleading information to discredit us. Our effort the past year is down to fighting back on this attack and our fight is completely in the public eye for people to watch, we already survived a hostile takeover attempt, so we we're very sure we're here to stay.

2024-07-18 15:46:07 UTC

- reply

I admit I'm curious to know what can be too good to be true about it? I know it's partially a compliment but still curious.
There is still a large amount of enhancements we would love to add and changes we want to make (see the roadmap on our site) so it surprises me people consider GrapheneOS at the current state to be too good.