• 1 Post
  • 12 Comments
Joined 6 个月前
cake
Cake day: 2025年9月25日

help-circle

  • Problem is requiring a browser if it’s not primarily a web interface. Even if initial setup is web-based, a lot of times background processes exist that don’t traverse the internet, especially in higher security situations, so exposing those components to the internet just to get external credentials is not worth it, so then an additional proxying component is required. Anyway, the idea is that it can add a significant amount of complexity if it’s something more complex than a simple, single component web application.


  • This too would likely require compromising at least one of the devices or at the very least compromising both users’ ISPs or some other fairly detailed and highly targeted attack, but none of that would require compromising Signal’s servers and would make any system’s key exchanges vulnerable, even self hosted systems.

    Simply compromising Signal’s servers might allow disrupting key exchanges from succeeding and thus making it impossible for those users to communicate at all, but not MITM really, at least if we assume there aren’t defects in the client apps.

    The key exchange is much more complex than something like TLS and designed specifically so that the server can’t interfere. With true e2ee the key never passes through the server. This isn’t like many other apps that say e2ee, but really mean end to server gets one key and server to end gets another and decryption and re-encryption happens at the server to allow users to access older messages on new devices and stuff like that. Signal just connects the users to each other. The apps do the rest.

    They could probably do something if they totally took over the entire Signal network infrastructure, but it’s definitely not something they could do undetected. But if a government took over the entire infrastructure, security conscious people would stop using it immediately thus not really worth the monetary and political cost. Otherwise China and others would have already done that to all secure communications. And again, not Signal specific.



  • It’s unlikely encryption would be compromised since the keys never leave the device. The user’s device would have to be compromised for that. Decrypting messages on Signal servers without the keys takes too many resources to be feasible en masse, even for a state actor. And the current app has no method to transfer those private/decryption keys.

    But Signal is not private. It is only secure. Two totally different things. A bad actor could uniquely identify a user and what users they have communicated with and how often, just not the content of the messages. That metadata is stored on the Signal servers and the company has access. That is the tradeoff for ease of use and keeping malicious accounts to a minimum vs an anonymous IM app.


  • Yeah, it could easily have added a couple of lines of code that sends everything to Northern Korean hackers because it found that in a bunch of repositories or just logging passwords to public logs or other things an experienced developer would never do. “AI” only replicates what it sees most often and as more spam and junk repos are added to its training data because “AI” companies are too concerned with profit to teach it properly, it could do tons of random stuff. It’s like training a developer by giving them random examples from the internet rather than specific ones. Of course they pick up bad habits. Even if it “works” it is almost never efficient or secure.


  • Keycloak has some learning curve, but it’s the best OpenID Connect client and the most configurable and feature rich open source SSO system with the fewest major issues that I’ve used. And I use traefik for a reverse proxy, so for things that don’t support SSO directly thomseddon/traefik-forward-auth works flawlessly with Keycloak to provide an auth layer to those apps.



  • You have to run an LLM of your own and link it, if you want quality even close to approaching Google, but the Home Assistant with the Nabu Casa “Home Assistant Voice Preview Edition” speakers are working well enough for me. I don’t use it for much beyond controlling my home automation components, though. But it’s still very early tech anf it doesn’t understand all that much unless you add a lot of your own configurations. I eventually plan to add an LLM, but even just running on the home assistant yellow hardware with a raspberry pi compute module 5 works ok for the basics though there is a slight delay.

    I haven’t tried, but Nabu Casa also offers a subscription service for the voice processing if you want something more robust and can’t host your own LLM, but thst means sending your data out, even if they have good privacy policies, which I’m not interested in, because while I somewhat trust Nabu Casa’s current business model and policies, being hosted in the US means it’s susceptible to the current regime’s police-state policies. I’m waiting for hardware costs to recover from the AI bubble to self host an LLM, personally.


  • Yeah, the issue is that it drove up the price to justify price-gouging even though it’s likely these won’t actually get purchased. They shouldn’t reserve nearly all of their product for pending transactions. They should fulfill actual demand before theoretical ones. This is clearly only possible because of the industry consolidation into essentially a monopoly. If they still had real competitors, they’d have to actually sell for a fair price and they’d be concerned that they likely won’t get paid for these “reservations”.