Follow

to have even some of the software freedoms when using someone else's computer as a server, you need to be able to see not only what software the server is running, but the exact source code for the software running on that particular computer. Is there a way to apply the concept of to binaries and scripts running on a remote server?

@strypey if the server owner wanted to silently introduce modifications to the code, even with reproducible builds they'd have many ways to do so.

For example, you can't check if the booted kernel is the same that one in a VM's /boot, and the kernel could be modified to patch binaries when they're being loaded.

So if the server owner is malicious, you've lost anyway.

And if the server owner is not malicious, that means when they say "it was build from this source code", you can trust them that it was.

What am I missing?

@Wolf480pl @strypey It's the same problem as detecting unofficial clients to a networked game. You might require the game to send a sha256 of its binary, but a modified client can of course be modified to send arbitrary bytes and claim those are its sha256.

@clacke @strypey
Yes

See also: Trusting Trust, DRM, Intel SGX, "they can't be sure unless they pwn you".

But this is not what I was missing.

@strypey you fundamentally need to trust that the server is being honest that the binaries it's runs correspond to the source code.

if you trust the server then reproducible builds can help, because we can build a binary from source and compare.

@rain
> we can build a binary from source and compare.

That's my understanding of what reproducible builds means. But what if we didn't need to trust the server? Is there a way servers could expose copies of the binaries they're running for comparison, without compromising their security?

Just spitballing here. It seems to me that serverless apps only cover some user needs, and currently the only way to know if you can trust a server is to run it yourself, or know the people who do.

@strypey @rain This is my understanding too.

We can't take a hard stance against serverside apps because they do have their uses, but too often things are serverside just because it's impossible to "pirate" that way or whatever.

@alcinnz @rain for sure. It's become such an ingrained habit that I even see projects that could easily be desktop clients built as "cloud" software, presumably so the developer has something to charge for (the hosted service). OTOH take something like , I guess you *could* build a version, but it would be incredibly complicated to keep everything in sync. I would like to see federation between Loomio servers though, so a user on Loomio.org can join groups on Loomio.foo.

@clacke @rain @strypey

I think the options are (?):

1. Trust the remote service; send it data it can read.
2. Don't trust the remote service; send it data that it can't read.
3. Don't trust the remote service; don't send it data.

For 2, there's very little profit motive in free-hosting data you can't read, therefore you don't get those services available as casually. Zero-knowledge services (eg github.com/fincham/paste or github.com/PrivateBin/PrivateB) do exist.

@clacke @rain @strypey

Also, consider the case of not trusting the servers you run yourself ... it's a problem :)

@clacke @strypey there may be the option of some kind of signed/homomorphic computation system, where you send a computation to a server and it returns the result and a efficiently checkable proof that the result is valid.

@rain @strypey Or you can have an inefficient checking that the result is valid, like the redundant checks in a blockchain.

Trust is efficient, that's why we built so many parts of our financial system on it.
Sign in to participate in the conversation
Mastodon - NZOSS

This Mastodon instance is provided gratis by the NZ Open Source Society for the benefit of everyone interested in their own freedom and sharing with others. Hosting is generously provided by Catalyst Cloud right here in Aotearoa New Zealand.