wow:

We use specifically crafted messages that trigger delivery receipts allowing any user to be pinged without their knowledge or consent

That makes think that 1st, perhaps it would be a good idea to avoid “return receipts” on any messenger, though that breaks ability to know if the destination has actually received, and if the destination has actually read the message.

Perhaps another thing, even though your messenger doesn’t identify users with phone numbers at all, still block the messenger to have access to your contact list. Not sure if this affects, for example if a xmpp client has access to a broader contact list, if it can only relate to xmpp addresses it wouldn’t pay attention to phone numbers, but I can’t really tell.

And of course, don’t use any messenger which tights users with phone numbers, no matter if to share among contacts now usernames are used instead of the phone number, when the phone number is still the way to identify the user.

True, but not entirely, signature spoofing needs OS support, and LOS and divestOS don’t, whereas murenaOS (/e/OS) and lineageOS for microG do. Other than that microG’s own f-droid repo makes it easy to keep microG’s component up to date.

That’s why I mentioned it would be nice to upstream divestOS bootloader lock/unlock at will solution, so that not just LOS, but derivative ROMs can inherit that solution. As some people don’t like the tight integration from murena (/e/) with all of its rebranding, LOS for microG is a very appealing option, if wanting full microG’s support. Actually LOS for microG was there quite before /e/ was created.

That’s great if not having to use any proprietary apps depending on google services, including push notifications, since part of divestos unsupported stuff includes:

Google Apps or microG or Sandboxed Play Services are NOT supported.

Which is fine, if you don’t need to use such apps. An alternative to /e/os, which now a days is actually murenaOS, is lineageOS for micro G, which does sort of monthly releases based on whatever is available as nightly releases on lineageOS. It does provide you with microG and also with F-Droid with privileged extensions installed and already set for you. This might be more suitable than divestos if in need for some such apps.

Yup, divestOS allows for booloader lock though unfortunately they don’t support microG. I hope they somehow help upstream their relock solution to LOS. I use LOS for microG instead, since I need stupid bank apps and also for the office some stupid proprietary multi factor authentication apps… If only LOS for microG could lock the bootloader at will (it needs to be unlocked for major upgrades, like on regular LOS), that’d be great.

There’s as well CalyxOS, which uses microG and also locks the bootloader, however I do prefer LOS since the strategy from CalyxOS and GrapheneOS trying to deGoogle pure Android in my mind sound like having some limitations, as opposed to LOS approach to be based on AOSP instead. Though that’s just in my mind, I’m sure those guys in Calyx and Graphene are the best at security and privacy.

Not sure what updates you are expecting to happen.

I’m not aware of any effort trying to identify the traffic going in and out on Thunderbird under android. The guesses from the one reporting about what happens when configuring a new email account is of no use since it’s easily associated to Thunderbird looking for ways to easy automation on new accounts settings.

Unless there’s a throughout analysis of the traffic, I’m not aware of anything to be expected. You can try reaching the one reporting his concern, and ask if he has looked into how to report an actual issue/bug to Thunderbird, or if someone else has done it

Quick question, why not considering lemmy as your “blog” provider? If the “community” concept wouldn’t apply, perhaps creating your own “community” and becoming its “mod”, disabling posts from others except yours, wouldn’t that work? Lemmy already provide RSS feeds so others can follow/track your posts without any lemmy account, just like with any blog providing RSS/atom feeds, and you get “blog” feedback through lemmy, but the same applies to other blog providers, only the ones subscribed can provide feedback.

I was looking for an anonymous blogging mechanism with digital signature (not to identify the author but to verify its authenticity). Long story short, nothing out there seemed to really fit into what I was looking for, but among the suggestions lemmy was there as an option. You can avoid following anything, and looking into lemmy’s default from page, just use it to post and get feedback, forgetting about the social networks characteristics of lemmy, and make it work as your blog provider…

Neither servo rendering engine (like gecko), nor verso (an actual rust based web browser based on servo) are quite ready for prime time. But I’m hoping they will be there sooner rather than later. I don’t use Firefox directly, but rather wrappers based on it, Librewolf for the desktop and Mull in part because I’m lazy (I prefer the ankerfox stuff and other to be done for me), and if I want to avoid chromium based browsers, dominating big time (MS browser edge is as well chromium base, electron is chromium in disguise, and now a days QT web engine underneath is chromium as well) well there’s no option yet.

