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

help-circle

  • That’s… not applicable here. Like, at all. To reproduce a printed document, you input it. To make a 3D print, you produce tailored list of operations depending on many, many settings. Usually, the file that reach the printer have little in the way of knowing what is printed, aside from expensive reconstruction that would only give the general shape, if even that. And even if you can send actual 3D model files to a printer that would do the slicing locally, there’s no “absolutely required” fingerprint there. A tube is a tube.

    And, just so you know, there’s a slew of public printers and scanners that will just plain not recognize any of this, too. There’s also some “protection” pattern in some official document; large office printers would choke on them, where a home scanner was fine. This is, at best, only enforceable in the flimsiest of ways.


  • Let’s entertain the thought. How would one identify what is a gun part being printed, and what is a tube, a mechanical latch, or whatever else. Heck, I printed a plastic replica of a movie prop once. Would that be illegal?

    I mean, I’m not in the US, and I know how to drive three steppers according to a list of extremely basic instructions that never ever represent anything “final part-y” looking, but the question remains. How do we go from “lots of gcode” to “yep, that’s definitely illegal” without saying that everything is illegal?





  • If the entire supply chain up to the software you’re running to perform actual decryption is compromised, then the decrypted data is vulnerable. I mean, yeah? That’s why we use open-source clients and check builds/use builds from separate source, so that the compromission of one actor does not compromise the whole chain. Server (if any) is managed by one entity and only manage access control + encrypted data, client from separate trusted source manage decryption, and the general safety of your whole system remain your responsibility.

    Security requires a modicum of awareness and implication from the users, always. The only news here is that people apparently never consider supply chain attacks up until now?




  • 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.