Truly Anonymous

Just trying to get my head around how MaidSAFE is both decentralised/anonymous and at the same time has:

  1. A requirement to authenticate via login credentials with IP tracking that must be validated/recorded
  2. Authenticated transactions in coinage that must be tracked ‘from’ and ‘to’ and recorded against those accounts (so that there isn’t double spending/crediting)

If there is a userid tied to an IP that’s being authenticated and that information is used in managing coin transactions, both from/to, then isn’t this in effect offering the MaidSAFE developers and administrators the backdoor into the system?

Yes, I get that transfers are encrypted, that file storage is encrypted. That’s not the part that makes me wonder…

2 Likes

At this time you need an invite key. But when in beta you just connect to the network (a group of vaults) and they have no clue who you are. They just see that users “dhjgfdjhfghgfbcnvrytgrluiwhgfldkbfdnks” connected to the group over a proxynode. And the proxynode knows to which group you connect but can’t see any communication, just gibberish data.

So no central server, just you connecting to a group of vaults.

4 Likes

So these vaults will be able to lookup my authentication details to see if they match, verify my IP matches my account, check my coin balances, deduct when I put and credit when I store?

No, these Vaults won’t see your IP. It is removed at the first hop. They see you have an account and know your balance (allowed PUTs), otherwise you wouldn’t be able to store anything on the network. But they don’t know your Safecoin balance. They might see that you want to move a certain coin from A to B and if you sign the transaction is just valid, but they don’t know which coins you own, not even which public name you use. So what the vaults know is something like:

  • This is user “dhjgfdjhfghgfbcnvrytgrluiwhgfldkbfdnks”.
  • This user is allowed to PUT 950 mb. to the network (balance 950 PUTs)

And for the rest they don’t know a thing.

11 Likes

So they’re not doing the authentication (at or before the first hop). Is it an auth/relay node doing that then, outside of the vaults? A bit like

If so, these form a trusted component of the network which would be particularly key obviously, to many things. But, aren’t these ‘key nodes’ that perform authentication/relaying controlled centrally in some way? Intuitively, one would expect there to be failover, logging and other control functions managed by something other than the vaults. Of course, that’s intuition - not the facts of this network :wink:

The authentication is done client side by a process call self-authentication. You ask for encrypted credentials, and other basic data, stored in a password derived network position. This data are decrypted client side. You use this credentials to interactuate with the network.

For third party apps you can read this RFC:

And as @polpolrene say, the coin balances and the storage balances are different thinks. You buy storage with coins and the vaults verify that you have enough storage balance but only you know your coin balance.

8 Likes

Thanks polpolrene and digipl for the discussion, and especially the link to that explanation + RFC. Just what I was looking for!

5 Likes

you may want to look at this page to get a first grasp of how things are tied together :

https://safenetwork.wiki/en/Efficient_-_Self_authentication ( PINs were removed since, but the idea remains )

Two other videos that helped me to get started :

Self encryption : https://www.youtube.com/watch?v=Jnvwv4z17b4

XOR space : https://www.youtube.com/watch?v=w9UObz8o8lY

EDIT : this series of talks by SafePod Montreal is really cool :

7 Likes

Robb, to understand how the features of the network can possibly work you will need to look into the nuts and bolts I’m afraid. Step by step I think anyone who is willing can get to a level of being satisfied, but it’s not a simple or short process, so keep questioning!

Two of the key pieces to understand are how data is stored/distributed around the network, and self encryption. The MaidSafe video at maidsafe.net (assuming it is still there) is a good start, then get to grips with self encryption. Then look at how authentication is done, but note that nowhere do nodes “look up” anything about you, they just handle very simple operations, sending messages that ultimately move chunks of encrypted data from one node to another without knowing where the request came from, what the chunk is, or where it is going. Your credentials don’t even leave your machine - because you don’t log into a server, but your credentials act like a key that opens a map, which let’s you retrieve your data from the network (still encrypted), and which your password then allows you to decrypt (on your own machine). So no authority, no servers, no way to identify you with your data, no surveillance, no points of censorship.

It takes a bit to get your head around because we are all schooled in a different way of systems working/thinking, but it is well worth learning how this works. It is quite beautiful, like nature from which the fundamentals of the design are inspired. Not least, ants :ant: :ant: :ant: :slight_smile:

17 Likes

I am unsure if you now know that any IP used is only for the invite and this system is only for the testing till SAFEcoin is being tested.

It is not a part of the network operations after that.

In other words your IP address plays no part in authentication or account security for the live network. IP Address will never be recorded. It is stripped at the first hop.

All network addressing is using XOR addresses so your IP is not needed to send SAFE packets around the network.

4 Likes

Thanks for clarifying this point. I was reading the discussion and got confused about this.

Thanks Nick. I wasn’t aware of the testing vs production differences thus far.

I’m still trying to find the docs on hash collision avoidance - how it’s implemented, but I’ll find it in due course :stuck_out_tongue: I realise it’s improbable but not impossible - and just was trying to see the approach (as well as risks).

Frankly, my concern is that, if the test system uses/tracks IP’s at this stage, and they’re key to auth - how do we know they’re not implemented in the production system, aside from you telling us that they aren’t. I’ve got a lot of reading still to go, heheh.

If this style of invite is in the production version then its not fit for its purpose. Thats pure and simple. On the initial usage of the invite system many expressed concerns along this line and it was made clear that it is only for the tests. Even David a few days ago said such.

1 Like

There was already a testnet where we ran vaults from home without any of this extra authentication. The problem was there was no cost to upload to the network (no SAFEcoin yet), so the network was filled up.

3 Likes