Well the Sony XZ1 Compact got IP68 even with aux input and a microSDXC slot so I don't think combining the SD Card with water resistance should be a problem. The swappable battery would probably be worse.
Regarding bloatware I've gotten used to using adb and the uad to remove it when buying a phone. https://github.com/0x192/universal-android-debloater/tree/main

Keepass2Android doesn't have it yet, but seems to be working on it
https://github.com/PhilippC/keepass2android/issues/2099

Strongbox seem to have their implementation done for iPhone
https://strongboxsafe.com/updates/passkeys/

I was thinking about trying another ROM on my old XZ1C but my banking apps wouldn't run properly if I did that anyways.

I can only imagine that your conviction is wrong. If we were large enough a market to make a nice profit then I imagine the smaller phones would still be around.
With all the video that's being consumed through phones today I kinda understand why most people prefer a larger screen too. I have friends who has neither tablets nor computers at home and if I didn't have both of those I might even prefer a 6 inch screen myself.

Yeah, I'm using the Sony Xperia 10 IV right now and while it is better than many phones I'm reminded of how much better the XZ1 Compact feels in my hand everytime I use it to startup some music.
129mm vs 153mm in height and 65mm vs 67mm in width - it's amazing how much a difference those 2.4cm in height does for me.

That's a cool project and it did have a small screen, I give you that. Might be nice to only have to worry about answering the phone for 5 hours a day too. ;-)

Vaultwarden is a nice self hosted bitwarden alternative
https://github.com/dani-garcia/vaultwarden

Some prefer using KeepassXC and sync the database between devices
https://www.ctrl.blog/entry/keepass-vs-bitwarden-server.html

Ah, that sucks and complicates things. One can only hope that doesn't stop the US phones from getting them then.

If they've already spent the developer time to create a security update for the EU market then I imagine they will push it to phones in the US too.

If your phone can survive until next summer it might be a good idea, EU is forcing some consumer friendly requirements which I imagine will give you a wider availability of models with five years of updates.
https://energy-efficient-products.ec.europa.eu/product-list/smartphones-and-tablets_en

Ecodesign requirements will apply to mobile phones and tablets put on the EU market from 20 June 2025 onwards, including:

1. resistance to accidental drops or scratches and protection from dust and water
2. sufficiently durable batteries which can withstand at least 800 charge and discharge cycles while retaining at least 80% of their initial capacity
3. rules on disassembly and repair, including obligations for producers to make critical spare parts available within 5-10 working days, and for 7 years after the end of sales of the product model on the EU market
4. availability of operating system upgrades for longer periods (at least 5 years from the date of the end of placement on the market of the last unit of a product model)
5. non-discriminatory access for professional repairers to any software or firmware needed for the replacement

Not in this case, the tests they're running doesn't need the vendor blobs in those testing folders.

Generally I agree with Debians changes to include nonfree firmware in the default images and making the "completely free" images the non-default version. I do think maintaining and having completely free distro versions to be a good thing though.

The whole situation is really unnecessary because none of the things that we're testing really requires those vendor blobs.
We're just testing the basic vboot and CBFS structures in those images, the file contents are not really relevant as long as they match the signatures.
So I think the easiest option here is to just remove the offending CBFS files from those images / overwrite the offending FMAP sections with zeroes.

https://issuetracker.google.com/issues/374385985

In this case the binaries with the nonfree software seem be completely unnecessary, so why not keep it free?

https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/6JI7KTJ3QVK6Q5BLNWREX2IBVZP7GCLP/

They were put there for some testing and from their mailing list it sounds like it will be removed as it's unnecessary.

Apologies that this has caused problems for you.
This is just some old test data used to confirm that the parser in the command line utility works, and I don't think anyone thought about the redistribution legality implications of putting those images into the repo.
I agree that it's not a good situation and we should try to fix it.

There is no real reason for these binaries to be in those test fixtures — the point of the tests is just to verify parsing for vboot data structures, the actual contents of the file are not really relevant.

• Julius Werner, member of the Advisory Group

https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/6JI7KTJ3QVK6Q5BLNWREX2IBVZP7GCLP/

edit: "there is a general advisory committee made up of any individuals who wish to help out and discuss their thoughts with the leadership board. This is done at bi-weekly meetings, which all members of the project are invited to attend and contribute."
https://coreboot.org/leadership.html