Governance (and government intervention) of updates to the SAFE network

Features
1

Hello all,

My understanding is that Maidsafe Foundation will create updates to the network code, and push those updates out to all vaults on the network automatically/compulsorily…

So if some government decides for example that the SAFE network is a threat to national security, or whatever, what is to stop them from coercing the team at the Maidsafe Foundation to change the code and introduce flaws/backdoors?

Even if we were able to see the hash of our locally running vault build and compare it to the hash of the open source repo build - what recourse would we have if the local build no longer reflected the repo’s build? If a rogue/flawed version was pushed to the network vaults and compromises it just once then wouldn’t that undermine privacy, which is the ultimate goal of the project?

Sorry if this is in the wrong place on the forum. Big fan, waiting patiently, just have a few such questions about the design of SAFE. Thanks!

4 Likes
2

I’m fairly sure that the plan is to make sure that that can’t happen by allowing both the old and new vault to run at the same time and check which is acting apropriatly and which isn’t.

Though the specifics of the process still alude me since I can think of a few ways to go around it.

3

Hmm, I haven’t seen anything to suggest that downloading updates will be optional. But even if that were true then I doubt that would work forever because sometimes it’s necessary to roll out backwards INcompatible updates.

4

Hello,
by the way, can a security government agency predict the SAFE net launch?
How do you know, if it had come coercing Maidsafe team or it comes soon?

1 Like
5

Haha. Next time someone asks for a launch date, we’ll tell them “go ask NSA”.

5 Likes
6

These are good questions.
I ask @dirvine about this in the last SAFE Crossroads podcast and we discuss it.

It is one of the last things to be fully worked out, but there are some promising paths. Also, I wouldn’t be surprised if there are plans to secure the updates in the interrum. We’ll see.

6 Likes
7

What about decentralizing the update release network? Like you have one node in say Scotland, one in India, a couple others around the world, and each has a multi sig key and it’s only when they all agree that the update is released to the network. They can’t all know one another so there would have to be a process where nodes, and techs, were selected for updates without all the other nodes being made aware of it. That way even if one government presures the Maidsafe foundation in one country they can’t control the whole network since the network at large controls the release and creation of updates, not the Maidsafe foundation.

Does any of that make sense?

2 Likes
8

I don’t understand the whole thread: the code is open source, so everybody can look at the commits history, check the code, and then recompile it from source.

Anything suspicious will be found and revealed to the world.

Also you can be sure that the code will be forked thousands of times and even re-implemented in other languages (like the bitcoin nodes).

3 Likes
9

ill:
by the way, can a security government agency predict the SAFE net launch?

I don’t understand the relevance of the question…

How do you know, if it had come coercing Maidsafe team or it comes soon?

We wouldn’t necessarily know if they’re coercing the Maidsafe team. That’s half the point - how would we ever know if the team has been compromised?

Blindsite2k:
What about decentralizing the update release network? Like you have one node in say Scotland, one in India, a couple others around the world, and each has a multi sig key and it’s only when they all agree that the update is released to the network. They can’t all know one another so there would have to be a process where nodes, and techs, were selected for updates without all the other nodes being made aware of it.

If one compromised keyholder knows who the other keyholders are - then those other keyholders could be compromised.

fergish:
I ask @dirvine about this in the last SAFE Crossroads podcast and we discuss it.

I’ll have to listen, thanks for sharing.

tfa:
the code is open source, so everybody can look at the commits history, check the code, and then recompile it from source.
Also you can be sure that the code will be forked thousands of times and even re-implemented in other languages (like the bitcoin nodes).

Sure, but my point is that, as far as I am aware, the Maidsafe Foundation is planning to push updates out to all the vaults on the network. Suppose I can look at the public repo and feel confident that the code is good, but then a compromised Maidsafe Foundation pushes an update to my vault, without my knowledge or consent, that contains code that isn’t necessarily in the repo. How do we know the vault code is the same as the repo code? That’s why I asked about being able to compare the hash of the repo build with the hash of the locally running vault build.

If Maidsafe Foundation don’t have authority to push backwards-incompatible changes to all nodes in the network then they hit the same governance problem that bitcoin has where miners have the choice of which version they run - and that seems like it would open up an entirely new can of worms for data integrity and network stability that I’ve not seen discussed anywhere.

I could be entirely misguided about this. Such concerns rest on the assumption that the Maidsafe Foundation will be able to forcibly push updates to all vaults.

10

@fergish thanks for sharing that. I listened to the relevant section (which, FYI, is Q21 and starts at 37:00 in the SAFE Crossroads podcast, and is reiterated at 48:07)…

It seems the conversation didn’t go into enough detail around this issue to put my concerns at ease… The discussion seems to be mainly about how the network should accept an upgrade, based on whether the output of the updated code is deemed valid or not. But that leaves lots of questions unanswered…

How does an upgrade get proposed? What @dirvine said suggests that one can run a node of arbitrary version and the network has the opportunity to accept/reject it. Does that then mean nodes have a choice of which vault version to run when participating in the network, so long as their output is valid? If so, then how would the network handle backwards-incompatible upgrades? Who would tell the network what the new valid output should be? And that seems to be the crux of the issue.

@dirvine also mentioned (at 48:07) that they’re not convinced on a solid mechanism for restarting the network, implying that’s related to this issue of updates - so how do network restarts fit in with rolling out updates?

@dirvine also says that this is one of the last big problems to solve for the network, and that it’s crucial to be able to roll out updates. So, it sounds like my question/concern is valid and still unsolved.

To me it seems you either go the route of having an authority determine which updates are valid or not, which leaves that authority open to coercion. OR you’re left with an update consensus issue, which seems like the same problems that bitcoin et. al. have with updates.

2 Likes
11

Ah, I just found the SAFE network upgrades topic, which appears to have much more discussion on the matter…

2 Likes
12

I think that once the network is live we will see a lot of developers from around the globe participating in development. If there is any attempt to break the privacy and/or anonymity of the network, we will hear about it … so, regardless of how the network updates, it will still be possible to fork it, if it is modified for ‘evil’ (insert your own definition of evil here).

13

forking doesn’t seem as easy for the safe network. You can fork the code easily enough, sure. For blockchain if you want to fork then that’s fine - you just copy the prior blockchain, fork the code, run the new code and it continues on with the new code and the existing history of data. But on a network that will have exabytes of data across the network - you can’t just fork to copy all that previous data, and I highly doubt the network would even let you access it all. So, presumably forks for the SAFE network will be code forks to start entirely new networks. But that doesn’t help if the main net contains immutable/permanent/sensitive data and then a new update is released that compromises the security of that data. If people put sensitive data on the network thinking it’s secure and then all of a sudden it isn’t - that’s irreversible damage to that user, even if you are able to fork a new network. At some point one of the forked networks would need to solve this very problem of governance of rolling out updates.

1 Like
14

You make a good point. I don’t have a good answer.

There has been talk of a “Safe-git” - a way of storing and editing the code on the network itself. I don’t know how seriously the idea is being taken by the team … but assuming we could have a Safe-git and assuming developers from around the globe are able to vote on code changes … and that these developers will have the anonymity offered by the Safe Network … then perhaps it will be quite difficult for governments to coerce change to the network.

1 Like
15

Well, voting online is hard too. Maybe for SAFE they’d be able to allow trusted vaults to be able to vote? … but otherwise it’s too easy for CIA/NSA botnets to create hierarchies of fake identities and networks to sway votes in their favour.

1 Like
16

This library must not be used for consensus code (i.e. fully validating blockchain data). It technically supports doing this, but doing so is very ill-advised because there are many deviations, known and unknown, between this library and the Bitcoin Core reference implementation. In a consensus based cryptocurrency such as Bitcoin it is critical that all parties are using the same rules to validate data, and this library is simply unable to implement the same rules as Core.

Given the complexity of both C++ and Rust, it is unlikely that this will ever be fixed, and there are no plans to do so. Of course, patches to fix specific consensus incompatibilities are welcome.

– GitHub - rust-bitcoin/rust-bitcoin: Rust Bitcoin library

i think, there are no permissions on reading data, everything is encrypted, you either have the passphrase to decrypt an encrypted data set, so you can access it, or you do not.

1 Like
17

even if you were able to read all the data - my understanding is that the network is set up in a way that you can’t just clone it on a new forked network. unless you’re able to recreate all the nodes, their id’s, their keys, etc. Each user knows where their data is based on their keys, and you’d have to be able to put that data back in those places, with all the right xor addresses and blah blah… the technical details are getting beyond me here, so I’ll stick to just saying I’m highly skeptical you’d be able to clone all the network data for a network fork.

2 Likes
18

i think you could do that by first making a large enough network to store the user data. And then copy the user data onto it.

the node ids are just for the routing. the sections history, thus the datachains would be different, but that’s just the structure of the network it self, and has nothing to do with the data stored onto it. that’s similar to how the network can change it’s shape (old nodes disconnecting/new nodes connecting) without losing user data. The user data would keep it’s ids (that’s simple for IM, but you could just copy the ids of MD)

19

ok, well, cool… if you say so, good to know the network data is forkable :slight_smile:

20

i don’t know if it’s possible to make an exact clone (you could still change the data (at least public data) while copying it or not copy some data sets), making a fork less acceptable by the users.