We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.


Eric Mill [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-03 12:22:12 (7 years 1 mon 9 days 04:30:00 ago)
No need to fight - Ximin read your email too quickly (though FWIW, for some reason I also initially assumed you were a Telegram developer - probably because you said "our project" without a name), and you were just describing something that happened to you.

Generally speaking, Telegram's problem is the same as Tox's is the same as many humans -- personal defensiveness. I'm not sure how to solve that, but working in public and operating openly are great starts.

On Mon, Mar 3, 2014 at 10:07 AM, Jörg F. Wittenberger <Joerg.Wittenberger@softeyes.net> wrote:
Am 03.03.2014 15:06, schrieb Ximin Luo:
On 03/03/14 13:29, Jörg F. Wittenberger wrote:
No matter how much crypto you add, a chance is left where you must trust your admin.

It's a fundamental theorem of cryptography that "trusted third parties" are never necessary in any protocol. The difficult question is to build non-TTP protocols that are *efficient*. This is beyond my knowledge to prove, but it's out there if you do the research. Try the Cryptography I course by Dan Boneh on coursera, it's pretty accessible to anyone with a moderate (ugrad) maths background, and is a good introduction to these topics.

I'm not talking about cryptographic _protocols_ at all.  I'm talking about the hardware you're using.  If you have some hardware and there is some administrator and the admin is not you, then your admin is a trusted third party to you.

Regarding Efficient non-TTP protocols: Which purpose do you have in mind?

The rest of your email, was uncorrelated snippets of security-sounding concepts, that don't have much connection to the field as it exists today.

Well, it's true that the criterion of being in-corruptible is not widely known today.

But I can't see this as a reason why we should ignore it.

It sounds like you are doing your own research into the field, and ignoring the previous few decades of research.

I just wanted to share the anecdote. Yes, it's originally based on our own research.  Though as a scientist, that's probably my job, isn't it?

Sorry, the anecdote itself left our the actual research entirely.  You can find it on the web site.  No, we did certainly not ignore existing research.

Also: by inviting getting academic researchers, students, lawyers etc. to provide reviews, applications and their legal opinion (in addition to the peer-review of the original publication) we hoped to foster confidence that we did not miss anything important.  But still that's the normal course of affairs in science, isn't it?

This is not a good idea, it will result in a highly insecure product.

I'll certainly NOT invite you to find a hack or anything into the software we wrote as a proof of anything. That would be pseudo-scientific and no proof at all.  After all we might have a bug there anyway.

You are however welcome to review the concept.  If you find any flaw please publish and inform us.  If you don't find any, I hope you might find the results useful for you.

You are also invited to hack around in the software.  If you find bugs or security vulnerabilities please report.

We also need some good coders.  E.g. we'd like to have alternatives the SSL layer (currently using either openssl or gnutls).  GNUnet and NaCl are currently our favorites.  But there's no decision yet.

But people have told you this before, and you keep ignoring this advice,

Ups?  Whom are you talking to or about?

So far I can't remember that anybody has seen a reason to tell me so.  To the contrary, so far all reviews where positive.  Maybe you intended to reply write this to somebody else?

 so I don't want to waste any more of my own time. This is mostly a warning to the others on this mailing list.

Best Regards