Hackgate is what started everything for me. My interest in mobiles, communications and security started afterward. It is an incredible research to read... It's a shame it's so underestimated due to how comprehensive it is, which also makes it difficult to fully understand. A lot only talk about the murder victims or royal officials. There are key events spanning decades, and the groups responsible were from so many different groups of media, law enforcement and private investigations that it's comparable to systematic corruption. Even I fully don't get it years later, but I still try.

The whole "Web3" association made it seem like Skiff was on a route for rebranding or failure to me. I saw nothing wrong with them. A massive shame that is what their fate has become. Hoping their users can find closure and comfort.

GmsCompatConfig (sandboxed Google Play compatibility layer configuration) version 95 released:

GitHub

Release config-95 · GrapheneOS/platform_packages_apps_GmsCompat

Changes in version 95: add stub for Vibrator.addVibratorStateListener() since it requires the privileged ACCESS_VIBRATOR_STATE update max supporte...

GM! ⭐ New #GrapheneOS release v2024020500 with the latest security update, additional early security fixes, security enhancements for the kernel and quality of life improvements. See the changes: - full 2024-02-01 security patch level - full 2024-02-05 security patch level - rebased onto UQ1A.240205.004 Android Open Source Project release - run full explicit GC in SystemUI and system_server after locking (this is already done after unlocking to purge data tied to the lock method and derived data, but it makes sense to do it after locking too) - kernel (Pixel 4a (5G), Pixel 5, Pixel 5a): update to latest Android 14 QPR2 Beta release including additional security fixes - kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision including update to 5.10.209 - kernel (Pixel 8, Pixel 8 Pro, Generic 5.15): update to latest GKI LTS branch revision including update to 5.15.148 - kernel (Pixel 8, Pixel 8 Pro, Generic 5.15, Generic 6.1): enable both software Shadow Call Stack (SCS) and Pointer Authentication Code (PAC) protection for kernel return addresses instead of only using SCS when PAC is unavailable - kernel (Pixel 8, Pixel 8 Pro, Generic 5.15, Generic 6.1): enable Branch Target Identification (BTI) protection for the kernel in addition to Clang type-based CFI to provide coarse-grained CFI coverage for calls excluded from CFI - kernel (Generic 6.1): apply sysrq hardening changes - kernel (Generic 6.1): update to latest GKI LTS branch revision including update to 6.1.74 - Settings: enable SIM deletion confirmation by default - System Updater: clarify notification for already being up to date - Messaging: update MMS configuration database based on Google Messages 20240123_01_RC02 - Dialer: update visual voicemail (VVM) configuration database based on Google Phone 121.0.603393336 - Vanadium: update to version 121.0.6167.143.1 - Camera: update to version 66

Releases | GrapheneOS

In my lookout for media involving GrapheneOS, some appear to make "examples" of GrapheneOS being unextractable against some small, irrelevant mobile forensics software. These do nothing to show OS hardening capabilities. Free trial, small fry software suites have no unique exploits and the gold lies in what is not for the general public. Free/public editions of software would need a surrender of OS credential practically every time and they're essentially used for training, research, or consented investigations. They are not the focus of what would interest me, personally. When you aren't putting in any effort, of course GrapheneOS won't work. You can't just click a button and extract, that's silly. You could give the credential away, disable the screen lock, enable USB debugging and give it a shot but you won't be surprised about the results. There *could* be merit to deploying a userdebug / eng build in a test environment and doing a consent extraction to simulate a scenario. You could then assess forensic artefacts of apps or differences between GrapheneOS and stock for research with one of these free suites. I've done this a couple of times. It still has nothing to do with the security of the OS because you'd never, ever deploy a testing OS with root access. Also unrelated, half the UIs look like complete garbage. What I can judge about the big industry names is they have great UIs, feels like only Cellebrite, MSAB, Oxygen care from what I see. Magnet is a mixed bag, some of their software just needs a revamp...

Old comment of mine relating to what I desire in a smartphone, I will write a modern complete and greater accurate version eventually.

Stacker News

Competing with Apple and Google - A Weekend Discussion \ stacker news

A growing concern in the tech community is the gatekeeping of Apple and Google through their respective app stores. Last week Damus, Zeus, and Fold...

Upcoming kernel hardening enhancements in #GrapheneOS for the Pixel 8 and 8 Pro: ARMv8.5 / ARMv9 Branch Target Identification (BTI) will be enabled for the kernel, allowing additional protection around indirect branches traditionally excluded from Clang's Control Flow Integrity protection. This will protect against Jump Oriented Programming attacks further. ShowCallStack and Pointer Authentication Code (PAC) protections will be both enabled instead of only PAC. SCS + PAC will be used so that PAC is a security upgrade instead of a questionable sidegrade.

People pleasing is over. Become unacceptable.

Interesting open, portable audio player

Crowd Supply

Tangara

The music player you wish you had in the early 2000s

Some users seem to not know where to find it, but you can add the #GrapheneOS changelog to your feed reader:

GrapheneOS changelog

Vanadium version 121.0.6167.143.0 released:

GitHub

Release 121.0.6167.143.0 · GrapheneOS/Vanadium

