Tom Glod wrote:

> Richard..... in the labs ...... I am testing the viability of using
> Livecode as ONLY a UI layer.  So I have to find the fastest way of
> getting decrypted JSON data from Core process (Go binary) to the UI
> Layer that is a LC stack.

SLL encryption/decryption adds overhead to that process.


> So when communicating data via the localhost or socket, I figured it
> should still be encrypted if possible when in transit between the 2
> programs. It's an attack vector in this kind of a scenario, a local
> one, not remote as much.

The main benefit of encrypted sockets is to mitigate man-in-the-middle attacks.

If you have a man in the middle of processes on a local computer that isn't you, it would seem you have bigger concerns. ;)



> It would have been nice to reply on the protocol for it. I can get
> around this particular problem of course by encrypting on one side
> and decrypting on the other, also.  If I am really paranoid about
> my security.

Paranoia can be healthy, when taken as directed. There may be a benefit to encrypting localhost sockets that I'm unfamiliar with, and if someone can point me to threat vector I'd be grateful to learn.

But I can't recall seeing a system that uses encrypted comms on local sockets.


> What do you think will be the fastest way?  Socket? Open Process?

Sockets and multiprocessing are such different things I'm pretty sure I don't understand the usage scenario. But if you can describe we can brainstorm to optimize, as many good threads here have done before.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 ____________________________________________________________________
 ambassa...@fourthworld.com                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to