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.
Invidious frontends by default do not proxy the videos. It gets the source video URL directly from Google. Some instances will allow you to proxy but need to manually set it.
Piped always does this, but there are still other merits to using Invidious depending on the situation (for example Piped requires JS while Invidious does not, and Invidious also works far better on Tor Browser).
App choices are totally up to the user, take a look and see what you prefer. In a perfect future we can hope more of these apps are maintained with replacements that have better usability. We certainly lack the current manpower for something like that...
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm Just wondering if you have any thoughts/advice on adding additional keyboards to GrapheneOS. My combo of Pixel8/GOS/Amethyst is causing some bugs that are resolved by using AnySoftKeyboard. I have concerns, but they're all founded in ignorance.
The stock AOSP keyboard is certainly lacking. We have had plans to try and integrate a keyboard in the past - but it's fallen short due to open source licensing issues. Sorry...!
There really wouldn't be an issue with using a Keyboard app you trust. Some people use an app like yours, Helium OpenBoard and FlorisBoard (Alpha versions *only*). Some may use GBoard or another keyboard app and disable the internet access as well.
It would be nice to have an improved keyboard and it's still considered.
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:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-95
The changelog entry regarding explicit GC after locking has been updated for clarification:
- run full compacting garbage collection purging all regular Java heaps of dead objects in SystemUI and system_server after locking
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
Worth noting this is a standard Android feature, just that GrapheneOS requires hardware accelerated virtualization before we can support a device.
(Hardware accelerated virtualization also needed for desirable future security and usability features. It has an extremely large room for potential!)
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...
And by old I mean... old. I wasn't even part of GrapheneOS when I wrote this.
Old comment of mine relating to what I desire in a smartphone, I will write a modern complete and greater accurate version eventually.
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.
Projects like this do get the crowdfund tax, likely to handle the costs to be able to mass-produce or work on future projects. It's pretty cool, but a secondhand iPod or Sony with Rockbox firmware would fill the space for some people who can't afford.
Can play Doom on a Rockbox player too...
Interesting open, portable audio player
None right now.
We've attempted multiple times working with an OEM but they haven't worked out because they either are not capable or do not want to meet the requirements we set (or the required quality of the implementations of the requirements...)
We want to still be hopeful that it will be worked out eventually.