consensus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU/consensus] [SocialSwarm-D] Consensus on the aims of this group


From: Simon Hirscher
Subject: Re: [GNU/consensus] [SocialSwarm-D] Consensus on the aims of this group
Date: Thu, 21 Nov 2013 02:08:17 +0100

On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho
<address@hidden> wrote:
>
> TLS *as an example* lets you exchange keys, and encrypt messages.  Rolled
> out to billions of users and devices.

What about MITM attacks? What about the fundamentally broken
certificate architecture? The only way I see that both issues
obviously can be solved is to solve the DNS issue right from the start
and use public keys as fundamental identifiers. Now, we're back to
Zooko's Triangle, an issue that GNS probably solves in the most
elegant way.

On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho
<address@hidden> wrote:
>
> On 20 November 2013 03:05, Simon Hirscher <address@hidden> wrote:
>>
>> On Wed, Nov 20, 2013 at 2:31 AM, Melvin Carvalho
>> <address@hidden> wrote:
>> >
>> > Why do you say no other project is working on this?  How can you even
>> > know
>> > every project out there?
>>
>> Melvin, I obviously can't know every project out there. Let's do a
>> search & replace then:
>> >> Because no one *we (or I) know of* is doing this *successfully*.
>
> These are modular components, which elements do you think are not being done
> successfully?

I said those 4 problems are not being addressed successfully *at
once*. And that's really the key to understanding why we can't just
solve these issues by mostly building upon existing technologies –
like TLS and web technologies. Because every project [again: I know
of] is just paying attention to one or, at the maximum, two of those
points and on the other hand makes it damn hard or simply impossible
to solve those other two or three issues at the same time. Yes, some
web applications might enable self-determined storage at first glance.
But, meanwhile, by running server-delivered code (which might not even
come from the server you trust – due to compromised TLS certificates)
in your browser you give up on end2end encryption. So, no, it actually
doesn't allow self-determined storage because there might be someone
else listening.

In fact, we could boil down the four requirements to just one:
Self-determined storage. This already implies end2end encryption,
perfect forward secrecy as well as social graph obfuscation because
*I* determine who gets to see my data and my messages and my buddy
lists. Now and in the future.

Hence, to wrap it all up and answer your question in the shortest way
possible: So far, there is absolutely no project that managed to
realize genuinely self-determined storage.

> Why cant this be done in a modular way with different teams working on
> different pieces and then put together.  I agree maybe not all pieces are
> perfect, but we cant some of us work on fixing the bugs working together?

See above. Also, I don't even know where to start when talking about
fixing TLS and doing web apps in a secure way. Then again, that might
be due to the fact that their design is fundamentally broken with
respect to our wishlist.

Maybe I'm all wrong – in which case I'd ask you to tell me which
building blocks you would use in our quest to fulfill those 4
requirements. At the same time, I'd ask you to explain to me why do
you think it's even possible to fix all their "bugs" (I prefer the
term "architectural flaws") all at once. In short: Give me a plan I
can believe in.

So far, however, all those solutions you proposed in your previous
email – regarding "E2E + Forward secrecy", "Social Graph Transmission"
and "Self Determined Data Storage" – aren't solutions at all. I think
Carlo really has a point here.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]