The doubts thread

Meta
1

Those interested in computer security will no doubt have heard by now that “security is a process”. The idea is that security is not a thing you can buy and have sitting on you shelf forever. Rather it is a living thing that requires a constant stream of work and resources to exist. The second you stop feeding it, it starts dying.

My idea for starting this topic is that sanity, too, is a process. Left to their own devices, even communities of level-headed and rational individuals can devolve into cultish echo chambers. They fall prey to affective death spirals, stuck in a positive feedback loop of enthusiasm about the Best Thing Ever.

I’m afraid MaidSafe has great potential for being the Best Thing Ever. It’s ambitious, it’s disruptive, and it’s got a great mission, and if you’re reading this, you most likely want to see it succeed - perhaps on an emotional, as well as intellectual level. So what? Nothing wrong with that. Except that MaidSafe is not the Best Thing Ever.

This is not an attack against MaidSafe, mind you. MaidSafe is not the Best Thing Ever, because there is no such thing. No, MaidSafe is not without flaws, nor will it ever be. No, it is not without downsides. No, it won’t solve all your problems, or even all your Internet-related problems. It’ll most likely create some of its own.

But what’s with the negativity? “What are you doing here if you don’t like this project?”

Oh, but I do! I’ve put this topic in the Meta category, because it’s not primarily about MaidSafe. It’s about the community, about keeping a cool head, a putting in the effort necessary for sanity maintenance.

Criticism is not an attack to be defended against. Doubts do not require systematic elimination. The instant this is not true anymore in a community, you know its has succumbed to the affective death spiral. A healthy community welcomes criticism, and does not see its originators as traitors or adversaries.

Of course, I’m not saying that relevant refutations are not welcome here, quite the opposite. But I’m saying that we shouldn’t necessary look for one if none springs to mind. We’re not defending MaidSafe here, we’re defending the truth, and if the truth is that some doubts about MaidSafe are valid, then so be it. If you start looking for a refutation, then you’ve decided what your answer was going to be before you even started considering the question.

So here’s a topic dedicated to the flip side of the coin. Take all those nagging doubts of yours, and post them here, not necessarily in an attempt to see them refuted, but in the hope that unless there is a clear reason not to share them, people will end up sharing them as well and having a more accurate view of the project.

If these doubts spark discussion, then great! Let’s discuss the problem, look at its implications, the things it relates to, its consequences, and its possible solutions. We can fork specific issues into their own topics. Let’s keep our sanity together!

So I’ll start:

I’m really worried about network latency. RUDP packets will typically hop across several (say, 3-10?) nodes between their source and destination. Nodes are randomly distributed across the address space, which means that, assuming world-wide adoption, neighboring nodes could be on opposite sides of the globe. I’ve seen @dirvine mention many times that it made sense betting on the network over local HDDs if you considered that network bandwidth was increasing faster that HDD speed, but network latency will always be much higher than HDD latency, because both are bounded by the speed of light. You could pull magical super-resistant optic fiber cables through the earth to link nodes sitting across the globe, and still you’d be looking at >80ms ping between those nodes. Multiply this by, say, 5 hops on average, and you’re looking at ~400ms RUDP pings.

This makes MaidSafe unsuitable for a whole host of applications (real-time video games come to mind) for which data cannot be cached. VOIP is less sensitive to latency, but depending on real-world figures, it might be out as well. I’ve had a recent disastrous experience with a VOIP call between France and Australia, with latency as high as five seconds. Now imagine that even Troon - Troon calls could get even worse worst-case performance sometimes because messages could pass through Australia, Antartica and the ISS before coming back home.

Latency matters. It’s one of the biggest things one needs to get right in order to build a great user experience - hence the recent push for async everywhere. I’m just not sure that it can be hidden well enough in all cases not to hurt MaidSafe’s adoption despite all its awesome advantages.

So that’s it, that’s one doubt I have. Discuss, or post your own.

Cheers,

Christophe

8 Likes
2

People might shoot me down for this, but as soon as I want to establish a real-time connection with a MPID (a phone call to my mum), surely at that moment we can exchange IP addresses in the app level through an encrypted channel and use rUDP, or standard UDP to directly send packets. The many hops are required for sharing information in an anonymous, untraceable way. If your security position really requires this (eg Edward Snowden’s live video feed to TED also hopped over five proxies, but well-connected ones for HD) then latency might be less of a concern.

EDIT: PS: sorry for being so adamant that there is no reason for doubt at all :). It took me a few paragraphs to understand your post, and I actually think we should start a new category ‘doubts’ (@David); it’s good to share doubts, it will make the community stronger!

