• 0 Posts
  • 26 Comments
Joined 25 days ago
cake
Cake day: January 13th, 2025

help-circle
  • I said from the beginning it’s a deal breaker for me. You’re the one trying to convince me it’s not the issue I think it is.

    And I’m not talking about the license to modify the firmware software itself. I’m talking about the EULA of the device itself. Pretty much any device you own that has any kind of software on it is not owned by you outright to modify as you wish. This website doesn’t show the agreement, but if it has a paid feature to unlock, it has to have one somewhere.


  • But were talking about firmware here. My computer also has firmware and an OS. I never have to touch that. Home Assistant is an application that I run on a computer. And I don’t have to modify the code in Home Assistant to get it to connect to another device. I just configure it.

    I also install Linux on my laptop. Is that self hosting, too? We’re not talking about a server or a “host” other than the hardware device itself that lives in the house. If I want the server functionality, sure that’s self hosting the server software. Firmware and operating systems are generally not referred to as self-hosting since all devices need those things. Self-hosting refers generally to cloud-based applications, not standalone hardware firmware/OS.

    This is a hardware device that is hard coded to connect only to a specific server that you have to pay to access if you want any API functionality. If I want to use my own I have to learn the programming language, figure out how to modify the Firmware, and then maintain a fork of that firmware indefinitely including making sure that there are no automatic updates since that would overwrite the modifications.


  • But i have no desire to compile and maintain a fork of software just to set a URL and auth token. And again, this is a license to modify the firmware, so they could at some point decide to revoke the license to modify the firmware or stop publishing security updates on their git repo to allow for merging into the fork I have to maintain. Probably won’t if they are reputable and don’t get acquired, but still a risk. It’s just not worth it for me for any open product I purchase.



  • OK, I see. They decoded not to have the device respond to requests. It’s not that the device has endpoints, it’s that it’s hard coded to connect to a specific endpoint and you have to build your own firmware in order to get it to connect to your own server.

    That’s still a deal-breaker for me. It’s just that the connection is flipped. I don’t want to have to build and maintain firmware to use the device in addition to maintaining the server. Why can’t this be a setting on what server it connects to?


  • I think you’re not seeing my point. This is in the hardware. It’s simple to have a setting that defaults to connecting to the company’s server and then have that setting allow for changing the sever target. Why do I need to build firmware to do that?

    And, no, it’s not acceptable to require forking, regardless of the ease of merging. It still means you won’t get critical security updates without manual intervention.

    And finally, it’s requiring trust. If the company decides to change the license, you are out of luck. And again, the documentation and policies are already lacking, like what happens if your API key is compromised? Do you need to pay for a new one to be generated. These are on your local device.

    And no, home assistant doesn’t require self-hosting. It requires hardware to put the central system on, but doesn’t require an external server for web services. This device is putting the lock inside the hardware you are purchasing. If I purchase hardware, I want it to be mine. Not subject to a license of what you can put on it, even if that license is initially very open. It’s my hardware.

    Home assistant does sell hardware that is totally open with no license on what software you can put on it. Most people put it on their own hardware. This is totally separate from the cloud service they offer which is for interacting with the sever over the internet and some other stuff. That cloud functionality is totally optional and you aren’t required to modify the home assistant code base in order to NOT use the cloud. So it’s not at all equivalent.


  • No, with home assistant they have a cloud server that has additional functionality that you can use or not. Home Assistant doesn’t restrict access to the software on device it’s running on.

    With this, the device itself will not allow you to access its API endpoints without having a key that you need to purchase. And though they say it’s a one time purchase, who’s to stop them from releasing a critical security patch that invalidates the keys, even accidentally, or includes making the keys a monthly subscription going forward. Or what happens if that key gets exposed and you need them to generate a new one? Do you need to pay for that or is the device permanently compromised unless you build your own custom firmware?

    You’re allowed to modify the firmware to use a self hosted server for that functionality without violating the license, which is better than nothing, but then it’s up to you to maintain your fork of the firmware. Why not just only require the key if you’re connecting to their server and allow you to select your own server without needing to modify and maintain a fork of the firmware?


  • Problem for me is that there is some kind of restriction on accessing the device’s API at all and you pay extra for the key that will get created when you unlock it. This may mean that some kind of lock is in place on the device that has to have a key for it created. Even if they give you a key, what happens if an update removes that key’s validity, even unintentionally. I’ve had this happen with products in the past. A bug will restrict access to things or worst case, will totally brick the device because the lock is stuck in place.

    Not saying this device has that problem, but the concept of a lock existing means it could intentionally for profit, maliciously by hacking, or unintentionally end up locked later, so I’m just against the concept in the first place. It’s a potential point of failure for no good reason but profit on a device that is supposed to be open. I’d happily accept if they changed a little extra for a device that had no lock at all. Just I don’t want a device with a lock on it.

    Also, I’m not sure how having my own server helps here, in fact that’s my plan in the first place as I want to get the thing to interface with my own internal systems. Maybe I’m misunderstanding the implementation, but my understanding from the very brief information available is that you get on your device, connect to their server to pay a fee, and then a key is created for you and then you can access the endpoints running on the device either through the server or directly with REST calls. The alternative is to teardown the device and build your own custom firmware that uses different authentication mechanisms. I don’t really have the interest to mod the firmware and then have to maintain a fork for getting official updates. I just want to be able to be able to interface any servers I have with the device as I choose.



  • No. I don’t use DoH inside my network because I redirect DNS traffic on my primary VLAN to a pihole for ad and malware reducing. But I also control what has access to that VLAN pretty strictly. I have another VLAN for guests and untrusted devices that doesn’t use the redirecting, but does use the Unbound server as the default DNS, just doesn’t enforce it. And I have an even more locked down VLAN for self-hosted servers that also doesn’t use the pihole, but does use Unbound.



  • I use a local unbound DNS server on my router with Quad9 as upstream. I actually have google DNS entirely blocked/rerouted on my router because google uses it for advertising tracking, but I get creepers out by targeted ads showing up in random places when I do do something on a totally unrelated site. Most important thing, though, is to use DNSSEC DNS over TLS or DNS over HTTPS to reduce middlemen from using your DNS info to track what sites you visit and sell that data. Of course ISPs still see the destination of all of your data for tracking what sites you visit unless you use a VPN or similar tools, so you can’t hide it from them that way.

    Edit: DNS over TLS not DNSSEC, totally different thing…


  • Matrix isn’t more secure/private than Signal. Both have advantages and disadvantages. Signal has a centralized server, but has no access to the keys to decrypt any of the data flowing through them. Matrix chat rooms live on servers that would theoretically be able to access the data in the rooms, so you need to trust the server owners. Advantage is that multiple servers are involved so no one sever can kill your chat room. With Signal, the disadvantage is if you join a chat room, you can’t see any past messages because those are encrypted with keys you don’t have access to. Similarly if you move to a new device, that device won’t have any of your past conversations because the new device doesn’t have the keys for those messages. (though migration is now somewhat possible but done poorly IMHO).

    So, they address different concerns. Is your concern keeping your conversations private, or keeping your conversations from being censored? Signal is more secure and private, but more centralized and easier or to fail. Matrix can be secure if you host your own server or explicitly trust the owners of all servers that house your chatrooms to keep them secure and to not sell their servers in the future. Matrix is more distributed, so more difficult to be censored or have your data lost by a single point of failure.

    Is it “secure enough” depends on what your concerns are. If you host your own, then it’s as secure as you are technically able to keep them secure yourself. Otherwise it depends on the server owner.



  • Most advertising links are routed through click tracing sites so that they can add some tracking information about what advertising campaign brought the user there and what that user does while on the site among other tracking data. In the rare cases i want to see something from an email, I never click on links, I always copy the URL being displayed and paste it. You can get email clients that have settings to warn you about this or that will automatically use the displayed link and ignore the anchor link.


  • For what it’s worth, I actually had a lot easier time with NVIDIA graphics on Ubuntu and Fedora than Mint. And Kubuntu with the Plasma desktop was the easiest to get my partner converted from Windows without much tweaking.

    You could try the booting the live CD and see if you’re able to get the graphics working more easily. And I’ve never seen that second issue on either Ubuntu or Fedora, so not sure what’s up there.

    I’m not too happy with the direction Canonical is taking Ubuntu right now, but it typically has the most documentation for when issues come up and has a very healthy development cycle, so I still recommend it to most people as a starting place. To me, Mint has always been a little too opinionated and catering to the less technical and thus harder to tweak. Ubuntu kind of does it in a way that makes it easier to override the default easy-mode kind of stuff. Just a general observation from decades of Linux use, and may or may not be as true for the current versions.

    I use Fedora with Plasma desktop on my other desktop/laptop devices because I prefer RHEL to Debian based stuff, probably just got used to it using CentOS and now Rocky for all my servers over the years.




  • Also Canonical has added a lot of problems to promote their monetization strategies lately. Mostly aimed at business rather than regular users, but still causes problems for home users.

    I generally prefer RHEL based distros over Debian based ones, so Rocky Linux for servers is my current go to and Fedora for desktop, though Fedora is heading in a similar direction as Ubuntu I feel…