Questioning loss of session base encryption (SAFE Launcher API v0.5) about rfcs HOT 1 OPEN

Some notes:

Firstly, while attackers can in theory obtain unencrypted information by other means such as the filesystem, a keylogger, or indeed the memory space of individual apps, these methods are in no way comparable to the ease of some malware simply logging or monitoring all App <> Launcher communications.

This can be said about anything. Convenience matters. When you don't hardly gain anything, this is not worth it. I can provide many examples of software that does not use local IPC encryption, and not very many that does encrypt IPC. Do you encrypt resident memory in your software? Because that's basically what local loopback is.

By leaving that channel wide open, malware can focus in on and collect everything the user saves and retrieves from the "Secure" SAFE Network.

Incorrect, they have to be given the ability to sniff packets. With that level of freedom, they can do much worse.

Suppose we have data that is created in the App that needs to be stored safely, but the App developer has not really considered or recognised the importance of keeping that data secure. Or perhaps doesn't have the time or skill to figure out how to use an encryption library and so skimps on security

I think you are confused. I am talking about not encrypting data in memory that is sent from one program to another. I.e. in transit. Has nothing to do with storage. The bad app dev is still gonna screw you over, this doesn't change that in any way whatsoever.

I follow @cretz' point (in the earlier discussion) that it is up to the App developer to secure and therefore encrypt data where needed, but that runs contrary to the approach of needing to try where we can to protect users (and in this case App devs) from themselves where that is possible.

That comment is about storage. In transit over local IPC call would make little sense to encrypt. Do you think all shared library invocations are encrypted? I mean, these invocations on the launcher are essentially just like COM or other shared library invocations.

I think you are confused between data security and how bytes move on the OS between processes. The lack of encryption on communication between processes, which has been removed, is reasonable and has nothing to do with whether data is encrypted in general either by safe or by individual apps.

And the original encryption issue was how it was poorly implemented where it could just be implemented with TLS on HTTP. The way it was implemented I can guarantee you would have harmed the ability to stream anything. It can be re-enabled if the launcher wants to use custom X509 certs which is not a big deal. There are many other problems with local machine security, such as the fact that all I have to do as an app is spoof your app ID and now I can do anything the app would. Many of these aren't solvable reasonably and this is why you are prompted.

from rfcs.