3

I’m listening. :smiley: For now “doubts” is a bit too narrow to have its own category I think. I’d rather have too few categories than too many so let’s wait and see.

I think the Network category works for some doubts (specific, focused on the technology), the Strategy category for others (“will we actually get anyone to use SAFE?”). If it doesn’t fit anywhere, leave it uncategorized.

I completely agree with this.

1 Like
4

@caguettaz I think this is a great point you make.

@David I am glad you are being so careful and dilligent about looking after the forum, being willing to say “no” (or rather, more gently “let’s see”). I too have asked for categories etc and am happy to receive a no (even if I disagree!).

As for a Doubts category. I agree it can fit in other places, and Network was kind of created for doubts - actually Problems & Solutions. I’m not sure! I’d like the invitation to “Doubt” to be more prominent than this one topic, and I think having a category for it is a mark of strength so I’m tending to like the idea - although I’m not sure it would get many posts. Let’s see then! :slight_smile:

5

I like your writing style. I too have Q&A conversations with myself when trying to solve problems.

I was trying to teach my niece about humility in knowledge. I said, “you should never assume what you know is absolutely true.” She responded with a smirk, and said “so you just go through life not knowing anything?” To which I answered, “in a way, yes. This is how we evolve and advance our understanding of the universe.”

My doubts on the project are not really doubts, they are more like questions that need to be answered. As an analyst, I prefer to test things. I’ve always held this deep principle. It doesn’t matter what I believe, only what works.

If the network latency ends up being too slow, my next question would be, how can we speed it up?
We’ll see what’s what, when the Network Launches. Like all things, it will evolve and improve if we have a willing community to make it happen.

1 Like
6

Ok @dyamanaka who was your mentor! I have a couple of catchphrases along these lines, one of my own is something I tag onto my thinking whenever I reach a conclusion: “…and don’t forget factor X”. This is to remind myself that I can’t ever know anything to be true. There is always more!

The other is not mine but a really great principle which not everybody is ready for (it goes rather well with both/and rather than either/or thinking): “ask not whether something is true, but what effect it has”

2 Likes
7

I learned about humility in knowledge in 7th grade. The science teacher had 2+2=4 on the chalkboard. He asked the class of 60 who was 100% sure this was true. It was first class of the day, and nobody raised their hand except one girl. The teacher screamed at her “Never be 100% sure of anything. Go outside and think about that!”. The poor girl had never been in trouble in her life, and went outside crying.

That moment will forever be etched in my head. Never be 100% sure of anything! lol

8

Poor girl :frowning:

That was a harsh way of teaching.

Indeed, if we were so sure of things. We would probably still be thinking the world was flat, and the sun revolves around the earth.

9

What an asshole! How people treat children like that is beyond me!?

I wish the kid had said “Teacher, are you 100% sure that you can never be 100% sure?”

2 Likes
10

I understand the point the teacher wanted to make, but he made it in an awfully misguided and irresponsible way. The point he should have tried to make is that if you want to be consistent in your reasoning, you can never have complete knowledge. We learnt that much from Gödel in 1931. It’s also more a lesson in arrogance from the teacher, than humility for the poor girl. :slight_smile:

11

The point on latency really is a big deal that causes concern, but we’ll really have to see what develops as testnets get into the 3rd or 4th iterations (from what @dirvine has said elsewhere). I’m very hopeful, if not certain, that solutions can be found and made to work acceptably.

Even if latency is a problem, though, the anonymity of the network and safecoin, and uncensorability are tremendous advantages, and will make it worthwhile even if slow, I think. But again, we’ll see. We’re creating an adventure here.

It seems, from what I can tell, that the key technology is in place to make those things above reachable, even if the rest of the network doesn’t live up to all of our hopes. There are many other things that the network “might” be, but I’m banking on those key things.

@dirvine, a straightforward questions: The plan is pretty solid already as regards those key points (anonymity, safecoin and uncensorability), correct? That is, after all, the bedrock.

It really is a good thing to be realistic with our concerns and differentiate solid capabilities from hoped or planned ones, as @caguettaz lays out above.

2 Likes
12

Returning to the original point, latency is a concern for me as well. I think the problem can be solved with clever optimizations in the routing layer. However, this will be innovative and challenging work. I hope the community is patient.

Getting a bit more meta, my primary concern is the complexity of the system. There are so many moving parts and interdependent systems involved, each one innovative in its own right. There are a lot of pieces that need to work just so to keep the system stable and balanced.

