• 1 Post
  • 81 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle
  • Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

    Damn reading literacy has gone downhill these days.

    Please reread my post.

    But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

    1. OSs provide keyring features already
    2. The framework signal uses (electron) has a built in API for this EXACT NEED

    Cmon, you can do better than this, this is just embarrassing.


  • That’s all hinges on the assumption that your computer is pwned. Which is wrong

    You don’t necessarily have to have privileged access to read files or exfiltrated information.

    That point doesn’t matter anyways though because you’re completely ignoring the risk here. Please Google “Swiss cheese model”. Your comment is a classic example of non-security thinking… It’s the same comment made 100x in this thread with different words

    Unless you can list out all possible risks and exploits which may affect this issue, then you are not capable of making judgement calls on the risk itself.


  • That’s not how this works.

    This sort of “dismissive security through ignorance” is how we get so many damn security breaches these days.

    I see this every day with software engineers, a group that you would think would be above the bar on security. Unfortunately a little bit of knowledge results in a mountain of confidence (see Dunning Kruger effect). They are just confident in bad choices instead.

    We don’t need to use encryption at rest because if the database is compromised we have bigger problems” really did a lot to protect the last few thousand companies from preventable data exfiltration that was in fact the largest problem they had.


    Are you confident in your omnipotence in that you can enumerate all risks and attack factors that can result in data being exfiltrated from a device?

    If not, then why comment as if you are?



  • That’s not how this works.

    If the stored data from signal is encrypted and the keys are not protected than that is the security risk that can be mitigated using common tools that every operating system provides.

    You’re defending signal from a point of ignorance. This is a textbook risk just waiting for a series of latent failures to allow leaks or access to your “private” messages.

    There are many ways attackers can dump files without actually having privileged access to write to or read from memory. However, that’s a moot point as neither you nor I are capable of enumerating all potential attack vectors and risks. So instead of waiting for a known failure to happen because you are personally “confident” in your level of technological omnipotence, we should instead not be so blatantly arrogant and fill the hole waiting to be used.


    Also this is a common problem with framework provided solutions:

    https://www.electronjs.org/docs/latest/api/safe-storage

    This is such a common problem that it has been abstracted into apis for most major desktop frameworks. And every major operating system provides a key ring like service for this purpose.

    Because this is a common hole in your security model.



  • Not necessarily.

    https://en.m.wikipedia.org/wiki/Swiss_cheese_model

    If you read anything, at least read this link to self correct.


    This is a common area where non-security professionals out themselves as not actually being such: The broken/fallacy reasoning about security risk management. Generally the same “Dismissive security by way of ignorance” premises.

    It’s fundamentally the same as “safety” (Think OSHA and CSB) The same thought processes, the same risk models, the same risk factors…etc

    And similarly the same negligence towards filling in holes in your “swiss cheese model”.

    “Oh that can’t happen because that would mean x,y,z would have to happen and those are even worse”

    “Oh that’s not possible because A happening means C would have to happen first, so we don’t need to consider this is a risk”

    …etc

    The same logic you’re using is the same logic that the industry has decades of evidence showing how wrong it is.

    Decades of evidence indicating that you are wrong, you know infinitely less than you think you do, and you most definitely are not capable of exhaustively enumerating all influencing factors. No one is. It’s beyond arrogant for anyone to think that they could 🤦🤦 🤦

    Thus, most risks are considered valid risks (this doesn’t necessarily mean they are all mitigatable though). Each risk is a hole in your model. And each hole is in itself at a unique risk of lining up with other holes, and developing into an actual safety or security incident.

    In this case

    • signal was alerted to this over 6 years ago
    • the framework they use for the desktop app already has built-in features for this problem.
      • this is a common problem with common solutions that are industry-wide.
    • someone has already made a pull request to enable the electron safe storage API. And signal has ignored it.

    Thus this is just straight up negligence on their part.

    There’s not really much in the way of good excuses here. We’re talking about a run of the mill problem that has baked in solutions in most major frameworks including the one signal uses.

    https://www.electronjs.org/docs/latest/api/safe-storage


  • Because the lowest common denominator is much MUCH lower than you think it is.

    This means it’s easy to indoctrinate and easy to maintain that for a massive number of people.

    Scientific illiteracy is extremely high, and actual “6th grade reading comprehension” is the highest level of literacy for > 50% of a country like the U.S. and ~20% are low literacy or actually illiterate.

    This means that half of everyone in the U.S. can read and understand what they read at or below a 6th grade level. This isn’t “reading big words”, it’s “tell us about what you read”, “what is the relationship between x & y” type questions.

    This comment for example, up to this point only, would be difficult to understand & comprehend for > 50% of people in the U.S. (it demands an 11th grade reading comprehension). And may be misread, misunderstood, or not understood at all.

    People are driven to religions to cults and alt conspiracy theories when they don’t understand how the world works around them. They latch onto extremely simple often misleading or incorrect ideas of how the world works because they can understand it and it “makes sense” within their sphere of ignorance (we all have one, this isn’t meant to be a disparaging term).

    This means that the problem is that humans are just not smart enough to escape religion yet. It’s the simplest answer, and it appears to be correct.







  • Yeah, ofc it is.

    I’m working in a system that generates 750 MILLION non-debug log messages a day (And this isn’t even as many as others).

    Good luck grepping that, or making heads or tails of what you need.

    We put a lot of work into making the process of digging through logs easier. The absolute minimum we can do it dump it into elastic so it’s available in Kibana.

    Similarly, in a K8 env you need to get logs off of your pods, ASAP, because pods are transient, disposable. There is no guarantee that a particular pod will live long enough to have introspectable logs on that particular instance (of course there is some log aggregation available in your environment that you could grep. But they actually usefulness of it is questionable especially if you don’t know what you need to grep for).

    These are dozens, hundreds, more problems that crop up as you scale the number of systems and people working on those systems.


  • They usually do yes however it’s all about prioritization.

    You may have hundreds or thousands or open requests and issues.

    With tens of thousands of closed issues that were either not reproducible, not actually problems, or largely indecipherable.

    There’s usually a feature roadmap which is where most of the development money and time is spent. If it’s an older business application then certain bugs might easily take weeks to find, fix, test, validate, go through user acceptance, A/B test, and then deploy. But fixing is expensive work, so if the bug isn’t severe it’s usually deprioritized next to higher priority work.



  • I’m finding the opposite…

    Lots of posts made by bots, with majority top level comments being short quips and attempts at jokes as opposed to discussion. So many discussions devolve into ad hominems almost immediately.

    Just like Reddit.

    It’s a social media phenomenon I think. The lowest common denominator will always dominate unless communities push against it.