Of course you have to trust them with anything going in clear-text on their servers. But you don't have the vendor lock-in you'd have with proprietary alternatives. It can be a great bridge between Google/Apple/Microsoft/etc and self-managed, if nothing else.
Guarantees are hard to come by. That's where reasonable amounts of risk assessment enter the picture.
If you're looking for absolute certainty
Compiling from scratch isn’t necessarily such a big deal these days (guix/NixOS/gentoo for base system, locally built containers for orchestrated services).
Personally I’m fine with putting some level of trust in the maintainers of Debian apt repos but everything else I definitely do take a look at where it’s coming from and what’s going on. There’s a middle ground between fine-combing the source tree and blindly accepting whatever comes from arbitrary upstreams.
At the end of the day, we largely trust canonical or the distros maintainers to not do anything malicious, even by accident.
I see Libre cloud as a similar situation, though with more avenues for larger-scale abuse. Hopefully, just like with other things FOSS, the community will validate that everything is fine and the risk is minimal.
We speak for ourselves!
Long answer: It could be, if proper protocols and data structures would be employed that make it trivial to move the data off the server, mirror it or dual host it on multiple servers at once. So far there is however barely anything that does that, git for version control, IPFS for simple file hosting, but that's about it. The tools to build a "Libre Cloud" don't really exist (and federation is snake oil).
I'm very interested in this domain. Hubzilla has pioneered account migration with the ZOT protocol, and there's discussions in the Jabber/XMPP ecosystem to implement something similar. Personally, i'm curious about going beyond a single protocol and migrating entire server services from a hosting coop to another: https://ttm.sh/dVy.md (draft blogpost)
> The tools to build a "Libre Cloud" don't really exist (and federation is snake oil).
There's Yunohost.org, Freedombox.org and Libreserver.org (ex FreedomBone). They're very cool, and enable non-tech users to selfhost.
Why would you say the federation is snake oil?
With federated services your are still just user@host, completely under the control of whoever owns host. Furthermore the federation aspect is completely optional, if host decides to blacklists some other hosts, there is nothing you can do about it. So I don't see the advantage over the Twitter, Facebook and Co., when everything that makes federation special can be taken away at any moment.
Without some public-key crypto or something that allows you to move your identity to another server or better yet, never exist on any specific server to begin with, I just don't see the point.
In general, I think the only way to build a "Libre Cloud" is by making the cloud part as stupid as possible. Have the actual app run completely on the client, use the cloud just as dumb object store with little to no awareness of what it is serving.
Not exactly, no. It can be taken away when your server operators decide it. But in the federated model, we go with explicit trust relationships and non-profit, community-operated hosts so that's not a problem in practice. In fact, i'm glad my server operators actively defederate from neonazi-friendly nodes, so that i don't have to deal with them... just like i'm glad my email operator validates DKIM and uses rate limiting to prevent spam.
> some public-key crypto or something that allows you to move your identity
That's a very interesting approach. It's been implemented in the ZOT protocol (Hubzilla ecosystem), and has been talked about in the Jabber/XMPP and Matrix ecosystems too. I'm excited for that future, if we can come up with an interoperable spec across protocols.
> use the cloud just as dumb object store with little to no awareness of what it is serving
That's an interesting approach indeed, and i'm interested if you have more resources/links on that. I've been thinking for a while about reducing the difference between federated and P2P services, like how servers could help you seed your content, and/or act as inbox for when you're offline.
I've started drafting a blogpost in that direction a while back.. nothing much in there yet but if it can be of interest to you: https://ttm.sh/tHG.md
These seem like advantages to federation. You can choose your masters, and you can choose another master (and they can choose to get rid of you) at any time.
I don't think that the advantage of federation over centralized services is that you can say and do what you want and everyone has to listen to or service you. It's that you have more options than one.
Of course, in the worst case, most nodes could federate into an exclusionary cartel controlled by a single, well-financed organization. But that means that the worst case for federation is the only case in the current situation.
-----
edit: I do think that the major thing missing from the web 2.0 user-provided content internet are tools to facilitate democracy and self-governance. With properly done tools and ownership structures, maybe the users can actually own their accounts, and have as much of a say in how their node was run as you would expect in an organization of peers.
That's only if your federated protocol supports account migrations (usually with some form of crypto-identity). This was pioneered as part of the Hubzilla ecosystem and ZOT protocol. Nowadays there are efforts to port this approach to ActivityPub/XMPP/Matrix, we'll see where that goes!
Of course it's all easier if everyone owns their domain name and you can migrate "transparently". But the tooling for giving away free, pseudonymous domains is limited so far (afraid.org, netlib.re, eu.org..).
An interesting question: How do you verify the code running in the 'cloud'?
And to rehash an old but relevant point: Practically, you don't know if local FLOSS software is the same as its released code, and you don't even review the code so it doesn't matter, to a degree. You are still operating on trust to some degree. But with local FLOSS software, someone else might review it, which seems difficult for hosted cloud software.
There's strong efforts for reproducible builds and bootstrappable distros in the past years. NixOS and guix have pioneered the field, but i believe both Debian and ArchLinux are now over 90% reproducible.
> seems difficult for hosted cloud software
Yes, it's outright impossible. That's why we need effective decentralization via free-software selfhosting solutions, so that you can place your trust in people you actually know and trust, not a "random" centralized free software operator like this one. That's the lesson framasoft.org has learnt when their degooglization campaign was a little too much successful, so they started a new "deframasoftization" campaign which gave birth to the chatons.org federation of non-profit hosts. In the english-speaking world, libreho.st comes to mind.
> There's strong efforts for reproducible builds and bootstrappable distros in the past years. NixOS and guix have pioneered the field, but i believe both Debian and ArchLinux are now over 90% reproducible.
That's a valuable step, but few people build their OS. In practice, few people will know if their copy matches the released code.
>> seems difficult for hosted cloud software
> Yes, it's outright impossible
I think it may be possible, but it will require different tools. Remote attestation? Can we verify what is running in memory?
This is true! That's why guix project has been working on `guix challenge`, which lets you inquire about checksums for a specific package from various repositories, to make sure they are the same. I personally think such an approach is a huge step in making software somewhat-verifiable by non-tech people (although guix is not exactly approachable by that audience, i'm talking about the principle).
> Remote attestation? Can we verify what is running in memory?
Yes and know. You can if you trust the hardware/software doing the remote attestation. Signal project for instance has argued that a centralized server with Intel SGX "secure enclaves" is the safest we can do. I personally strongly disagree, and i believe vulnerabilities found since then in Apple/Intel/AMD security chips go against that argument.
Software security is almost tackled with bootstrappability, reproducibility and "challenges". Hardware/firmware security is an entirely new thing...
If it that isn't 'safest', what do you think is safer (and practical)?
Distributing trust is safer and practical. A single, centralized server will always be vulnerable, whatever defenses in depth you deploy. Standardization and decentralization is more valuable in the long run for privacy/security than any customized efforts.
That's what allows us these past years to do PGP over email over Tor onions, transparently via onionMX SRV records (+ a local cache/mapping to prevent lying DNS). Meanwhile, Signal still requires a unique identifier (phone number) to operate and mandates usage of AWS and other privacy-hostile providers to reach their server, and there's nothing we can do about it because they control the entire infrastructure. Some resources on that:
- https://gultsch.de/objection.html <-- A free-software Jabber/XMPP client developer's answer to Signal team's stance against federation and open standards
- https://north-shore.info/2019/06/02/signal-fails/ <-- A critique of Signal from a militant, non-tech, "security culture" perspective