One of the implications of that complexity is that user training and marketing will be a challenge. I like to think I am relatively knowledgable about these sorts of things, and it still took me a month to get my head around a basic understanding of the maidsafe paradigm. Presenting the advantages and functionality of the network will be a challenge to application developers, let alone end users.

Take the recent thread on crypto-reddit for example. They took one look at the self-encryption scheme and dubbed it crap, and from a conventional file encryption viewpoint, it is. You need to understand the other aspects of the system (deduplication, vaults, hash ID’s, etc) to be able to understand the goals and tradeoffs made in the self-encryption component.

Below are some of my thoughts on this side of things. It is a bit stream-of-consciousness, but maybe it will be interesting. I think it will be a challenge to explain all these possibilities in a way that makes sense to the general community.

There are a number of competing goals for any system like this, a few of which are: privacy, anonymity, performance, cost, and ease-of-use. Maidsafe raises the bar on all of these factors, but none of them will ever be 100% and compromises must be made. It will be important to find ways to explain all of this in a simple and concise manner for end users, and provide avenues to dive deeper for those that want or need further details.

Maidsafe provides default values for these factors that are superior to our current infrastructure. However, the true power of the network is that it is built in a composable manner such that we can provide app developers with plugins and config settings to easily change the characteristics of the network.

A few examples:
Privacy is orders of magnitude higher than the current web and email infrastructure. However, in order to increase performance, decrease storage costs, and increase ease of use, it is not as secure as encrypting a file with truecrypt. Lets say you are a bank sending sensitive information through the maidsafe equivalent of email. You might want a bit more privacy than the standard self-encryption scheme and you are just sending text so storage costs are not a major concern. They could set a config setting to pre-encrypt the message with the recipients public key before it is self-encrypted. Performance and storage efficiency would be reduced, but privacy would increase.

Anonymity in the default design is a level above conventional systems, but it is not as good as Tor. If the user was willing to trade performance for added anonymity, they could use a plugin that implemented Tor-like onion routing through the maidsafe routing layer.

Performance in the default configuration will not be as good as conventional implementations for many applications. Over time, for some use cases, optimizations and caching in the routing layer should lead to superior performance with much higher ease of use. However, there are a number of settings and plugins that could be provided to app developers to change the performance characteristics (at the cost of other functionality) while maintaining ease of use. In this way, the network designers can provide a number of different performance profiles, while ensuring other characteristics (privacy, cost, etc) remain as efficient as possible. Standardized permissions and alerts could be devised to inform the user about the tradeoffs an application is making with their privacy/anonymity.

As @benjaminbollen described, one example would be to allow known nodes to be added to the routing table to make video conferencing more performant.

Once distributed computing is implemented, games might want a number of different options.
Lets take a FPS for example. A dozen users need to connect to a single orchestration server. Performance and cost are primary concerns, privacy and anonymity don’t matter as much. None of the players care if there is a slight chance that the server will cheat or go down in the middle of the match.
The application defines the minimum requirements for the server, including a network rating. A farming node on the network is chosen at random that meets those requirements and the necessary RAM and CPU time is requisitioned. No consensus group is used. Each player connects to the “server” node and agrees to pay their share of the server cost for the duration of the match. The server code for the game is uploaded to the server node, each player node verifies the server code is the expected version, and the match starts.

Maybe one of the players cares more about his anonymity for whatever reason. He can choose to use the default routing scheme. He will have more lag, but he won’t be connecting directly to the server.

Lets say the match is a high stakes tournament. The players want verification against cheating. They don’t need it real-time, just a stamp of approval from the network after the match is completed. Consensus group verification is turned on and the players agree to pay the added expense. When the server node is chosen, a number of other nodes are chosen as well to form the consensus group. All communication to/from the server is forwarded on to the consensus group, who verifies the server responses are correct. If the response is incorrect, the consensus group will send and alert to the players.

Another example would be an MMORPG. In this case thousands of players need to be connected to hundreds of servers, all working together. Many real-time consensus groups might be defined to orchestrate the various aspects of the game that must be run on the network. All communication to/from each consensus group would be sent to each member concurrently, so if any single node drops off or acts incorrectly it can be replaced with no interruption. See the fictional book “Halting State” by Charles Stross for an example of what this might look like in practice.

4 Likes
13

I’m glad we have you and many others like you on board. The idea of a “pop-up server node” is a neat solution, especially in focused activities like online games MMORPG.

It is important that we are honest and try not to oversell the Network, even though we are all very passionate about its “potential.” My favorite form of marketing is word of mouth. And the best way to do that is to let the Network prove itself.

Our job as developers, builders, farmers and users is to constantly work at improving it.

14

