• 0 Posts
  • 473 Comments
Joined 3 years ago
cake
Cake day: June 20th, 2023

help-circle
  • Matrix, the central service, might work, but I’m not sure if it could handle the load well. Matrix, the federated service, hosted by many people, have performance issues with the “free” version. I could not test the paid/more optimized version, so I can’t talk about that.

    Anyway, the protocol and clients have their issues. All these stems from usage; I did not do a deep dive in the internal of it. But on the top of my head:

    • joining a room will sometimes not send you keys to see older messages, despite being configured to do so. When it works, it’s ok. When it doesn’t, there’s little to no recourse.
    • sometimes (rarely) rooms have to be upgraded to use new versions/features. So far it happened once (to my knowledge). The issue is that “upgrade” means locking the existing room, creating a new one, inviting everyone in the new room, and putting a link to the old room as read only. Sure, the process is mostly automated… except the best way to start it is using dev commands on a client, and every user will have to accept the invite. Just hope you don’t have too much rooms.
    • Logging into a new device/client sometimes will works perfectly fine. Other times it will obstinately refuse to retrieve your room’s keys from another existing, online, logged-in device. Despite the “confirmation” dialog, it won’t work. You can manually export/import your keys from one device to another, but for large scale adoption? Not good. You can say goodbye to all previous messages if that happens.
    • Interface is relatively barebone, and some features gets pushed quickly (like, throwing confettis), while other (like, proper room management, fine notification controls, etc.) are held back forever.
    • Features are limited. It works very well as a chat, and they recently worked on a built-in video/audio call service, but that’s it. A few “plugins” are supposed to work but are clunky as hell (they’re basically iframes). Some features that people consider important (like stickers) are definitively an afterthought, and searching for a sticker is a pain (dicslaimer: I’m not using the central service/app, so that part might be specific to my instance)

    With that said, nothing’s actually a show stopper for small usage, and the heavily optimized server might handle itself well enough, as long as you’re mainly concerned with having text rooms. But open instances handling hundreds of users might be a stretch… for now. Maybe this will cause more development into the Matrix/Element ecosystem.





  • Unless there’s an incredible amount of people “not in” on some universal secret, maths gonna maths, and physics gonna physics. Actual encryption works well in a proven way, computational power isn’t as infinite as some people think, and decent software implementations exists.

    Getting hold of anything properly encrypted with no access to the key still requires an incredible amount of computing power to brute force. Weak/bad implementations can leave enough info back to speed this up, malicious software can make use of an extra, undocumented encryption key, etc. but a decent implementation would not be easy to break in.

    Now, this does not say anything about what Apple actually do. They claim to have proper encryption, but with anything closed source, you only have your belief to back you up. But it’s not an extraordinary claim to say that this can be done competently. And Apple would have a good incentive in doing so: good PR, and no real downside for them since people happily unlock their phone to keep their software running and doing whatever it wants locally.


  • I don’t know how most package managers on windows work, but usually, auto updates are disabled by default for software that comes from one. For example, Firefox installed using APT on various linux distro will not auto-update out of it.

    I vaguely remember chocolatey packages not really doing that, causing mismatch between installed versions and its internal database, though, so maybe it wasn’t that good of a solution.


  • The software itself, and the devs, have little to nothing to do with this besides detecting the issue. Which was not obvious, since (it seems) the attack was targeted at specific IPs/hosts/places. It likely worked transparently without alteration for most users, probably including the devs themselves.

    It also would only affects updates through the built-in updater; if you disabled that, and/or installed through some package managers, you would not have been affected.

    A disturbing situation indeed. I assume some update regarding having adequately digitally signed updates were done (at least, I hope… I don’t really use N++ anymore). But the reality is, some central infrastructure are vulnerable to people with a lot of resources, and actually plugging those holes requires a bit of involvement from the users, depending how far one would go. Even if everything’s signed, you have to either know the signatory’s public key beforehand or get a certificate that you trust. And that trust is derived from an authority you trust (either automatically through common CA lists, or because you manually added it to your system). And these authorities themselves can become a weak point when a state actor butts in, meaning the only good solution is double checking those certificates with the actual source, and actually blocking everything when they change, which is somewhat tedious… and so on and so on.

    Of course, some people do that; when security matters a LOT. But for most people, basic measures should be enough… usually.






  • Steganography is extremely far from undetectable, unfortunately. And trivial to find out once you know its there; if we ever allow a framework to be put in place to intercept communication at a large scale, it will be the inverse of the cat and mouse game we have with encryption : very hard to improve, very easy to detect.

    And I’m aware of the many funky things we did. At some point people tunneled DNS queries through HTTPS, to get through wifi captive portal that only allowed HTTPS traffic until authenticated.

    Just to be clear, I’m aware of the issues of detecting stealth data, and even detecting encryption against seemingly random data. It’s kinda fascinating to detect the difference, too; some people have looked into that. But the point is, if you’ve already agreed on “banning encrypted communication that can’t be listened to easily”, you can basically just say “this is gibberish, decrypt it or get to jail”. I also know that this sounds insane and throw away the “innocent until proven guilty” principle, but we’re slowly creeping toward a world where our device scans all our document and communication to notify of issues to a central authority, where black box in large networks are already present, and so on.

    It’s been slowly creeping toward that. Finding way to hide traffic on public networks can only go so far if the listener can just stop you if it detect what looks like encrypted content.

    And, since this is kind of a heated discussion, I’ll reiterate: it would be batshit crazy to go this way. But I would have found batshit crazy to have our own devices spy on us and report suspicious activities to third parties years ago, and yet here we are.