On 24 July 2013 20:01, carlo von lynX <[email protected]> wrote:
> On Mon, Jul 22, 2013 at 10:13:04PM +0200, Melvin Carvalho wrote: > > They are in the church of "your email is your identity" -- let's be clear > > this is an unnecessary restriction with will not scale. Other projects > > (not mentioning any names) *cough cough* are also in this religious sect. > > email needs to be discontinued in the long run. it doesn't serve any of > the purposes it was constructed for. it gives the attacker a full view > of the social network, a view into the content by default and it also > fails at delivering to many recipients promptly and to handle spam. > > a proper messaging system protects both content and meta data of > communications, multicasts whenever something wants to be received by > multiple recipients and sorts out spam because it is the only use > case for massive unicasting. also, key management is ridiculously > easy if it doesn't try to get along with email addresses. the key > is the identity. works great in modern systems such as tor hidden > services, retroshare etc. > Yes, but the key is not the person. The person has a key. When you overload he key and the person to mean the same thing (known as an 'indirect identifier') you have to be quite careful. The advantage of not overloading identifiers that the same identifier in one system means the same in another, which helps with inerop with other systems that might not have made the same design decisions as you. > > > > > Together with Elijah of the LEAP project we came up with this list > > > > of priorities: > > > > > > > > 1) Client side encryption > > haven't looked into it, but if there is a client i presume there is > a server so there is a server that gets to see meta data of who is > talking to whom. that means it doesn't fulfil today's requirements > for privacy. correct? > > > > *** We tend to always repeat the same: public communication does not > > > need to be encrypted, so it's a use case that should easily be agreed > > > upon. Yet, everything that is not explicitly public is, in my opinion, > > > to be private: that means, in the current context, strongly encrypted. > > > > Great point. We've not even solved the public version yet. When we do I > > suspect the encrypted version will be easy, just some shared keys and AES > > or another symmetric cypher, asymmetric PKI, or hybrid, or security by > > obscurity. I'm not a huge believe in advertising which crypto algorithms > > are being used to the whole world, that all the relevant parties know > > should be enough. > > once there is a system that can deliver public info without exposing who > is actually receiving it, there will be no need for public info to > actually be unencrypted. in other words, i am afraid you are putting > effort into something nobody will want as soon as something better is > available. there is no such thing as "public communication." even if i > subscribe to the public pirate party announcements channel, i am > exposing my political interest - thus, even the most popular twitter > content needs to be subscribeable in privacy, the delivery tree must > be invisible to outside viewers thus the content must be encrypted or > otherwise you would see how the distribution tree is architected. > > conclusion: the use case for a "public version" does not exist - at > least not from the point of view of somebody who is not going to tolerate > any further data mining on the general population - even if it is > just subscribing to sports news. this whole 1984 approach has to be > stopped without exceptions. > > > > > 8) Client choice - you should be able to use a mobile, desktop, or > > > > html5 app client (once webcrypto is deployed in browsers). > > > > > > > *** Honestly, I'm not sure that is a sane decision. Not until there > > > are some things fixed: > > > > > > - 1 TLS certification authorities (utterly broken and mostly > > > untrustable) > > > - 2 TLS perfect forward secrecy implementation everywhere (servers, > > > browsers) including protection against TLS-downgrade attacks. That's > > > mostly a matter of proper configuration though. > > > - 3 Javascript protection: Libre JS to ensure the code run on the > > > page is genuine and not malicious > > > - 4 proper protection against XSS, CSRF, and other MITM > > > > > > 3 and 4 are way out of reach at the moment. HTML5 is bringing new > > > attack vectors, and the development of the Web is going towards more > > > usage of centralized resources (+1, Like, Login with X, analytics, > > > etc.) without mentioning javascript-less CSS-based or DOM-based XSS, > > > plugin-based infection, and mobile phone network insecurity as a whole. > > i agree and i also doubt that 1 and 2 can be fixed in a way that cuts > out big brother. too many bugs on all levels. X.509 is a failure. > the only way to use web technology is to forbid it from connecting > to anywhere else but the locally running social network daemon. > > > I dont believe in trying to create perfect security, security should be > > "good enough" then you start the arms race between attackers and > > defenders. Facebook didnt even start with https remember and go to 100 > > million users. In any other project I'd be a security fundamentalist, > but > > for a social project, users count, this often seems to be > underestimated... > > the user count is irrelevant if the load is fully distributed among those > who are using it. it doesn't matter if a hundred or a billion people > participate. each time we do something "good enough" we are only behind > the attacker and not achieving our goals - because each time we find > out it wasn't good enough. we have a realistic chance to do much better > so let's not invest in anything half-baked. after all Tor just needed > to be coded, too, and it has changed the landscape of the internet. > >
