5 ms·

Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges. I used to use protobuf but now I just use JSON

by klabb3 1y ago

Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges. I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.

cyberax 1y ago
Why not ConnectRPC? It's basically gRPC but without all the strange requirements for exotic HTTP features.
- nu11ptr 1y ago
  I actually use this currently. Not nearly as many platforms, but you an always fallback to gRPC.
- newswangerd 1y ago
  I've never heard of ConnectRPC before! Will check it out.
nu11ptr 1y ago
Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.
- dvdkon 1y ago
  Then you have to deal with port collisions when some other software wants to use that port. And keeping a port open without any authentication is terrible for security, even if it only binds on localhost, so you have to find some secure way to share a key between the client and server. Personally I wish we could just use UNIX sockets for "localhost-only TCP", but software support is just not there.
  - nu11ptr 1y ago
    I don't worry about security too much given it is just bound to localhost, but I do use a simple password (and make it modifiable by the user). Avoiding port collisions in the real world isn't a big issue, just ask an AI for the least assigned default ports and chance of collision is minor (in worst case, also user modifiable). In return, you get free "remotability", which is kind of a big deal IMO. I do wish gRPC allowed for easy usage of UNIX domain sockets and perhaps named pipes, however. Sometimes all you need is IPC, but in my case, I'm happy to have remote usage builtin.
    - dvdkon 1y ago
      You should worry, system users are relied on to effectively separate privileges even in "single-user" desktops. This has led to privilege escalation before, not to mention the potential for browsers to access these ports [0]. That said, a random password should be enough protection, even if it isn't the cleanest solution. [0]: e.g. https://palant.info/2020/06/22/exploiting-bitdefender-antivirus-rce-from-any-website/ https://palant.info/2020/06/22/exploiting-bitdefender-antivi...

by klabb3 1y ago

cyberax 1y ago

Why not ConnectRPC? It's basically gRPC but without all the strange requirements for exotic HTTP features.

nu11ptr 1y ago
I actually use this currently. Not nearly as many platforms, but you an always fallback to gRPC.
newswangerd 1y ago
I've never heard of ConnectRPC before! Will check it out.

nu11ptr 1y ago

Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.

dvdkon 1y ago
Then you have to deal with port collisions when some other software wants to use that port. And keeping a port open without any authentication is terrible for security, even if it only binds on localhost, so you have to find some secure way to share a key between the client and server. Personally I wish we could just use UNIX sockets for "localhost-only TCP", but software support is just not there.
- nu11ptr 1y ago
  I don't worry about security too much given it is just bound to localhost, but I do use a simple password (and make it modifiable by the user). Avoiding port collisions in the real world isn't a big issue, just ask an AI for the least assigned default ports and chance of collision is minor (in worst case, also user modifiable). In return, you get free "remotability", which is kind of a big deal IMO. I do wish gRPC allowed for easy usage of UNIX domain sockets and perhaps named pipes, however. Sometimes all you need is IPC, but in my case, I'm happy to have remote usage builtin.
  - dvdkon 1y ago
    You should worry, system users are relied on to effectively separate privileges even in "single-user" desktops. This has led to privilege escalation before, not to mention the potential for browsers to access these ports [0]. That said, a random password should be enough protection, even if it isn't the cleanest solution. [0]: e.g. https://palant.info/2020/06/22/exploiting-bitdefender-antivirus-rce-from-any-website/ https://palant.info/2020/06/22/exploiting-bitdefender-antivi...