Great post @oillio!

15

Thanks. I am glad it made sense to others.

The point I think I was trying to make (or should have been trying to make) is that the potential of Maidsafe is huge. There is really no need to oversell it. There are warts and issues, and there is still oh so much work that needs done. The key, in my opinion, is to find a way to explain the system, including the massive potential, as well as the potential issues, in a way that the average “techie” can understand without needing a month to think it all through.

Normally, I would agree that we should just build killer apps on top of it and let the system speak for itself. Unfortunately, Maidsafe requires a rather large community to remain viable. I fear the window of success is far shorter than any of us would like.

3 Likes
16

I would disagree, MaidSafe uses AES256, just as TrueCrypt has AES256 in it’s encryption armoury. On top of that with MaidSafe the data is completely untraceable. In traditional cryptography you still have to worry about passing your keys to your counter party; this is not the case in MaidSafe.

17

Again, I disagree, MaidSafe is better then Tor. In Tor you can chose to have your obfuscation-route change every few days - standard setting. The Tor network still has exit and entry points and it has been proven that by closely monitoring the in- and outflow of a large number of Tor node, you can uncover many of the users and their traffic.

In Safe for every get request you do, it follows many untraceable routes WITHIN the SAFE network; ie it never leaves the SAFE network: there is no exit point to monitor. Nor is there an entry point as with self-authenticating anonymous login, you don’t know who is logging in from where in the world (excepting the four worldwide scattered NodeManagers).

18

Thanks for sharing, oillio!

One of the things I really want from MaidSafe is a Gmail replacement. But that would be a functional replacement, keeping the idea of an electronic mail and lightweight clients but completely ditching the current implementation. Once you can store files over the network, there’s no need to have emails traveling between a sending and a receiving machine, and POP, SMTP and IMAP become completely irrelevant.

And since MaidSafe’s got a PKI already, it only seems natural that everyone who has a safe-mail address also has one or several public keys attached to it. And since we have them, why not use them? Every safe-mail is encrypted with one of the receiver’s PGP keys, and is signed by the sender. This crypto layer comes on top of the vault’s security infrastructure, and offers as much security as the equivalent for email. Vault security and chunk encryption don’t matter much in this case, even if chunks are stored in plaintext, they are parts of an encrypted message anyway.

But there’s a not-so-subtle difference between safe-mail and email in this case: in safe-mail, mail encryption and signing are both automatic and mandatory. Received an unsigned mail? Dump it. Unencrypted mail? Dump it. This is mandated by the protocol. Since encryption and signing are not painful (they can both be performed by simply giving a sender address you own and giving a valid recipient address), there’s no reason not to use them, ever. Bye-bye spam, bye-bye third parties accessing your plain-text emails at will.

4 Likes
19

A derived private key will always be less secure than a randomly chosen one.
Consider the guessed plaintext attack as an example. Say Alice transmits a message to Bob using self-encryption. The message is, “Bob, this is Alice. Your account balance is currently $5,000.”
This is a standard message that Alice sends to all of her customers regularly. If Charlie can guess the exact text of the message, he can decode the message. If he knows the name of Alice and Bob, he can iterate through the possible account balance values and discover Bob’s account balance.

Plugging this hole would require disabling deduplication. As I said above, this might be useful for specific data, but should not be the default.

I don’t know how you mean self-encryption does not require key passing. This is solved through public/private keys in MaidSafe and elsewhere.

Communication entirely within the Tor network is safer than communication entirely within Mainsafe. In Tor, no intermediate node in your route can determine anything about the source, destination, or the makeup of the message. An intermediate node can only determine the source of it’s leg of the route (it cannot tell if this is the original sender or not), and it knows the next destination in the route (again, it does not know if this is the final destination). The actual message is completely encrypted.
The in/outflow attack will only allow you to potentially uncover the source and destination, not the message itself. This same class of attack is also possible in Maidsafe. It would actually be easier as you don’t actually have to analyze the in/outflow as you can already see the destination address.

In Maidsafe, all nodes within the route know the destination address and the message type. If it is a GET/PUT it knows the address of the data in the network. If the node happens to have the plaintext of the data, it will be able to determine what data is being stored or retrieved. Additionally, the first node in the route will know all the above information, as well as the source IP address for the message.

Increasing the security of the network to the level of Tor would make caching impossible; definitely not a trade we would want to make for a vast majority of communication.

These are minor vulnerabilities, and they are exposed in order to allow important functionality and to greatly increase performance. They were good trade-offs to make. As I said above, it is important to explain the concessions that were made in order to allow the network to do what it does.

1 Like