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:
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.
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.
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.
OSs provide keyring features already
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 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.
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.
Cmon, you can do better than this, this is just embarrassing.
Why exactly am I re-reading your post? Im in complete agreement with you? Should I not be?