Changes in version 121.0.6167.143.0: update to Chromium 121.0.6167.143 A full list of changes from the previous release (version 121.0.6167.101.3...

#GrapheneOS

Leaving my small rambled thoughts on this since I am seeing this discussion everywhere: When making a censorship-resistant public network or service the primary objective comes with the relays distributing events with the furthest outreach and as fast as it can to make censorship near-impossible. #Nostr systematically doesn't really care about privacy, and why should it? That's not always the goal... The entire Nostr ecosystem is designed to be transparent. If you want a communication method that's opaque then you would use a private messenger instead. Using Tor or a VPN should be a given for risky people. The relays are a valid concern but even if the Nostr network or client had proxying then you are just moving the goal posts and trusting that proxy instead. Onion routing by default could help but then it becomes a scalability problem of relays vs. proxies. I really don't know how you could make a system designed for extremely public, far reaching, permanent posting private that also has a scaling as large as Nostr does. I'm not saying clients shouldn't discuss these privacy caveats though. They should. Especially since not just relays, but other users could see IPs due to all media being hosted remotely. Events on Nostr are also all tied to a persistent, cryptographic pseudonym at the minimum. We know realistically you can't erase posts. Erasing your own posts can be loosely defined as self-censorship, so why would you have the ability to do so easily on a censorship resistant network? Privacy isn't the objective of a public social network anyone can read. Do you expect #privacy on Twitter, a site where Internet Archive scrapes individual tweets all the time, Bing saving caches of tweets in the search results deleted or not, and where you can do advanced, fine grained searches on tweets with advanced parameters on the platform itself? Why should people expect Nostr to be private when people use it like Twitter? For those who understand Nostr, that's fine, but there is unfortunately a portion who don't. Is there an issue with people adopting services and technologies without assessing them? I think so sometimes. Being into #Bitcoin doesn't always mean aptitude in technology (and that's fine!) but I guess I stopped being surprised that people are surprised. Going back to the beginning, Nostr like Bitcoin is more transparent than private and has the goal of censorship resistance, not privacy and you need to use your own setup. Nostr's only objective is distributing media, privacy features is the job of apps integrating Nostr and the users of the apps and the network. Feel free to discuss this with me. Would like to hear your thoughts.

I consider being able to make a web page something a young person should attempt to do, preferably in school. Learn the basics of HTML, CSS and you can pretty much make a small site about anything. You see a website that looks cool? The markup is your documentation. Read the HTML and look at the styles. Teens seem to love one-page site links for their social media like Carrd, I think it would be the next level for them. It doesn't matter if it's ass to begin with, you make better pages as you keep making different sites. After I discovered static site generation then the work flow improvements was marvelous.

Vanadium version 121.0.6167.101.2 released See changelog:

GitHub

Release 121.0.6167.101.2 · GrapheneOS/Vanadium

Changes in version 121.0.6167.101.2: rebuild to fix arm64 32-bit WebView support which was omitted in the last build and not noticed even days aft...

#GrapheneOS

GM! 🔥 #GrapheneOS version 2024012600 is out with several #security enhancements and improvements to eSIMs. See the changes! - isolate eSIM activation app from non-system apps to avoid it sharing data with sandboxed Google Play - make eSIM activation toggle available without sandboxed Google Play installed - make the eSIM activation app toggle persistent instead of it being disabled at boot - remove misleading message about device info being sent to Google message before eSIM download - hardened_malloc: use tag 0 for freed slots instead of reserving a tag to allow using 15 of 16 possible tag values for random tags (there are 3 dynamic exclusions of the random values for the previous tag along with the 2 current or previous adjacent tags) - Settings: prevent disabling Camera2/CameraX extension provider app (Pixel Camera Services for Pixels) since it breaks apps using CameraX - kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro): use a normal reboot on overheating instead of an emergency reboot to harden against physical attacks - kernel: enable reset attack mitigation for UEFI systems supporting it (Tensor Pixels use minimalistic littlekernel-based boot firmware rather than UEFI and the previous Snapdragon Pixels using UEFI didn't implement this but we may need this for future devices) - kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision including update to 5.10.208 - kernel (Pixel 8, Pixel 8 Pro, Generic 5.15): update to latest GKI LTS branch revision including update to 5.15.147 - kernel (Generic 6.1): update to latest GKI LTS branch revision including update to 6.1.73 - Launcher: disable gradient at the top of the home screen again (change lost with Android 14 QPR1 due to it being reimplemented upstream) - rewrite HTTPS network time implementation to make it much more maintainable and robust along with providing better debug output via ADB - Vanadium: update to version 121.0.6167.101.1 - GmsCompatConfig: update to version 93 Seedvault: update to latest revision (will be replaced with a better backup implementation in the future)

Releases | GrapheneOS

Next #GrapheneOS update now includes some hardening against reset attacks to prevent potential ways of bypassing our memory zeroing features. This is a response to the exploit we previously reported to Google of forensics companies exploiting a RAM dump from fastboot firmware to brute force OS credentials in Pixels running the stock OS. While not suggested to affect GrapheneOS nor should a user be concerned, this will be an additional security enhancement for our users anyways. Thermal reboots are unsafe reboots that don't erase memory safely. They have now been changed to perform safe shutdowns instead. It stops a threat with physical access and RAM dump capabilities from overheating the phone to force an unsafe reboot into fastboot. A reset attack protection mechanism has been enabled for supported UEFI systems. While we don't support devices using UEFI or the UEFI reset attack protection mechanism, it could come useful in later devices. These protections will be one of multiple to kill the capability for good. Read about the original exploit on my post on stacker news:

Stacker News

GrapheneOS discloses vulnerabilities actively exploited by forensic companies \ stacker news

Link: https://x.com/GrapheneOS/status/1745506661467299946 Nitter: https://nitter.net/GrapheneOS/status/1745506661467299946?s=20 Overview The team a...