• 3 Posts
  • 133 Comments
Joined 8 months ago
cake
Cake day: September 25th, 2025

help-circle


  • It uses a database and it’s totally possible to use SQLite as the database and sync that elsewhere. You could then find or make a small client that just accesses that db directly rather than a web service, I suppose. Though there are already several apps out there that store passwords locally and their data files can be synced, if that’s what you want.

    But if you’re doing that then you may not be using this in the most common way or may not understand the risk involved. This is likely to have every one of your logins, not just a single login that may or may not be used on other sites, but the specific username and password and which site it’s associated with. On addition to access to those accounts, this links all of your accounts to a single identity which companies spend billions to do with advertising IDs, cookies, embedded scripts, and lots of other, usually shady, practices. This is a gold mine, though usually only for one or a few users, so generally not a major target unless you’re being targeted personally for some reason. So, even if they don’t get the passwords, they’ve now linked every account you have on every site to your identity.

    If you are allowing the database to be relatively easily obtained by syncing it to a central location accessible over the internet, a bad actor who gets it can even take their time brute forcing any encryption that may be present in the database, but if you don’t keep encryption keys only on your local device because you want to be able to use it elsewhere, then you probably stored the keys along with the db and they dont even have to bother with that, or if it uses password based encryption, they just have to guess or brute-force a single password.

    If it’s behind a properly secured web service, then even if they find an exploit in the server software, they likely have to do many queries over time to get much data and the server can mitigate that risk and/or alert the owner about new logins and such. A database in the hands of the bad actor can’t complain about too many attempts to access it or notify anyone that it’s been copied.

    So, IMHO, it’s a bad idea to use synced local password managers unless you have a very robustly secure way of storing the database and the encryption keys.



  • Vaultwarden will survive. Since the client is open source, once they close the API and break compatibility of the clients with Vaultwarden, the old version of the app can simply be forked and rebranded. I also do hope that the KeyGuard app will continue to support vaultwarden as well since if bitwarden closes the API and makes a breaking change, as is likely to happen, it will break KeyGuard as well, but it will still work with VaultWarden for some time.

    The real issue is that many people who are using Bitwarden aren’t savvy enough to host Vaultwarden in a secure way. Many people are careless with things like secret keys and such and dont know how to properly secure a web facing app or a VPN into their local network. But anyone who self hosts should result learn those things anyway. This one just happens to be a particularly high risk since it contains all of your passwords for everything else.



  • Guessing this is for getting a new phone number? They had stopped giving them outside of Fi for a while. Are they allowing new accounts again? I wonder if with Alphabet’s continuing expansion of cooperation with law enforcement and governments, this is something that those agencies requested in order to link your call data and recordings to your identity when they tap your calls. Google Voice has never been private.




  • Right, but my point is, most US ISP are shitty and don’t offer IPv6 blocks. If you are in the lucky minority who’s ISP does provide proper support for IPv6, then why bother dealing with IPv4 at all, ignore it. Almost nothing needs it anymore besides the majority of ISPs in the US which all suck.

    There are some cases where locally defined addresses (private IPv4 or IPv6 ULAs) and NAT are useful for controlling what people and devices on your LAN can access, but usually not in a residential or home lab situation. So why bother. Either if your ISP offers proper IPv6, just use that, or if they don’t, just use IPv4 and ignore the transitional IPv6 addresses. With both you end up writing every NAT and firewall rule twice, I don’t see the point unless you have an old device that can’t handle IPv6.

    As for performance hits, I was referring to the fact that most ISPs dont offer proper blocks of IPv6 and the transitional technologies they do offer like 6rd or 6to4 do have performance hits, sometimes extremely significant ones. So if you implement dual stack and your DNS query returns AAAA record and your systems prefer it, they will always take a hit. This is from lots of experience. I always disable IPv6 because my ISP uses 6rd and it is the only one in the major city I live in that offers >10Mbps upstream, so it’s not feasible to switch. When I was on Comcast and got an IPv6 block, I disabled IPv4. Dual stack would be too much work.


  • What do you use for repeatable recovery and deployment of systems?

    I’ve looked at ArgoCD and FlexCD. ArgoCD was too flaky. When I made changes to helm files it would often fail to deploy them and the UI often wouldn’t really show the detailed errors from things like helm syntax errors, so it was a pain to troubleshoot.

    FlexCD was just really a pain to configure in the first-place and I didn’t want to learn kustomize when I already have helm charts.

    And neither really supported staged deployments or dealt with dependant services well. So I couldn’t get it to deploy the infrastructure level helm charts like PostgreSQL before deploying the services that depend on it. Technically, with Kubernetes it shouldn’t matter about the order of deployment but in reality when ArgoCD would deploy the other stuff first and wait for it to come up and it never came up because the dependencies weren’t there, it caused it to choke a lot.

    Just an example of the issues I’ve had. But I really want an easy way to make lots of small changes to charts and deploy them quickly as well as being able to quickly recover the cluster from backups if something catastrophic happens like a fire without having to manually deploy each chart. Just curious how others handle it or if it’s always manual deployment of charts via CLI only.


  • But why bother if you get ULAs. It doesn’t enhance anything and adds complexity if you use NAT or other routing as you need to add rules for both IPv4 and IPv6. Most ISPs, in the US anyway, don’t offer true IPv6 only what was supposed to be transitional technology decades ago like 6rd. I hate to say anything good about Comcast, but it’s the single thing I miss from that they actually do. But having such limited upstream speeds on cable just isn’t reasonable for much of anything these days, but definitely not when self-hosting. 1-10Mbps up on Cable or most DSL just doesn’t cut it.

    If you’re starting from scratch implementing IPv6 on your LAN might be worthwhile if you dont mind the limitations of or don’t require the transitional technologies on your LAN like NAT64 and the hit to performance from the translations/tunneling when accessing the internet doesn’t bother you (it sure annoyed the hell out of me every time I accessed a website, among other things).

    But dual stack, seems like it’s not worthwhile. Just choose one or the other. Few software applications or modern hardware are going to have an issue with IPv6. But if you’re using both ULAs and IPv4 private addresses, it seems like a lot of extra hassle to write duplicate routing rules for everything.


  • I can’t get IPv6 in any worthwhile form from my ISP. IMHO IPv6 isn’t any more useful than IPv4 if you only have ULA. And NAT is not as well supported since it wasn’t intended to even be really necessary for example. So even if you are starting from scratch or just using it internally, there are some disadvantages to implementing it over just sticking with IPv6. But if your ISP actually provides IPv6 it might be worth it as long as your devices all support it. But otherwise you’re going to need to set up IPv4 in addition, anyway, so you’re just going to create problems for no good reason, IMHO.



  • Plex prices are expensive just to access your own media. Tailscale can do it for free.

    Tailscale isn’t exactly free. It requires a lot more knowledge, configuration, maintenance, etc, than Plex alone.

    Sure, many self-hosters have the ability to figure it out and the proper networking and/or server hardware to implement it. But many Plex users aren’t really self-hosters in that sense. Hosting a local media server that deals with all of the networking stuff for you is much easier than maintaining a tailscale or similar setup on top of the media server stuff. I mean for me, if I hadn’t gotten a lifetime Plex Pass early on for cheap, I probably would have put more effort into my Jellyfin setup. But Plex mostly just works and I have other bigger priorities. I hate the functionality they’ve removed that makes things more difficult than it should be, or I wouldn’t be switching, but it’s not all that bad. So if I didn’t have the expertise and hardware already, I could see it being worth the money to stick with it.


  • Damn I hate the chatbots though.

    Just yesterday I was on a site to get some routine lab test results. There is no link for results on the hamburger menu or the top of the home page. There are a few links for things further down, one of which is “Test Results”. But those all open the chat bot and ask it instead of just going to the page. However, it just offers some FAQs that I could find just as easily on the FAQ page. But it doesn’t even link to any pages no matter what options you select whole chatting. I finally gave up and clicked the “Dashboard” link in the hamburger menu which I had originally assumed meant the homepage hoping I just missed something.

    Turns out the “dashboard” is a separate page, and I still don’t know if that’s where results go because it just asked me to verify my identity and despite completing the identity verification successfully (twice) it still keeps saying I’m not verified.

    So yeah, I completed my visit to the site while having accessed the chat bot for help and not interacting with a human, so it “solved” the issue in the sense that I no longer had any desire to get any additional information from them and just waited for my doctor to send the results. I was also never presented with an option to contact a human, nor would I consider it worth waiting on hold to call a call center to find the core info that the site should he helping people get.

    So, poor web design and broken services both made me use the chatbot unwillingly and made me leave the site without human interaction, so I bet they’d consider it a win for them.




  • This is using energy already in a brand new battery under ideal conditions, and no inefficiencies of commercial fast chargers if you commute as much as the average in the US, and no average over the life of the battery, no average of climate effects on efficiency, or any of the other real world implications of EVs fully replacing combustion engines.

    Plus it’s comparing the energy used to produce and transport the oil to gas process to the energy used to make an ideal EV car move. What about comparing the energy used to produce, transmit, and store the energy for the car. And it’s not taking into account degradation of efficiency over the life of the vehicle which, if both are well maintained, reduces much less in a combustion engine vs a battery. Plus many small cars can go more than 25 miles on a gallon of gas if that’s what we’re comparing. I know mine can.

    I believe with some relatively small investments in implementing various current technology into EVs and the battery and charging infrastructure (like tech used for preserving the life of cell phone batteries for example), we could get to the point where the average could get to the point where EVs could replace nearly every type of vehicle under nearly every condition combustion engines are used in and be more efficient. That’s not at all what this article is even close to talking about, but it isn’t out of reach, just too many power struggles right now.


  • If I was going by oil company propaganda, I’d say EV tech wouldn’t get there for a generation, but I’d say it could take only a few years (assuming reasonable levels of funding).

    And, as an engineer, I say “significant” as in the literal meaning of the word not as an emphasizing word sometimes used to mean “a lot”. I mean an amount that is enough to be mathematically worth including in a calculation.

    As for the alternator comment, I said probably because I dont have data to say 100% for sure, but logically based on the tech it makes sense. Probably means likely.

    I think you’re looking at an edge case, which is generally the current market of the majority of EVs, and then comparing it to real averages of efficiency across all types of another technology’s use cases. That’s not fair. So it may be more efficient for some and in specific cases, but what does that matter in the long run except that it’s exactly why the market stopped growing when it sold to the majority of people in those situations. Obviously, that was not the vast majority.

    As I mentioned you need to consider the average driver and what they use cars for. If you have a high efficiency slow charger and don’t travel and have below average commutes, then yeah, you (as a market) may have mitigated some of the efficiency issues with fast chargers, recharging cycles, etc.

    And if you live in a mild climate and only experience extreme cold periodically and/or always charge in a relatively warm garage, that might be somewhat mitigated for you. The heaters for the batteries and drive trains drain quite a bit of energy while in use and charging a cold battery in a parking lot is less efficient. It takes more energy to charge them to the same level and the battery will hold less energy. But as I mentioned the energy inefficiencies of things like air conditioners might swing the balance if you live in primarily hot conditions.

    And if your batteries are relatively new, the inefficiencies there might be mitigated for some time. Used EVs tend to have significantly diminished efficiency, capacity, and lose energy while idle at a faster and literally significant rate. Combustion cars constantly sitting in the hot sun in extreme climates similarly will lose more fuel to evaporation (otherwise the tank would be over-pressurized and be unsafe). In those cases, an EV may have a leg up.

    But I’m talking average car usage and vehicle condition excluding poorly maintained vehicles as those outliers would skew things too much. The efficiency numbers that are generally used for combustion engines cover all of this as well as things like use of the alternator to power a fuel pump and other parts that are essential to operation, but not things like air conditioning use, so that’s why I made that distinction previously.

    Of course I’ve only analyzed data from the US, and I’m using averages. So in a country where average commutes allow for going both directions on a single charge and thus using more efficient home chargers only may shift the balance as an example.

    Fast chargers of any kind of rechargeable battery both waste more energy (which is why the EV chargers need the huge heat syncs in parking lots but not at home) and with repeated use reduce the life and thus the efficiency of the battery much more quickly. Same happens with cell phone batteries which is why modern phones trickle-charge at night when it’s likely you don’t need a full charge right away and only fast charge when needed. Many of the commercial chargers don’t even have this basic technology to allow the user to slow charge if they want (again one more reason just a few years could easily sway the balance with existing tech implemented for cars).

    I could continue, but if you are not willing to consider the average use case of a vehicle and not the average use case of the EVs currently in use, it’s not really going to matter except to disappoint people who use their vehicle in an average way (average for the US anyway).