Redecentralize
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.
Main Website: https://redecentralize.org
Parent
There's a "UX Hackathon" for security / privacy tools happening this weekend in San Francisco:
-jonny
I can't make it, but there may be interesting people / projects to talk to coming out of it
On Thu, Feb 27, 2014 at 12:20 PM, Francis Irving <francis@flourish.org> wrote:
Hi all!
Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
Ideas I have:
Telegram - who does design stuff there?
Brennan from Mailpile - would it be good or weird for us to have a second interview of the same project, but on a different aspect?
IndiePhoneAny other suggestions?
Francis
PS Unhosted interview to come out soon!
Hi all!
Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
Ideas I have:
Telegram - who does design stuff there?
Brennan from Mailpile - would it be good or weird for us to have a second interview of the same project, but on a different aspect?
IndiePhone
Any other suggestions?
Francis
PS Unhosted interview to come out soon!
HI Francis, you might want to interview some of the folks I work with at Loomio - an open-source platform for decentralised decision-making. We've got a focus on UX, which we treat as part of the work of all developers, not the domain of some specialist.Â
--
I can imagine a great article exploring the tension between design and democracy, exploring how open-source projects can adapt the 'visionary designer' model (e.g. Apple) to decentralised projects.
Feel free to contact me off-list if you're interested :)
Warm regards from Aotearoa New Zealand,
Rich
On 28 February 2014 09:20, Francis Irving <francis@flourish.org> wrote:
Hi all!
Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
Ideas I have:
Telegram - who does design stuff there?
Brennan from Mailpile - would it be good or weird for us to have a second interview of the same project, but on a different aspect?
IndiePhoneAny other suggestions?
Francis
PS Unhosted interview to come out soon!
Richard BartlettNot to drag this out, but would you mind posting a link to something about Telegram's travails? I'm interested.
There's the potential for a dangerous wave of slickly designed messaging apps that adopt the mantle of security without truly prioritizing it. I had a frustrating interaction with the Tox team here, for example:
https://github.com/irungentoo/ProjectTox-Core/issues/121
-- Eric
On Feb 28, 2014 6:51 AM, "Ximin Luo" <infinity0@pwned.gg> wrote:
On 27/02/14 20:20, Francis Irving wrote:
> Hi all!
>
> Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
>
> As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
>
> We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
>
> Ideas I have:
> Telegram - who does design stuff there?
For the love of god please do not give Telegram any more attention.
They are a marketing machine with no security credentials whatsoever.
They are so far up their own ass they are like a 3D projection of a klein bottle.
They ate a crap load of humble cake, perhaps it will be worth talking to them in a year or so. But not now. Give more deserving projects your attention for the time being.
X
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
I see Moxie doesn't think much of Telegram:
http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
-- Eric
On Feb 28, 2014 9:48 AM, "Eric Mill" <eric@konklone.com> wrote:
Not to drag this out, but would you mind posting a link to something about Telegram's travails? I'm interested.
There's the potential for a dangerous wave of slickly designed messaging apps that adopt the mantle of security without truly prioritizing it. I had a frustrating interaction with the Tox team here, for example:
https://github.com/irungentoo/ProjectTox-Core/issues/121
-- Eric
On Feb 28, 2014 6:51 AM, "Ximin Luo" <infinity0@pwned.gg> wrote:On 27/02/14 20:20, Francis Irving wrote:
> Hi all!
>
> Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
>
> As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
>
> We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
>
> Ideas I have:
> Telegram - who does design stuff there?
For the love of god please do not give Telegram any more attention.
They are a marketing machine with no security credentials whatsoever.
They are so far up their own ass they are like a 3D projection of a klein bottle.
They ate a crap load of humble cake, perhaps it will be worth talking to them in a year or so. But not now. Give more deserving projects your attention for the time being.
X
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
Most programmers don't realize the immense importance of user experience. It's the entire reason for Apple's success, for example... OSX was not technically superior to Linux in any way but it offers a vastly superior user experience.
I think a common and dangerous myth is that good UX is for "noobs" and "non-computer people." I've been programming since I was four and was a Linux user since 1992, but I love my Mac and I love really good user interfaces and zero-configuration apps. Why? Because I have better things to do than futz around with my computer to get it to work. I am way, way too busy for that. I *hate* things that make me climb a steep learning curve to do something trivial, or that require me to jigger with them to get them to work. I'd much rather be coding, writing, or doing things in the real world like spending time with my family.
I did sort of enjoy jiggering with things like Linux when I was learning, but that's because I was learning and learning is fun. Now that I know how to admin a machine, I don't want to do that anymore. I want to do new things.
That being said, there is often a tension between security and UX. Security is often accomplished through the erection of barriers, requiring the user to do extra steps. Good UX is often achieved through automation that involves trusting third parties or doing things the "easy" (insecure) way. But I don't think it has to be this way. In particular, I think cryptography offers many opportunities for using clever math and cryptographic transform composition to do things in a way that is both user-friendly and very secure. But it requires a deep understanding of crypto to get there.
On Feb 27, 2014, at 12:20 PM, Francis Irving <francis@flourish.org> wrote:
Hi all!
Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
Ideas I have:
Telegram - who does design stuff there?
Brennan from Mailpile - would it be good or weird for us to have a second interview of the same project, but on a different aspect?
IndiePhoneAny other suggestions?
Francis
PS Unhosted interview to come out soon!
On Feb 28, 2014, at 10:21 AM, Eric Mill <eric@konklone.com> wrote:
Also, I just found this much more detailed demonstration of how Telegram's philosophy led it to make wildly insecure architectural decisions:
That's often a pitfall of Ph.Ds. Complexity is usually bad for security. I'll give you a recent example I tangled with: Microsoft's filesystem ACL model. It takes a *page* of C++ code to lock down permissions on a file. On *nix I can do this with "chmod(file,0600);". I ended up doing it by invoking the "cacls.exe" external utility, since I just couldn't overcome my disgust at having to spend a day learning some incredibly complex APIs just to do something incredibly elementary.
I'm sure most developers don't even go that far. They just pay absolutely no attention to file permissions on Windows.
I get your point, but secure products which don't succeed at marketing are *not* "just as dangerous". Insecure but well-marketed projects are clearly more dangerous, as people put unfounded trust in them.
My main problem with the Tox team is that they said pretty much this: they'll improve security if it means not sacrificing UX. Viewing security and UX as equally important is a recipe for disaster, at users' expense.
It's natural to view them as in tension, but watching Moxie's work at Whispersystems has been an inspiring demonstration of why they don't have to be. WhisperSystems is now transparently integrated in CyanogenMod as the default SMS provider without any UX degradation, and they just moved beyond SMS to a more full-featured messaging system.
And unlike Telegram, they're doing it all as 100% open source, and even experimenting with ways of incentivizing and crowdfunding contributions.
So when I hear projects pit UX in tension with security, I hear that they don't feel like learning as much as Whispersystems has, or spending the time that they do on getting it Right.
-- Eric
On Fri, Feb 28, 2014 at 10:20 AM, Francis Irving <francis@flourish.org> wrote:
As a warning, you've got to be careful the other way...
*Just* as dangerous are cryptographically excellent products which are
hard to use and aren't marketed, therefore have no adoption.
I agree we need things which are BOTH technically sound AND have a
great user experience.
Francis
--
On Fri, Feb 28, 2014 at 09:48:38AM -0500, Eric Mill wrote:
> Not to drag this out, but would you mind posting a link to something about
> Telegram's travails? I'm interested.
>
> There's the potential for a dangerous wave of slickly designed messaging
> apps that adopt the mantle of security without truly prioritizing it. I had
> a frustrating interaction with the Tox team here, for example:
>
> https://github.com/irungentoo/ProjectTox-Core/issues/121
>
> -- Eric
> On Feb 28, 2014 6:51 AM, "Ximin Luo" <infinity0@pwned.gg> wrote:
>
> > On 27/02/14 20:20, Francis Irving wrote:
> > > Hi all!
> > >
> > > Having interviewed many geeks, I now think the limiting factor in mass
> > adoption is involvement of more design and user experience people in
> > decentralization projects.
> > >
> > > As I describe in the Gigaom article today, I also think designers are
> > quite interested in this (post Snowden), and likely there are some who need
> > good projects to help/start but don't know about this movement.
> > >
> > > We are going to try and interview more people with that kind of
> > background, who have done at least something tangible in this area.
> > >
> > > Ideas I have:
> > > Telegram - who does design stuff there?
> >
> > For the love of god please do not give Telegram any more attention.
> >
> > They are a marketing machine with no security credentials whatsoever.
> >
> > They are so far up their own ass they are like a 3D projection of a klein
> > bottle.
> >
> > They ate a crap load of humble cake, perhaps it will be worth talking to
> > them in a year or so. But not now. Give more deserving projects your
> > attention for the time being.
> >
> > X
> >
> > --
> > GPG: 4096R/1318EFAC5FBBDBCE
> > git://github.com/infinity0/pubkeys.git
> >
> >
Do *you* have an awesome idea you never quite manage to do?
http://www.awesomefoundation.org/en/chapters/liverpool/
On Fri, Feb 28, 2014 at 1:00 PM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
Most programmers don't realize the immense importance of user experience. It's the entire reason for Apple's success, for example... OSX was not technically superior to Linux in any way but it offers a vastly superior user experience.
Subjective (I find OS X a terrible user experience), but sure, for many that seems to clearly be the case.
That being said, there is often a tension between security and UX. Security is often accomplished through the erection of barriers, requiring the user to do extra steps. Good UX is often achieved through automation that involves trusting third parties or doing things the "easy" (insecure) way. But I don't think it has to be this way. In particular, I think cryptography offers many opportunities for using clever math and cryptographic transform composition to do things in a way that is both user-friendly and very secure. But it requires a deep understanding of crypto to get there.
Couldn't agree more. And as the leaders in this push the boundaries, and other people follow their lead, their ideas will hopefully trickle out more widely and become the best practices for tomorrow, that ship standard in support libs, etc.
Also, I just found this much more detailed demonstration of how Telegram's philosophy led it to make wildly insecure architectural decisions:
Â
-- Eric
On Feb 27, 2014, at 12:20 PM, Francis Irving <francis@flourish.org> wrote:Hi all!
Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
Ideas I have:
Telegram - who does design stuff there?
Brennan from Mailpile - would it be good or weird for us to have a second interview of the same project, but on a different aspect?
IndiePhoneAny other suggestions?
Francis
PS Unhosted interview to come out soon!
As a warning, you've got to be careful the other way... *Just* as dangerous are cryptographically excellent products which are hard to use and aren't marketed, therefore have no adoption. I agree we need things which are BOTH technically sound AND have a great user experience. Francis On Fri, Feb 28, 2014 at 09:48:38AM -0500, Eric Mill wrote: > Not to drag this out, but would you mind posting a link to something about > Telegram's travails? I'm interested. > > There's the potential for a dangerous wave of slickly designed messaging > apps that adopt the mantle of security without truly prioritizing it. I had > a frustrating interaction with the Tox team here, for example: > > https://github.com/irungentoo/ProjectTox-Core/issues/121 > > -- Eric > On Feb 28, 2014 6:51 AM, "Ximin Luo" <infinity0@pwned.gg> wrote: > > > On 27/02/14 20:20, Francis Irving wrote: > > > Hi all! > > > > > > Having interviewed many geeks, I now think the limiting factor in mass > > adoption is involvement of more design and user experience people in > > decentralization projects. > > > > > > As I describe in the Gigaom article today, I also think designers are > > quite interested in this (post Snowden), and likely there are some who need > > good projects to help/start but don't know about this movement. > > > > > > We are going to try and interview more people with that kind of > > background, who have done at least something tangible in this area. > > > > > > Ideas I have: > > > Telegram - who does design stuff there? > > > > For the love of god please do not give Telegram any more attention. > > > > They are a marketing machine with no security credentials whatsoever. > > > > They are so far up their own ass they are like a 3D projection of a klein > > bottle. > > > > They ate a crap load of humble cake, perhaps it will be worth talking to > > them in a year or so. But not now. Give more deserving projects your > > attention for the time being. > > > > X > > > > -- > > GPG: 4096R/1318EFAC5FBBDBCE > > git://github.com/infinity0/pubkeys.git > > > > -- Do *you* have an awesome idea you never quite manage to do? http://www.awesomefoundation.org/en/chapters/liverpool/
Plan9's papers include an overview of its security arch that's worth a read. One of their core views is that UX is a security decision, which is in keeping with a lot of what's been said in this thread.
On Feb 28, 2014, at 10:21 AM, Eric Mill <eric@konklone.com> wrote:Also, I just found this much more detailed demonstration of how Telegram's philosophy led it to make wildly insecure architectural decisions:"and they take the most complicated route for everything."That's often a pitfall of Ph.Ds. Complexity is usually bad for security. I'll give you a recent example I tangled with: Microsoft's filesystem ACL model. It takes a *page* of C++ code to lock down permissions on a file. On *nix I can do this with "chmod(file,0600);". I ended up doing it by invoking the "cacls.exe" external utility, since I just couldn't overcome my disgust at having to spend a day learning some incredibly complex APIs just to do something incredibly elementary.I'm sure most developers don't even go that far. They just pay absolutely no attention to file permissions on Windows.
Is anybody familiar with novel approaches to security UX that you might share? I'd enjoy some anecdotes about what's worked.
On Fri, Feb 28, 2014 at 4:46 PM, Ximin Luo <infinity0@pwned.gg> wrote:
Telegram's justifications for their security have basically been "prove me wrong". In fact, they have been proven wrong several times, but then they fix the specific attack and repeat the "prove me wrong" challenge. It gets tiring. Modern strong security justifications must be secure-because arguments, not lack-of-attack arguments.
They also made a big deal out of the fact that some of their team have PhDs. They weren't in computer security, though.
I do not want to present this as a "you must listen to a security professional" advice. The security community is realising more and more how elitist the traditional "don't do your own crypto" advice sounds. Rather, we would encourage people to learn security in a more precise and technical fashion, and that includes practising by implementing these things yourself.
But - don't release them, or make claims about them, until you are genuinely honestly sure (as opposed to wanting to make a quick buck) and have had it reviewed by similarly genuine and honest people. Also, even if you don't become good enough to release things for deployment, learning about these concepts from a precise and engineering viewpoint lets you see through the bullshit more effectively.
X
On 28/02/14 14:55, Eric Mill wrote:
> I see Moxie doesn't think much of Telegram:
>
> http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
>
> -- Eric
>
> On Feb 28, 2014 9:48 AM, "Eric Mill" <eric@konklone.com <mailto:eric@konklone.com>> wrote:
>
> Â Â Not to drag this out, but would you mind posting a link to something about Telegram's travails? I'm interested.
>
> Â Â There's the potential for a dangerous wave of slickly designed messaging apps that adopt the mantle of security without truly prioritizing it. I had a frustrating interaction with the Tox team here, for example:
>
> Â Â https://github.com/irungentoo/ProjectTox-Core/issues/121
>
> Â Â -- Eric
>
> Â Â On Feb 28, 2014 6:51 AM, "Ximin Luo" <infinity0@pwned.gg <mailto:infinity0@pwned.gg>> wrote:> Â Â Â Â git://github.com/infinity0/pubkeys.git <http://github.com/infinity0/pubkeys.git>
>
> Â Â Â Â On 27/02/14 20:20, Francis Irving wrote:
> Â Â Â Â > Hi all!
> Â Â Â Â >
> Â Â Â Â > Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
> Â Â Â Â >
> Â Â Â Â > As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
> Â Â Â Â >
> Â Â Â Â > We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
> Â Â Â Â >
> Â Â Â Â > Ideas I have:
> Â Â Â Â > Telegram - who does design stuff there?
>
> Â Â Â Â For the love of god please do not give Telegram any more attention.
>
> Â Â Â Â They are a marketing machine with no security credentials whatsoever.
>
> Â Â Â Â They are so far up their own ass they are like a 3D projection of a klein bottle.
>
> Â Â Â Â They ate a crap load of humble cake, perhaps it will be worth talking to them in a year or so. But not now. Give more deserving projects your attention for the time being.
>
> Â Â Â Â X
>
> Â Â Â Â --
> Â Â Â Â GPG: 4096R/1318EFAC5FBBDBCE
Hi,
The problem between security and UX often bogs down to the approach in development. Crypto apps have a bottom up approach: we have a crypto protocol, let's build a UI around. That's what we saw with GPG, client cert authentication, etc.Also, we need clear definitions of what a protocol can and cannot do. there are a lot of wonderful crypto primitives that could be exploited if people knew about it, instead of writing yet another broken scheme with RSA and AES.
On Fri, Feb 28, 2014 at 7:00 PM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
Most programmers don't realize the immense importance of user experience. It's the entire reason for Apple's success, for example... OSX was not technically superior to Linux in any way but it offers a vastly superior user experience.I think a common and dangerous myth is that good UX is for "noobs" and "non-computer people." I've been programming since I was four and was a Linux user since 1992, but I love my Mac and I love really good user interfaces and zero-configuration apps. Why? Because I have better things to do than futz around with my computer to get it to work. I am way, way too busy for that. I *hate* things that make me climb a steep learning curve to do something trivial, or that require me to jigger with them to get them to work. I'd much rather be coding, writin g, or doing things in the real world like spending time with my family.I did sort of enjoy jiggering with things like Linux when I was learning, but that's because I was learning and learning is fun. Now that I know how to admin a machine, I don't want to do that anymore. I want to do new things.That being said, there is often a tension between security and UX. Security is often accomplished through the erection of barriers, requiring the user to do extra steps. Good UX is often achieved through automation that involves trusting third parties or doing things the "easy" (insecure) way. But I don't think it has to be this way. In particular, I think cryptography offers many opportunities for using clever math and cryptographic transform composition to do things in a way that is both user-friendly and very secure. But it requires a deep understanding of crypto to get there.On Feb 27, 2014, at 12:20 PM, Francis Irving <francis@flourish.org> wrote:Hi all!
Having interviewed many geeks, I now think the limiting factor in mass adoption is involvement of more design and user experience people in decentralization projects.
As I describe in the Gigaom article today, I also think designers are quite interested in this (post Snowden), and likely there are some who need good projects to help/start but don't know about this movement.
We are going to try and interview more people with that kind of background, who have done at least something tangible in this area.
Ideas I have:
Telegram - who does design stuff there?
Brennan from Mailpile - would it be good or weird for us to have a second interview of the same project, but on a different aspect?
IndiePhoneAny other suggestions?
Francis
PS Unhosted interview to come out soon!
--
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:
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.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.
Regarding Efficient non-TTP protocols: Which purpose do you have in mind?Well, it's true that the criterion of being in-corruptible is not widely known today.
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.
But I can't see this as a reason why we should ignore it.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?
It sounds like you are doing your own research into the field, and ignoring the previous few decades of research.
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?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.
This is not a good idea, it will result in a highly insecure product.
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.Ups? Whom are you talking to or about?
But people have told you this before, and you keep ignoring this advice,
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?Best Regards
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.
/Jörg
For your pleasure an anecdote...
Am 01.03.2014 00:53, schrieb Paul Frazee:
Am 01.03.2014 00:53, schrieb Paul Frazee:
Is anybody familiar with novel approaches to security UX that you might share? I'd enjoy some anecdotes about what's worked.
On Fri, Feb 28, 2014 at 4:46 PM, Ximin Luo <infinity0@pwned.gg> wrote:
Telegram's justifications for their security have basically been "prove me wrong". In fact, they have been proven
First let me say: it depends a lot of you definition of "worked"; this is how it worked out, even though not always as intended:
In contrast to the mentioned "proof me wrong" attitude, out project began with the proof a security property. We then built a system, which abides the a rule set we could proof secure. Let me share the surprise what happened once we had users...
The problem we tackled relates to permission delegation. Easy to see: any system having an administrative super user is prone to corruption. The administrator can easily impersonate any user. No matter how much crypto you add, a chance is left where you must trust your admin. So the first "interesting" result: an incorruptible system has pair-wise symmetric permissions initially. (Independent of how permissions are represented) Next: we know there are inalienable rights in real world. To be able to model those correctly we must proof that no operation is be able to transfer _all_ those permissions away from a owner.
That's it already: any system which allows wholesale (or transitive) permission transfer is corruptible. Even if we do not yet know how to exploit the vulnerability. (Most databases document how the admin can set up another admin account. That's precisely what must be proofed to be impossible. Another example would be X509 sub-certificate authorities. The criterion of being "in-corruptible" would simply forbid sub-CA's. Period.)
Left with little choice of existing system, we build our own, where permission delegation would always transfer at most a strict subset of the permissions a user already has.
First we met skeptics who simply claimed that "such a system will never work" and "the administrator is there for a reason". Those we could silence by demonstrating that the implementation is at least usable.
Then we added "users": programmers & students. We wanted them to be creative. Build some applications atop. Make the step from "technically usable" to "usable by end users" (those who we don't want to bother with any proof, even when the math is simple enough to be understood by an 8th grade).
First surprise: after setting up their development environment, they forgot about permission handling to the extend that they never thought about adding a real user interface at all. For years that is. Once done right it worked for them.
Second surprise: a manager (from a partner company) was enthusiastic in the beginning about having a system which can ensure absence of impersonation. After all that's the foundation for both individual responsibility and freedom. Once there where some application prototypes built, the manager learned that such apps leave little room to exert coercing power over users. So he had the programmers build backdoors into the users apps. No he could still not break the permission control. But he could circumvent it using broken apps. (Until the first source code audit at least. But that would presumable be years in the future.)
Moral of the story: the well know problem with the strength chains and their weakest links.
Best Regards
/Jörg
----
askemos.org - A S(ch)KEMatic Operating System
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
/Jörg
On Fri, Feb 28, 2014 at 07:33:08PM +0100, Geoffroy Couprie wrote: > We need more crypto wrappers to provide usable APIs (good algorithms > default, sane use of RNG, etc) with clearly defined boundaries (embedding > the protocol's state machine instead of asking the developer to write it) > and good abstractions (the developer should not have to worry about > repeating IVs or verifying a MAC). I see that approach in NaCl or the new > Python cryptography project. It takes time to write those abstractions, but > it is rewarding. Meant to ask, what "new Python cryptography project" are you referring to? Thanks! Francis
Re: [redecentralize] Spring of User Experience 2014-03-05 18:02:48 (6 years 11 mons 29 days 20:16:00 ago)
On Wed, Mar 5, 2014 at 11:55 AM, Francis Irving <francis@flourish.org> wrote:
On Fri, Feb 28, 2014 at 07:33:08PM +0100, Geoffroy Couprie wrote:Meant to ask, what "new Python cryptography project" are you referring
> We need more crypto wrappers to provide usable APIs (good algorithms
> default, sane use of  RNG, etc) with clearly defined boundaries (embedding
> the protocol's state machine instead of asking the developer to write it)
> and good abstractions (the developer should not have to worry about
> repeating IVs or verifying a MAC). I see that approach in NaCl or the new
> Python cryptography project. It takes time to write those abstractions, but
> it is rewarding.
to?
Â
This one: https://cryptography.io/
--