Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design for trust and security #2

Open
penguineer opened this issue Dec 8, 2022 · 0 comments
Open

Design for trust and security #2

penguineer opened this issue Dec 8, 2022 · 0 comments

Comments

@penguineer
Copy link

I like the idea of a decentralized network, especially seeing how much effort we put at FFMD into maintaining firmware builds and gateways. However, I also agree with #1 that decentralization, in the end, is mostly a social challenge.

Who governs the network?

If I continue thinking along #1, I end up without specific Freifunk communities. Every two routers with matching firmware can initiate a Freifunk network. However, as @christf also mentioned, there is no governance on the rules of this network.

On the other hand, people connecting to the ESSID Freifunk have some expectations, e.g. that their connection meta-data is not stored and that the connection cannot be traced back to them, to name the biggest ones. In a truly decentralized Freifunk system there are no guarantees to comply to these expectations.

This gives a new task to the Freifunk communities: Define and govern rules and expectations for the Freifunk network.

Protection against malicious parties

Even with a healthy community who sets and monitors rules and guidelines for the network, there is no guarantee that these rules are upheld.

Malicious parties may inject nodes that capture traffic, expose users or try various attacks on the network or its users.

An important question is: How can we make sure that nobody attacks a decentralized network?

Our current solution works via a central team that shares trust, especially by accepting signatures from members who are noted in the site config. The only way to distribute a firmware into the system is by getting onto that list and finding enough members of this core team to sign this version.

How to anchor Trust?

What happens if everybody can build and distribute new firmware? Are we a network of Bitcoin miners tomorrow?
(The other way around: What happens if we leave this to the node owners? Many of these do not know or care how to do this, so we would end up with obsolete firmware, aka future Bitcoin miners.)

Who would be allowed to provide an open WiFi network with the ESSID Freifunk in Magdeburg?
How can you trust the network you connected to?

This is an unsolved problem today. If the WiFi name an credentials match we connect and happily send our data, even if it's an un-encrypted Freifunk WiFi.

While some things cannot be solved so easily (like how to trust an ESSID), others in the proposed decentralized network can. We can still build a trust network of nodes and find a mechanism to get into that network. (For example, having pre-built firmware images or adding your own signing key to a trust network with social review, such as a key signing party or participation in the community; trust by merits.)

Start with security!

I believe it is adamant to consider the trust and security aspects from the beginning. It will be very hard to add a trust level on a network that is already designed for complete openes - as much as I wish we could just do that, the world and the Internet as part of the world turned out to be differently.

We need to take these social aspects into account and build the technical solution around that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant