(Poll) Help us shape iodé!

  1. Add Sony Xperia XZ1 Compact (lilac) as an official device. It uses the same common repos as the XZ1 (poplar) which is already supported, plus device specific device tree and vendor blobs from the same upstream maintainer. Unofficial build (of Iodé 4 already runs well enough for use as a “daily driver”
  2. Upgrade XZ1 (and XZ1 Compact) to Iodé 4
  3. Enable rooted debugging in released builds, so that Android Backup and Restore Tools project can be used for backup / restore/ migrate.
1 Like

I would not make use of any option proposed in the poll.

In my opinion:

  • Must have: security improvements, e.g. security updates guaranteed in less than a month, major updates faster than now as I do not have Android 13 yet on my Fairphone 3+, verified boot with a custom key, etc.
  • Nice to have: easiest installation possible without any commands to type in or impossible to make mistakes, same criteria for backups as Seedvault is not satisfying.

Basically I think iodé should only work on things that cannot be done by anything else than the operating system. When I need another service, I can search for a provider.
I come from /e/ and it was really refreshing to discover that iodé was not baking in other apps or services, making the whole product worse in the process.

I am happy with iodé as it is, and improvements stated above would make it excellent.
Thank you to all the team.

1 Like

I also consider verified boot with a private custom key important on any device where it is possible. I had the impression that iodé had not thought about this with the FP3(+) at the time. Fortunately, this was implemented later with the FP4. With the Pixel 4 and 5 with iodéOS 3 also. However, I was surprised that there is seemingly no verified boot on the Pixel 3 with iodéOS 3 and the Pixel 4, 5, 6 and 6a with iodéOS 4? Why not? (Or am I wrong about that?)

2 Likes

Bonjour.
FR : Tel que discuté ailleurs sur ces forums, la fonction d’iodéBrowser d’envoi des pages à un autre appareil ne fonctionne plus (puisque Firefox utilise Firebase pour cela, lui même racheté par Google). Une alternative serait la bienvenue - J’utilise Nextcloud, cela peut faire partie de la solution. Le module Nextcloud de gestion des signets/mot de passe pour Firefox ne se télécharge pas pour iodéBrower.

GB : Discussed elsewhere on this forum, iodéBrowser tab sending feature to another device is not working anymore (as Firefox relies itself on Firebase for this feature, Firebase was bought by Google).
An alternative is welcome - I use Nextcloud, maybe a solution could be found. The Nextcloud plugin for bookmarks/passwords doesn’t install for iodéBrowser.

Merci !
Pascal

let’s have a look to floccus
i use it as browser plugin and standalone app on android (f-droid)
works well

https://floccus.org/

Yes we definitely think it’s a must have to have a detailed technical documentation and changelog. We have started working on this, but it will probably take over a month to get a first online version of the doc.
In the meantime there is a first draft of the documentation available here: iodéOS documentation and changelogs are available as usual in our news app.

  1. 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.

  2. Yes good points, thank you for the suggestions. We will discuss internally what to implement first.

  3. How would that look like? Based on what?

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.

  1. Yes we will add this in the future
  2. 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.
  3. 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.

We are looking for the possibility to add a donation gateway via wire transfer to our donation page

  1. 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.
  2. They are currently in beta phase
  3. 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.

  1. 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.
  2. 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

@Antoine

  1. Nice thats great :slight_smile:
  2. True thats a solution to my needs.
  3. 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

  1. 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.
  2. 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! :slightly_smiling_face:

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? :thinking: