Right now you can make define bulk rules using the search function in the customzied blocking settings and block for instance all ancountered domains having “googl” in their name if that helps.
We will add more advanced settings in the future.
Yes they are now public.
- Yes we will add this in the future
- You can restrict app access / visibility from home settings → protected and hidden apps, is that what you’re looking for? You can also use an alternate launcher.
- Would you like to be able to block by default all domains and whitelist them 1 by 1 or progressively?
We are baking a new feature that may help to see that more easily. No ETA on that yet though.
- Adding a supported device means work to maintain it up to date foe years to come that’s why we are picky about it. We usually favor devices that we find in stock from our refurbishers for now.
- They are currently in beta phase
- iodéOS uses user build type instead of userdebug for compatibility reasons. I don’t know the implications / feasibility of adding root debug to our builds. @vince31fr probably knows more about this.
But you can still be rooted if you’d like on iodé
Thank you for the suggestions.
- We try our best to provide the security patches ASAP for beta testers, they usually come a few days after LOS patches. We decided to provide beta OTA with security patches monthly for beta testers and OTA releases every 2 month as we don’t want to take risks for our customers with OTAs. The day we have enough beta testers/HR we will shorten releases to each month.
Verified boot is supported on FP, Pixel phones. - iodéOS installation process is similar to LOS, and there are loads of tutorials on how to install LOS, that’s why we currently don’t provide more details in that matter. I agree about Seedvault not being fully mature, for now we keep our focus on maintaining devices secure and working on privacy features.
To search when a request was blocked: you can filter the stream view by app and or domain.
Verified boot is enabled on all FP + pixel phones
- Nice thats great
- True thats a solution to my needs.
- Yes kinda like that. Maybe with some popups when a new domain is called and then you can either give it free or leave it blocked.
1 Like
Thanks for the response
Please can you tell me what you mean by “compatibility reasons”? I know in earlier Android versions, it was harder for user-debug builds to pass SafetyNet, but I believe that is no longer the case, with the inclusion of ih8sn and accurate ih8sn.conf files. My unofficial Iodé 4 builds are user-debug builds and pass SafetyNet with no problems.
I actively don’t want root on my devices. I only want rooted debugging
- Mainly, so that I can backup my user-installed apps and data using Android Backup and Restore Tools project, which is the only available working backup and restore solution.
- When my builds have problems, it is easier to work out what the problem is
Thanks again
Yes we can protect apps but i want to be able to set a different password from the phonelock password and to be able to to deactivate the biometrics. I want to make a digital detox and want to block the stores so that i cannot download a browser or newpipe or similar.
Thank you @Antoine for your answers! 
If the smartphone has lost connection to the last actively connected WiFi for X minutes, automatically turn WiFi off completely.
Example: If I leave my home and my phone loses connection to WiFi, it will automatically switch off after 2 minutes.
If the smartphone has lost the connection to the last actively connected Bluetooth device for X minutes, automatically switch off Bluetooth completely.
Example: If I switch off my Bluetooth headphones, Bluetooth switches off automatically after 1 minute.
X minutes = freely selectable between e.g. 1, 2 or 5 minutes.
In addition, there should be the option that the mobile data is automatically switched off when a WiFi is actively connected. And the reverse option, that the mobile data is automatically switched on when no WiFi is actively connected.
What about point 4? Could the iodé team imagine thinking about this?
Imagine that you have lost your mobile phone or it has been stolen. Then it would be very helpful to make it impossible for even an experienced attacker to guess the PIN and get all the private data. (With “luck”, even a few attempts could be enough.) The mobile phone could shut down after a few failed attempts and/or re-entering the PIN is only possible after a certain waiting time. After an extremely large number of failed attempts (50?), the mobile phone could be deleted.
At iodé, privacy is in the foreground. Wouldn’t it therefore make a lot of sense to build in such protection? 
I am also interested in wildcard domain filtering. It would be desirable if the iodé blocker could regulate wildcards automatically via filter lists. Just as it does with all other domains. This could be done, for example, via an additional list that can be activated. Or possibly in several gradations as with the other lists. See also the blog article by Mike Kuketz: Pi-hole, AdAway, NetGuard und Co.: Wie DNS-Blocking mit speziellen Domains leicht umgangen werden kann ⋆ Kuketz IT-Security Blog
OK, but is it possible that the latest iodé version for FP3(+) and all Pixels has verified boot only with a public test key?
But I was talking about the private custom key, so that the security is increased.
I would have thought that if it is a private custom key, then it can be found on GitHub on the corresponding releases page?
Example FP4 with the file “avb_custom_key-FP4.bin”: Release iodéOS 4.x for Fairphone 4 · iodeOS/ota · GitHub
Example FP3(+) without the corresponding file:
Release iodéOS 3.x for Fairphone FP3 · iodeOS/ota · GitHub
Example Pixel 4 with the file “avb_custom_key-flame.bin” (but only with the old version iodéOS 3, with iodéOS 4 there is no file anymore):
Example Pixel 6a without corresponding file:
Either I understand this wrong and the private custom key is somehow solved differently for the devices that don’t have such a file on GitHub, or they only have the public test key?
1 Like
hey barry
the function of WLAN control as well as BT and NFC has been available in LOS for a long time.
under settings
system
system profiles
can you set what should be changed on the system if I leave the stored wlans, for example.
been using it for a long time and works great.
greeting sts
2 Likes
Thanks @sts61. I’ll have to take a close look at that. That comes what I want perhaps already quite close. But if I understand correctly, you have to specify each WLAN and each Bluetooth device explicitly. If you use a new connection that is not in the profile, the profile does not work. It would be better if the created rules generally work for all used WLAN and Bluetooth devices. As soon as there is no active connection to any Bluetooth device or any WLAN, make …
So probably only the following option would have to be added:
Triggers that activate this profile:
- any WLAN, 2. any Bluetooth device
Hi Barry
do I want every WLAN…BT…to control my phone?
no… only the ones defined by me.
Automatic WLAN and BT search is also off for me.
greeting sts
Hi, the private custom key can be found in fastboot packages for pixel devices, as this the way for initial installations. FP4 and Pixel devices all use custom keys, only FP3 uses the public test key. We realized too late (i.e. after releasing the first builds) that this key could have been changed, and did not want to force users to wipe their phone.
1 Like
As Antoine mentioned, we initially moved to user builds for compatibility reasons (safety net). Progress have been made in the field since then, with ih8sn and universal safetynet fix., facilitating safety net passing.
But another important aspects is privacy/security: user builds are more restrictive than userdebug builds (and are the AOSP recommended release type for producing builds, btw). You can get convinced by grepping userdebug_or_eng in system/sepolicy: each time see it, some relaxations are made in selinux rules, which are an essential part for ensuring privacy/security. It is, in our opinion, an evidence that userdebug builds increase the surface attack and/or potential privacy leaks, even if we cannot prove that userdebug builds are effectively less secure than user builds. It is just a question of attack surface which is obviously wider.
2 Likes