Discord is more of a social media platform than a messaging platform, everything you do on there should be treated as public, it's literally designed for rooms for tens of thousands of people to talk in. Sites like these have existed for years.
People do the same mistakes with Matrix as well, although you can just look at the web preview of rooms with no account, and encryption is useless in big rooms if anyone can join and watch.
We was able to watch an approve-only Discord server for forensics analysts (employees of *those* companies) and law enforcement because they kept the room preview open. They sounded pretty annoyed about GrapheneOS too...
#GrapheneOS version 2034042100 released.
This update backports an upstream Linux kernel patch for a kernel panic caused by another patch in the last update.
These are the changes from the previous update (2024042000) that are relevant:
- add toggle in Settings > Security for opting into memory tagging in vendor processes currently excluded from it with the end goal of having it force enabled without a toggle as we do for the rest of the base OS
- allow eSIM activation app to interact with Google Fi app when installed to fix Google Fi activation
- use ro.vendor.build.svn system property from adevtool instead of AOSP to make sure it always matches the stock OS
- Pixel Fold: update to AP1A.240405.002.A2 vendor files
- Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro: update to AP1A.240405.002.B1 vendor files
- Log Viewer: include kernel log buffer in default log output
- Log Viewer: show "Save" instead of "Copy" button for logs that are over ~50 KB
- Log Viewer: improve handling of log saving
- backport mainline APEX module patches for Android Health, ART, DNS Resolver, Media Provider, Network Stack, PermissionController and Wi-Fi
- TalkBack (screen reader): update base code to 14.1 and massively overhaul our changes to it
- Vanadium: update to version 124.0.6367.54.0
- Camera: update to version 68
- Auditor: update to version 79
- GmsCompatConfig: update to version 104
- Setup Wizard: layout and style improvements
- Setup Wizard: add functionality for testing on debug builds
Our latest release will remain in the Alpha channel due to upstream Linux kernel regressions in the latest 5.15 GKI LTS release causing crashes on the Pixel 8 and Pixel 8 Pro for some users. Very likely caused by f2fs backports in the newer LTS release. Major thanks to our testers.
Updates are delivered OTA and installed automatically after an update check. A reboot finishes the process. You can also choose to check for an update immediately after it is released providing it is in your release channel manually in Settings on the owner user profile as well.
See: https://grapheneos.org/usage#updates
This update is currently in Alpha channel. It will move to Beta in a few hours and then the Stable channel after more, providing no issues of the update are reported.
#GrapheneOS version 2034042000 released.
This update most notably fixes Google Fi eSIM activation.
See the changes:
- add toggle in Settings > Security for opting into memory tagging in vendor processes currently excluded from it with the end goal of having it force enabled without a toggle as we do for the rest of the base OS
- allow eSIM activation app to interact with Google Fi app when installed to fix Google Fi activation
- use ro.vendor.build.svn system property from adevtool instead of AOSP to make sure it always matches the stock OS
- Pixel Fold: update to AP1A.240405.002.A2 vendor files
- Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro: update to AP1A.240405.002.B1 vendor files
- Log Viewer: include kernel log buffer in default log output
- Log Viewer: show "Save" instead of "Copy" button for logs that are over ~50 KB
- Log Viewer: improve handling of log saving
- backport mainline APEX module patches for Android Health, ART, DNS Resolver, Media Provider, Network Stack, PermissionController and Wi-Fi
- TalkBack (screen reader): update base code to 14.1 and massively overhaul our changes to it
- kernel (5.10): update to latest GKI LTS branch revision
- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.148
- kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.76
- Vanadium: update to version 124.0.6367.54.0
- Camera: update to version 68
- Auditor: update to version 79
- GmsCompatConfig: update to version 104
- Setup Wizard: layout and style improvements
- Setup Wizard: add functionality for testing on debug builds
Disabling entirely is an extreme move of course... but the option is there for the extreme people 🤔. Charging still works when off or in bootloader modes like Fastboot. I find myself using Charging-only the most.
Future Pixels are *alleged* to have Qi2 wireless charging with magents, if it's true then then someone could charge with that and never use the port at all, and since it's magnetic you shouldn't need to stop using the device to charge it.
Also, USB-C port controls to disable the port or it's data transfer lines. Possibly the biggest feature against a physical threat except autoreboot. You could write about almost every feature/enhancement we have and an example on how it protects against a forensics threat. 🤔 Well, I could anyway.
*note: surveiling a target to know their PIN isn't really something they usually do because they usually expect the device they seize to be exploited and brute forced open... Think a Ross Ulbricht degree of suspect, you'd need to be known as high-profile, high-risk. How you act on that depends on threat model. They know about GrapheneOS so if I was in their shoes this would be my go-to for a GrapheneOS user every time... but it's not.
Lockdown only locks the device and disables fingerprint as an unlock method for the next lock. Data is still not at rest and remains in AFU. If you're using a user profile then the End Session button (GrapheneOS feature) purges keys and puts that specific user profile back at rest / in a BFU state!
It's just a frill to prevent someone unlocking your phone with your finger while you sleep or something, it doesn't prevent much, may be possible to rename or remove this upstream feature to avoid misleading people. Chain of custody and device seizure processes typically instruct the device needs to be contained in a faraday bag as soon as possible and sent to a lab handled by a professional. Keeping a phone in the open exposed to any networks is very bad for them as it means someone could erase the device remotely.
Labs can come in different degrees of capability and they can be moved to better labs if the current lab fails to extract evidence. Good example is a local PD to an FBI lab. Some may be instructed to go directly to higher levels. I'm aware the FBI has a few national labs called Regional Computer Forensics Laboratory (RCFL) who get involved with serious crime seizures or more advanced/risky seizure targets. They do some pretty weird stuff!
By that time the phone moves to a lab the auto-reboot should have triggered unless you're so high priority they make the move to a lab and ask for that fingerprint on the same day. If they are aware of the nature of the device, they could try getting to work immediately in a portable lab as well which changes the circumstances... but they would need to know you're using GrapheneOS. FBI do a lot of surveillance work so they'd watch you to make sure they can figure out your PIN. Using a fingerprint protects this from happening.
The duress PIN / password is in the works, and also work towards a second-factor PIN for fingerprint unlocks have been quite steady and is heading towards the late stage. It's likely to combine these features too. While they are good benefits, it also means that they will treat the device differently if they know this feature is present on your phone before they get it. They won't make you touch the device at all, but with auto-reboot that could also be a blessing.
Auditor version 79 released:
- modern Material 3 UI overhaul
- use edge-to-edge layout
- update CameraX library to 1.3.3
- update AndroidX Core library to 1.13.0
- update Bouncy Castle library to 1.78
- update Guava library to 33.1.0
- update ZXing library to 3.5.3
- update Gradle to 8.7
- update Android Gradle plugin to 8.3.2
- update Kotlin to 1.9.2
https://github.com/GrapheneOS/Auditor/releases/tag/79
#GrapheneOS
See attestation.app/about and attestation.app/tutorial for information about Auditor and the optional device integrity monitoring service.
#GrapheneOS
Auditor version 79 released:
- modern Material 3 UI overhaul
- use edge-to-edge layout
- update CameraX library to 1.3.3
- update AndroidX Core library to 1.13.0
- update Bouncy Castle library to 1.78
- update Guava library to 33.1.0
- update ZXing library to 3.5.3
- update Gradle to 8.7
- update Android Gradle plugin to 8.3.2
- update Kotlin to 1.9.2
https://github.com/GrapheneOS/Auditor/releases/tag/79
#GrapheneOS
IF AN EXPLOIT LEVERAGES ACCESS TO THE FULL FILESYSTEM THEN THEY CAN JUST MAKE A COPY OF THE MESSAGE DATABASE, KEYS, AND FILES AND MAKE A RECOVERY
RECORDING THE DISPLAY IS ALSO AN OBVIOUS WAY
REAL END TO END ENCRYPTION IS DOING THE ENCRYPTION ON THE USER'S PHONE. IF YOUR APP DOESNT DO THIS THEN IM AFRAID YOU ARE BEING SCAMMED. THEY WOULD NEED TO PUSH A MALICIOUS UPDATE ON BOTH THE SERVERS AND THEIR APP FOR MESSAGES TO BREAK MESSAGE CONTENT.
RUNNING A GLOBAL CONSPIRACY OF COMPROMISING A COMPANY, APP AND SERVERS TO GET AN IRRELEVANT NEWS REPORTER = MONTHS IF NOT YEARS OF WASTED TIME, STUPID, EASY TO GET CAUGHT
PRESSING THE ZERO-CLICK STEALTHY EXPLOIT WITH SPY PAYLOAD BUTTON = IMMEDIATE RESULTS, THE SMART WAY, HARDER TO CATCH
HE LIKELY HAS NO CYBER SECURITY EXPERIENCE AT ALL. HE IS A NEWS REPORTER. ALSO WE CANT REALLY BE SURE IF WHAT HE IS SAYING IS EVEN TRUE BUT THATS OKAY.
IN END TO END ENCRYPTION THE SECURITY OF THE ENDS STILL MATTER. ITS ALL GONE TO WASTE IF ANY OF THE CHATTERS ARE FUCKED.
He uses GrapheneOS every day... according to the man himself 😄 It is likely the Damus relay.
Due to frequent DDoS attacks, we're enforcing stricter limits on the number of connections to our servers. By default, each server enforces a limit of 16 or 32 TCP connections from each IPv4 address and IPv6 /64 block. During persistent attacks, these limits will be adjusted.
We've determined these limits are high enough to avoid causing issues due to CGNAT. Browsers open a single TCP connection to each domain or server due to HTTP/2 multiplexing. Our focus is tuning it to avoid it triggering for our network/update services (https://grapheneos.org/faq#default-connections)
The naive approach to enforcing TCP connection limits starts with the initial SYN packet. An attacker can leverage this to their advantage with a spoofed SYN packet flood to fill the connection limit tracking tables to bypass them or block all new connections if you fail closed.
Tracking all connections with conntrack is enough to open up a new denial of service attack vector since the conntrack table can be filled by an attacker. For this reason, we were previously making all inbound connections untracked and are still doing that for both UDP and ICMP.
To prevent conntrack table exhaustion, we're using synproxy for SYN packets above a rate limit of 1024/second with 128 burst.
To prevent abusing connections limits or filling the sets enforcing them, we're only counting successfully established connections towards the limits.
Both the official documentation for netfilter (iptables/nftables) on connection limits and every guide we've found are vulnerable to all 3 of the attacks described above. There's info on using synproxy, but not combining it with connection limits or rate limiting it kicking in.
Our firewall configuration is published at
https://github.com/GrapheneOS/infrastructure/tree/7782c861cb560c91813ef6d85374830c3526f61a/nftables
and provides a reference on how to do this.
There are 4 cases for the connection limits to handle both the non-synproxy and synproxy cases for both SYN packets and the first ACK for newly established connections.
Newly established connections (valid first ACK) without synproxy are added to connection limit sets or rejected if above the limit. The connection is marked to bypass the checks going forward. For synproxy, this has to be done for the spoofed SYN packets it sends via loopback.
For web services with HTTP/2 enabled, we're still enforcing a connection limit at the nginx layer since each concurrent HTTP/2 request over the same TCP connection is considered a connection. For other services, we've removed obsolete application layer per-IP connection limits.
Our new approach is superior because it enforces the limits at the firewall layer without needing applications to process and reject the connections. The reason we didn't previously enforce the limits at the firewall layer is because the typical approach opens up new weaknesses.
Implementing connection limits with nftables required coming up with a good approach to avoid spoofed SYN packets counting towards the limits or bypassing the limits by filling the sets. It also required using synproxy to prevent conntrack table exhaustion, but only when needed.
Synproxy uses Linux SipHash-based SYN cookies for stateless establishment of TCP connections, but unlike typical SYN cookies it happens at the firewall layer. On success, it injects an ESTABLISHED state connection into conntrack and spoofs the TCP handshake to backend server.
Linux SYN cookies rely on TCP timestamps to store full options. If timestamps are disabled as Windows does by default, window scaling and SACK are lost. Not having scaling is horrific (only 65535 bytes in transit at a time). Timestamps are useful so it hurts a bit with them too.
Commenting is fine too
Do you mean opening the apps switcher from the home screen? If so then swipe up slowly from the bottom, it should do that instead of showing you the apps list.
You can always troll mobile forensics companies. It is always morally correct.