As as self-hoster, I recommend vault warden. Supports 2fa, written in rust, works pretty well, is easy to backup, and you can use bitwarden's phone client.

I'm curious why other self hosters think it's a bad idea.

> and you can use bitwarden's phone client

What will you use when this stops working in the near future?

You use Keyguard (https://github.com/AChep/keyguard-app).

>The source code is available for personal use only.

Not sure how switching from a "FOSS with some proprietary source-available components" client, that can be forked mostly intact if need arises, to a full proprietary source-available client, that author can make closed source at any point with no forks being possible, is an improvement.

May be worth submitting this to the front page

Why does everyone act like this hypothetical (and however likely) future is something that needs to be acted on now?

I'll just export my vault and move to KeepPass or something else?

Because people don't trust themselves to do proper backups as if this is some kind of black magic or something.

I've been self hosting Vaultwarden for me and my wife for years without issue. People like to tell others what they should and shouldn't do because they want to feel superior to others, I suppose.

It's especially strange since self hosting is, aside from the 'fun' aspect of it, about personal control. So this tsk tsk'ing from others about self hosting a password manager is especially ridiculous.

I moved to the cloud for a simple reason: if I die tomorrow people who depend in the service are screwed. And this is an important service, like email or digital archives.

I'm confused, so you are self hosting it for other people?

Yes I was - for me and my family (and a few friends)

Yeah I have no problems letting family and friends use cloud services. I keep the self hosted stuff for myself.

Presumably, it's a memory hog. What is your RAM usage?

I think the memory hog you're thinking of is the official Bitwarden self-hosted backend. Vaultwarden is pretty light on resources.

For me, vaultwarden's RSS is ~45 MB, with ~13MB of that being shared. I have it running as a secondary thing on a 512 MB machine and don't notice it's there. Is there a reason you presume it's a memory hog?

For me, RSS 35 MB, SHR 23 MB. The vaultwarden executable is 38 MB (typical Rust executable that links Rust code statically, and only dynamically links libssl.so and libc.so dynamically).

So probably its RSS usage is just mostly its own executable code?

I'm surprised, actually. I expected at least an order of magnitude more. In my humble opinion, this is still a lot of memory -- probably an order of magnitude (or even two) more than what is realistically required for the task. But this is just my own philosophy, and I do realize that the days of careful memory utilization are long gone.

Thanks for sharing.

GrapheneOS does everything and more for key attestation, allowing security sensitive applications to test the integrity of the device. Sadly some apps like google wallet not only check for attestation, but check if Google's signed it. Which is against the idea of attestation in the first place.

So google's tap to pay doesn't work, but others do, like garmin pay. Random bank apps are hit and miss.

> GrapheneOS does everything and more for key attestation

Right, that's the problem, in my opinion. I'm not referring to the apps that require Google's keys only, I'm referring to the ones that allow GrapheneOS keys too. If you use one of these apps, you can use vanilla GrapheneOS builds, but you cannot run your own self-signed builds.

You are gaining freedom relative to running Google's OS, but you are still not free to further modify the software running on your own device.

Apps that require "integrity" should monitor their own integrity only, they should not attempt to infer the integrity of their environment.

Trick is there's no integrity without the OS. Cheats can ruin games, keyloggers can record passwords, music/movies can be stolen, bitcoins can be stolen, etc.

Attestation does not solve this.

Heh, I used to use bluetooth GPS tracker with my nokia 770. It worked well since I could place the gps where it got the best signal. I could start a track, have it record it, and then check in with the n770 only when I needed to see a map. That way I made the most of my n770's battery life, but still got continuous tracking.

Beware that they take much longer to start since they don't know the GPS coords of the nearest cell tower, nor do they download the GPS almanac over the cell connection. They will however remember the almanac so you can leave it on for 30 minutes and not have to redownload it the next day.

I have a small Meshtastic device, not quite button-sized but still tiny. The chip on it supports aGPS, so I can upload the almanac and prime it with the approximate location. I'm very familiar with this process, I wrote a small utility for my cell phone back in ~2010 after I screwed up its factory image by installing Cyanogen.

Nice, I have a few mestastic widgets, but do want something small enough for a dog collar. That way my wife and I can carry a radio and keep one in the car so we have a good chance getting in range.

Sad that most of ham radio, which has similar APRS for tracking, doesn't do async or multi-hop.

I found this one when searching for something similar: https://www.amazon.com/dp/B0GF6QL9S9 - it should even be hackable.

I have not tested it, but it should be hackable. I have a couple of discrete RAK chips, and I've ordered a PCB with a trace antenna for them.

Looks nice for some uses, but pretty big for a dog collar, almost 3" on a side. I've some long/thin dev boards that I could pair with an 18650 that should be closer to 1".

I'm planning to use a small LiPo battery with a JST connector. The whole footprint should be slightly larger than 3x4x1 cm. Still a bit too large for a pocket device, but perfect for a collar.

Sounds great, best I found so far is the RAK19007 (30x60mm), then add a GPS (RAK12500). It will be kind of long (60mm + case) but not too wide (30mm + 3d printed case).

Or the Mesh Node T114 Development Board V2 (23mm wide).

How close does another diver have to be for a message to send/received?

Spec says about 30m (it's relayed via tank pod transmitter using sound).

Sounds like an issue with hardware. I watch ECC errors for 2500 servers and see a few some days, and zero others. Said servers at an elevation of 6,000 feet or so. A few per day for a single machine is crazy high. You likely have a dimm, dimm slot, motherboard, or CPU issue that's susceptible to RF noise, vibration, temp changes or similar.

Sort of, often there's workstation chips, like the xeon E3, which is a warmed over desktop chip ... with ECC. Price difference when I bought was $20 CHEAPER for the CPU (at the cost of 100 MHz or so). I did pay $50 more for a motherboard and 10-15% more for ram.

Or just get an AMD Ryzen.