GrapheneOS version 2024111700 released:
https://grapheneos.org/releases#2024111700
See the linked release notes for a summary of the improvements over the previous release.
spiral
- Joined Jul 25, 2022
@spiral:4d2.org
We have a thread about iOS 18.1 integrating the auto-reboot feature we pioneered in GrapheneOS:
https://grapheneos.social/@GrapheneOS/113450097776800819
We proposed it for inclusion in Android in January 2024 but it has yet to happen and it's likely they weren't going to do it based on our proposal. They'll almost certainly add it now, but they could have just listened to us.
Whatnoww It's available as a feature of the hardware keystore and it's up to apps to use that API for an additional layer of disk encryption. Android is going to be providing APIs for an iOS style data class available only while the device is unlocked and hopefully it's implemented better. We can harden it if it fails to hold up properly to attacks.
- In OEM unlock
grphnswimmable376 So only do i need is to connect to an open-, public wifi network some km far from my home.... that is it?
If you are "not a superhero" and your goal is "general de-googling my life", it is not clear why any cloak-and-dagger action is required.
Performing the "check-in" step via public Wi-Fi stops Google from associating your IMEI with your home address. OK, but then the phone will be wiped and apps installed under GrapheneOS -- even Google apps -- won't have access to your IMEI.
It might be productive to indicate what you hope to gain by going through the extra effort of OEM unlocking anonymously. As Dumdum pointed out, it is not a requirement for successfully installing GrapheneOS.
gos-users This has been discussed before and I believe the concensus is you should consider each profile protected by it's own lock method, not the owner.
Hi there! I appreciate the effort and thought put into this post.
Unfortunately, the raspberry Pi is way too far from being close to meeting the project's requirements.
In case you haven't already, please take a list at our official list of requirements here:
iraqi_sunburn Wow.
I have never used a work profile, thus never used Shelter. Is "autofreeze when I hit the widget" a Shelter feature? If so:
- it might (or might not) be helpful to ask the Shelter author for advice.
- It might be productive (in a general sense) to file a request that the Shelter app to refuse to "autofreeze" any system apps, since that is (as empirically determined) a recipe for disaster.
Another question if I may, would the duress pin be triggered if there was a brute force attempt?
If I understand this post correctly, unfortunately it looks like this is currently not possible:
Duress PIN/password is an OS feature without secure element support. An attacker successfully exploiting the OS can try the duress PIN/password without risking a wipe since they can control the OS. In theory, the secure element could implement duress PIN/password support by having a 2nd authentication token for each Weaver slot which wipes the Weaver token instead of providing it. There's no way for GrapheneOS to implement this without having our own hardware where we can add secure element features.
Oh this is awesome:
A nice example usecase would be have the duress pin written on a label inside the phone case, or set it to 1234, so that if someone steals the phone, odds are they'll think it's the unlock pin, and will wipe it.
Viewpoint0232 I'm not really sure that this is the correct forum to provide or discuss legal matters like that. Things are going to wildly differ in different parts of the world, and these things can change at moment's notice.
GrapheneOS has designed a feature with a clear goal and a focus on reliably doing what it says. Beyond that, it is up to people to decide if, how, and when to use it.
Heliboard is a great option.
rusty-cheeto I hope the dev team is open to more perspectives than one individual
Just saying so that it's clear, I'm not part of these conversations but I do know that this isn't the case. Features, decisions, etc are discussed by multiple people. Decisions aren't made by one person. Please don't make assumptions like this.
You have to keep in mind that they have thought through these things. They've been working on this feature for a long time. If you read through the issue that was linked you'll see that deleting profiles can't be done in a way that doesn't leave traces of the old deleted profiles.
You can use jmp.chat and their app Cheogram
GlytchMeister I was going to get obtainium first, but... uh... I don't actually see a button in github to install it? do i need a github account?
Perhaps this guide may help you out
https://sideofburritos.com/blog/obtainium-overview/cdflasdkesalkjfkdfkjsdajfd As far as I'm aware, there are no such plans. If you're in a situation where you want to trigger a duress wipe like that, why would you want the eSIM to stay?
If you are not in a duress situation and want to wipe, just factory reset instead.
Recently, I decided to migrate from iOS to Graphene. Since everyone around me uses WhatsApp and I have chats that I don't want to lose, I decided to spend a few hours figuring out the best way to migrate chats from one OS to another.
I will provide some context before diving into the topic. iOS has a way to migrate chats from an iPhone to an Android device (GrapheneOS doesn't work; it has to be an Android device), so I decided to start here.
In my case, I don't have another mobile device with Android, so I used the Pixel to capture a copy of the iOS backup on Android. If you are starting from an Android device, you can skip directly to step 2.
Note 1: Stickers will not be transferred, but there will be a copy of all the sent stickers in the chats. I will later explain how I managed to recover the stickers if needed.
1. I started by following this guide: https://support.google.com/android/answer/14669513?hl=en&co=GENIE.Platform%3DiOS. It basically explains how to transfer the app from iOS to an Android device. In my case, I only imported the WhatsApp app and nothing else. I followed the guide to bring all the chats and restore the backup.
2. At this point, the Android device should have a copy just like it was on iOS. Now we will make a copy, but we will not use the Google Drive cloud backup. Instead, we will make a local copy on our PC to later recover it on the device where we have installed GrapheneOS.
Note 2: The Windows file explorer doesn't work very well when transferring many files. It freezes and doesn't transfer the information. To avoid using this method, we can use the adb tools (https://developer.android.com/studio/releases/platform-tools).
Activate developer mode in Settings > About phone and click on the build number until they are activated. Next, enable USB debugging in Settings > System > Developer options.
3. Connect the Android device to the PC with the USB cable and use the adb tools to transfer the files to the PC. In my case, I used these commands to transfer the files:
.\adb.exe pull /sdcard/Android/media/com.whatsapp C:\Whatsapp_Backup\com.whatsapp
.\adb.exe pull "/sdcard/Android/media/com.whatsapp/WhatsApp Images" "C:\Whatsapp_Backup\WhatsApp Images"
.\adb.exe pull "/sdcard/Android/media/com.whatsapp/WhatsApp Stickers" "C:\Whatsapp_Backup\WhatsApp Stickers"
.\adb.exe pull "/sdcard/Android/media/com.whatsapp/WhatsApp Video" "C:\Whatsapp_Backup\WhatsApp Video"
Note 3: I recommend doing it step by step, as you can miss some folders in the transfer and not notice it. In my case, I had to isolate those three folders at the root of C:\Whatsapp_Backup and import them one by one later. I will leave you the commands I used as an example:The folder structure is as follows:
C:\Whatsapp_Backup\com.whatsapp C:\Whatsapp_Backup\WhatsApp Images C:\Whatsapp_Backup\WhatsApp Stickers C:\Whatsapp_Backup\WhatsApp VideoSo the commands to transfer were:
.\adb.exe push C:\Whatsapp_Backup\com.whatsapp /sdcard/Android/media/
.\adb.exe push "C:\Whatsapp_Backup\WhatsApp Images" "/sdcard/Android/media/com.whatsapp/WhatsApp/Media"
.\adb.exe push "C:\Whatsapp_Backup\WhatsApp Stickers" "/sdcard/Android/media/com.whatsapp/WhatsApp/Media"
.\adb.exe push "C:\Whatsapp_Backup\WhatsApp Video" "/sdcard/Android/media/com.whatsapp/WhatsApp/Media"As I mentioned earlier, I was forced to do it this way due to the absurd amount of files in those folders. You can try to do it all with the first command without moving the folders out of "com.whatsapp," but it didn't work for me because of the file volume.
4. Once we have the WhatsApp copy on the mobile device, we can install WhatsApp. In my case, I used Aurora Store, logged in with my mobile phone, and after granting permissions to the app, it should detect that you have a backup to restore. Click on restore, and you will have your backup restored.
Extra. To recover stickers, I simply took a copy of the WhatsApp Stickers folder and used this application (https://github.com/qarmin/czkawka) to delete all duplicates (note that it stores all the stickers sent in the chats. In my case, I had 19600, so I used this app to speed up the inhuman task of doing it manually). I uploaded the remaining stickers to a folder on my mobile device and restored the ones I wanted with the "Sticker Maker" app.
kd92jew
KDEConnect has this functionality.ryrona I also by chance discovered a flaw in the app permission UI, where not all file based permissions show up, possibly misleading the user to believe an app do not have access to files and media at all, when it fact it has full read/write access to the whole file system. I reported this issue today too.
As discussed in the issue itself, the permission can be found in Settings > Apps > Special app access. That's where it is in upstream. Mentioning it here for people who are not aware. It's not an issue, it's just how the AOSP UI is.
TRInvictus I don't know if that is part of AOSP or GOS
Almost certainly AOSP.
