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

GitHub

Release config-96 · GrapheneOS/platform_packages_apps_GmsCompat

Changes in version 96: update max supported version of Play services to 24.07 update max supported version of Play Store to 39.7 update Android Gr...

#GrapheneOS #privacy #security

Vanadium version 122.0.6261.43.0 released: - update to Chromium 122.0.6261.43 - checkout PGO profiles by default now that PGO is enabled by default for Android production builds #GrapheneOS

#GrapheneOS project announcement: TLDR: Moving away from Signify keys to OpenSSH keys to sign releases, which has better platform support and is overall a benefit. SSH public key for signing GrapheneOS releases: contact@grapheneos.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIUg/m5CoP83b0rfSCzYSVA4cw4ir49io5GPoxbgxdJE This key has been used for signing our Git tags since January 2023 and will also replace signify for factory images releases. Official builds of GrapheneOS are signed with per-device signing keys for updates and verified boot. Those signatures are automatically verified. The signatures for source releases (Git tags) and factory images are a separate thing and we're standardizing on using SSH for those. We replaced GPG with signify for signing factory images in 2019 prior to SSH having file signing support. Signify is perfectly modern, unlike GPG which is a poorly designed legacy technology. However, SSH signing is a lot more broadly available than signify and is a bit nicer. Our SSH public key is signed with our previous GPG and SSH keys: Key: https://grapheneos.org/allowed_signers Signify signature: https://grapheneos.org/allowed_signers.sig GPG signature: https://grapheneos.org/allowed_signers.asc GPG key has been fully retired for a while and the signify key will also be retired going forward. We've completed replacing the factory images signify signatures with OpenSSH signatures. It only impacts users following the traditional CLI install guide. It's a nice improvement since Windows and macOS have it in the base install and nearly all Linux distributions package it. Each supported OS for installation either has a Chromium-based browser in the base install (Android, ChromeOS, Windows) or a first party repository with one available, so the web install avoids this problem and relies on verified boot for verifying the flashed firmware and OS.

Vanadium version 121.0.6167.178.0 released 10 hours ago, btw: See the changes: - update to Chromium 121.0.6167.178 - disable selecting initial search query text for the web and global search intents added by GrapheneOS #GrapheneOS

GitHub

Release 121.0.6167.178.0 · GrapheneOS/Vanadium

Changes in version 121.0.6167.178.0: update to Chromium 121.0.6167.178 disable selecting initial search query text for the web and global search i...

A self-reliant, full-time open source software developer lives off of donations to continue their work, put food on the table and put a roof over their head. Exploit brokers offer bounties on exploiting their work for tens of thousands regardless, money that could have helped these developers not live off waiting for the next donation or having to run fundraisers. There's an ethical question behind an industry like that.

My Nostr likes list looks like this

If you are protecting your technology and your first thought isn't your mobile device then you are not going to make it. In my opinion mobile security is always my first priority. What you use most should be the most important of all things you have to protect, for most, that is your phone. The technology you carry around with you on a day to day schedule has far more data worth something to a threat. Where ordinary people spend time more on their phone than they do a computer, a phone is the golden ticket to your life. Even if you have nothing of value to worry on compromise now, it doesn't mean that will not have something valuable later after further use. Where a computer manages day to day work tasks, a phone often manages people's lives. They are an irreplaceable tool in society. Your communications, photos, videos, documents, online activity or possibly even your finances and identity are managed on portable devices. The most promenant attack campaigns we know from world affairs involve targeting smartphones, some of the most expensive bounties for zero-days involve mobile software, and there are multiple industries whose main objectives are to find and attack smartphones. Threat actors love smartphones. Protect what is most valuable.

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.