On the other side, nothing guarantees servo and verso (or whatever other servo based browsers in the future) will care about net free advocacy, neither user freedoms, just be concerned about being better technical solutions, :( But I still have high hopes as you might…

Just being a good technical alternative is not good enough now days, :(

This is sad, not just because it’s a trend on Mozilla, but because it shows how mozilla has embraced the corporative kind of mindset. The advocacy team was fundamental for net free principles.

Mozilla based browsers keep being the only practical alternative to web browser dominance, but it itself has degrading its status of resisting bad practices against users and the web in general. And emerging alternatives are also technical alternatives only, with no intention of net freedom advocacy, GPL sort of principles to protect the user and so on.

Sad days indeed, :/

What they’re saying there is that when trying to auto detect the server configurations, there are unexpected connections to cloudfare IPs, which didn’t usually happen with K9. Who posted the concern associated this to telemetry, but the answers are pointing a different direction. But at this point it just guesses, :(

I guess some more formal traffic inspection needs to happen to understand if truly there’s unexpected traffic, where it is directed to, and hopefully infer somehow its purpose. The guesses about what’s happening suggest it’s just about the auto connection, but again, just guesses.

I explored the configurations, and I didn’t find anything about telemetry, and so neither how to disable it. K9 does not have an about:config advanced configuration like desktop Thunderbird does, so if there’s truly telemetry or some other sort of information leakage, then after proving it, perhaps developers realize they can do better. But so far nothing really proving telemetry or information leakage.

What telemetry is enabled? Is there a way to disable it?

F-Droid produces its own builds, with its own signatures, so to get f-droid going, you’ll need to install from F-Droid. However the import mechanism seems really nice. Perhaps you can install from F-Droid the official release, which can co-exist with your upstream installed beta release, import from it from the F-Droid app, then remove the upstream installed beta release, and if you wan to keep on beta, then install the beta release from F-DRoid (be careful right now, given a bug made K9 show up as beta release as well, but the app ID is clear, just being careful is enough), and then import from the official release, then remove the official release and you’re all set. The idea is not to reconfigure a thing by doing those steps, and perhaps you wouldn’t like to go to beta, and remain on the official release, which is not that behind, and perhaps better tested.

Did that, thunderbird release no beta, and no issues since I don’t have google account. For people with google account requiring to re-sign in, and who don’t often do so, signing in is really hard if they don’t registered their phone number to google. It’s sad, I commented about it in some other post. Understandable in reality they are different apps, but in the end it should be the same user ID, but nevertheless it’s a PITA if people don’t have a device permanently logged in, :( For them it’s better to stay on K9,and hope K9 doesn’t go away, or else find out how the heck to login to google once again.

correct, that’s the official release, the other is beta for testers…

Sadly, when having a gmail account, the migration is not possible, if the user doesn’t keep permanently logged in somewhere. TB is not taking the current K9 OATH, and tries to establish it’s own authentication, which on a K9 + desktop TB user not logging often to google at all, it’s really almost impossible to login to gmail, since it ask as security the user 1st phone number, which could have never been registered to google, and beyond that it requests to use a different device which is already logged in, but it you go to the desktop, and attempt to login, it does exactly the same thing, the same stupid question or requesting for another device. So it gets into a loop of devices which can’t be resolved. And for this other user I tried to setup TB for, they don’t authenticate near often to google, but they use both desktop TB and K9 quite well.

For now, for such users, until they figure out how the hell to login to their google account again, they better don’t try migrating to Thunderbird, since the import functionality is not quite enough to get google mail working fine, again if the user doesn’t login to google often. A bit sad, though it makes sort of sense, since the apps registered to google would be different. Sad in the sense that an already working setup for gmail on K9 can not just be imported as is to TB, and keep just working.

While K9 remains working, there’s no issue for such users though. Hopefully that doesn’t happen,

It works great when not having a google/gmail account, :)

Ohh, it needs to import though. I was afraid in case there would be sort of two different directories over the same data, or that on TB dir it would be to start fetching stuff. But it seems it literally copies over the directory contents, which is fine, since the then the other app could easily been removed.

And it works with TB non beta, I guess it works with beta for testers a well (though I like the release, and see how it goes). I’ll be using non beta for now, a bit behind, I prefer to use releases rather than beta releases, and on f-droid I enabled unstable upgrades…

Anyone played with push vs. pull on TB? On K9, I ended up having both. With the last years changes, it removed the push option selecting from the fetching configs, but the push could be selected/deselected from each folder, and I keep them both. Pulling makes the requirement of not having restrictions on battery usage though.

Not sure if that’s getting any better with TB (non beta or beta), and if push has gotten any better. In the end, imap push/idle pretty much depend on the server, and not so much on the client I’d guess…

Thanks !

Thunderbird beta for testers?

OK, many thanks !

I’ll just do nothing for now then. I hope if at some point a migration is required, it’s sort of automatic, f-droid just starts using the Thunderbird app rather than the K9, without user intervention other than performing the f-droid upgrade, one and that would be it. But we’ll see.

If you ask, knowing it’s the same thing, I would have gone with just one app, replacing the other one, and that would be easier and clearer, :)

Thanks a lot again !

good idea, thanks !

Cool, many thanks ! I’ll just wait a littloe longer then…

Oh, you mean using divestos-fdroid-repo? Well, before it became part of official f-droid I used to do that. I’m not sure how long it’ll take to fix the official f-droid.org builds though, since I’d like to go back to it. The sad thing is that to move from one repo to another one loses all configurations/settings, :( But perhaps it’s truly unsafe to wait until the build on f-droid.org gets fixed, if it ever does it.

Anyone aware if there are efforts to get it back building for f-droid.org? Does it depend on the Fennec issue getting resolved?