[asdkhadsj]

I agree with your concerns - I wonder what could be written to alleviate them? This brings up an interesting problem.

Ie, could we write a monitoring proxy where if enabled, all traffic goes through this proxy. This proxy enables the end user to monitor 100% of traffic, all http requests, and could even have a secondary documentation flow that explains the I/O for security minded individuals.

Then you'd shut off remote network access to the binary, monitor all traffic, and feel secure knowing that it's only sending what it says it's sending, and why.

With that said, I imagine you could do the same thing with a sniffer. Perhaps a documentation standard could be built into request/responses, so a monitoring program like Wireshark could snuff the I/O and see what it is.

Do you have any thoughts on how someone could both network-license, and make you feel secure in their I/O? Ie, no trust needed?

[itdaniher]

I don't think a DRM solution that is both robust against an adversary and inspectable by a stakeholder can be engineered. Software can't look out for both the person running it and the person selling it simultaneously when their needs are mutually exclusive. Cory Doctorow has some eloquent content on the topic, ie at [0].

In this particular case, the use of TLS (good!) makes it relatively challenging to inspect. Assuming the author isn't shipping a cert in his binary (doesn't look like it) - I'd have to spinup a new VM, load a custom root cert, and mess with a TLS terminating proxy / forwarding solution, and hope he's not using a secondary stream cipher on top of TLS. Maybe I get lucky and https://mitmproxy.org/ or something just works out of the box. In any case, lots of effort to know he's not siphoning up all the source code on the local machine and using it to train v2 of his project. And the more robust the DRM solution, the less feasible it is to inspect.

[0] https://github.com/jwise/28c3-doctorow/blob/master/transcrip...

[achamayou]

If the amount of traffic is predictably small though, you can be confident that it’s not uploading the entirety of your source code, so perhaps some mechanism to estqblish that would help?

[gbear605]

Some code is a lot more valuable than other code. For example, token files for connecting to remote servers.

[achamayou]

There is no good reason for authentication secrets to be in your source tree though.

I’m not suggesting this is perfect in any case, but it would at least place an upper bound on whatever amount of IP leakage you think might happen.

[heartbreak]

But do you ever edit your authentication secrets in your text editor? I edit my .env file in vim all the time.

[nickpsecurity]

A combo of two applications: main app and network agent. Main app writes to a file with request, registration check or update, in JSON or other text-format for user inspection. It loads the agent which reads same file, applies operations, sends them to 3rd party, and writes result into another file. Main app reads that the second it appears. To keep it simple and not have to delete, the files might be numbered with old exchanges kept unless admin/owner deletes them.

With such a setup, users can see exactly what data is outgoing, have a reasonable belief they know what's incoming is harmess, main app gets no network access, agent has no access to secrets/system, and agent can be open source (entirely or mostly).

So, there's a quick brainstorm from how I did privilege-minimization for high-assurance security. This is basically a proxy architecture. That's a generic pattern you can always consider since it can help protect lots of risky apps both ways.

[elyase]

Take a look here for some solutions:

https://www.openmined.org