Avatar
final [GrapheneOS] 📱👁️‍🗨️
c15a5a65986e7ab4134dee3ab85254da5c5d4b04e78b4f16c82837192d355185
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.

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.

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.

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.

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.

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.

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.

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.

nostr:nevent1qqspl86upj94rndj3kg0uuvyka3kaa0z59kl7d3wx889stza2rcznvsppemhxue69uhkummn9ekx7mp0qgsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgrqsqqqqqpqacnkk

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.

nostr:nevent1qqsdrspnq5l0q3kjgm8gplyeyrjcdscrwgjj53yz5gmzvjxe9gtmsvcpzpmhxue69uhkummnw3ezumt0d5hsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsv9mcec

#GrapheneOS receives third Android Security Acknowledgement from Google this year. This time for a high-severity Bluetooth vulnerability:

Google has listed the CVE-2024-23694 vulnerability we reported in the security acknowledgements for May 2024:

https://source.android.com/docs/security/overview/acknowledgements

This is the Bluetooth issue we found with memory tagging which they assigned a High severity. We fixed this on March 9th. This vulnerability isn't listed in the baseline Android Security Bulletin despite being an Android Open Source Project issue. It will likely be listed in the Pixel Update Bulletin which should be today with the monthly update of AOSP and the Pixel OS.

This vulnerability only impacts Android 14 QPR2 and later. It's possible they only list issues impacting the initial release of Android 14 in Android Security Bulletins and put the rest in Pixel bulletins. It's odd how Pixel bulletins are mostly issues impacting other devices.

Last month, Pixels fixed 2 vulnerabilities we reported which were both classified as High severity and were both exploited in the wild by forensic companies to extract data on smartphones. Both also impact non-Pixels but were only fixed for Pixels and listed in the Pixel bulletin.

We understand why they didn't list those firmware patches in the Android Security Bulletin (ASB) since other devices with the same issues need their own unique firmware patches for them.

The AOSP 14 QPR2 Bluetooth big not being listed means ASB is less complete than we thought though.

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:

nostr:nevent1qqsgfzs2mw8x3jfz0m3vlwd5pgty2ne9gzw8lpcjkyrrs88pjvnwhlspz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsc39mh4

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.

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.

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:

nostr:nevent1qqs0nywe3nndmy58zfuezntqpqujr6luz5e6cxg26yfvy9e678ea2kcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqs0femts

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.

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:

nostr:nevent1qqsfdvew2fde7lm6tkfqz5m43xxugr998sxe7tfqchfv59uf2yehh3cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqs8x6ltz

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.

Outside of Signal, nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsg5cway is fantastic if you don't want a centralised messenger or a phone number requirement.

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.

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.

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.

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.

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.

nostr:nevent1qqs8uxurjncnpj8uyzqy5gd3lyevzd8u92xhk2xe9fdln5y03hgwrwgpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsgwaf3p