Re: [GNU/consensus] [SocialSwarm-D] Fwd: FYI: Securing the Future of the Social Web with Open Standards

[carlo von lynX]

On Thu, Jul 25, 2013 at 02:08:27AM -0700, elijah wrote:
> Again, a straw man argument. yes, x.509 is a failure, but there are
> other ways to perform key validation. I gave you two: DANE and Nicknym
> (https://leap.se/nicknym)

think of your grandma. she unpacks her brand new computer with
a free operating system on it. she clicks on "send a message"
and the software asks her to insert the identifier for her son.
typing address@hidden may be slightly easier than inserting
7yuogiqxgrak36kk, but it is harder than holding his business
card in front of the webcam or typing in what they agreed upon
(some keyboards have a very nasty place for the @ sign ;)).

but the real problem is different: once she starts using her
brand new computer, the communications software generates a key
pair for her. will she go to some israeli authority and get
herself a certificate? will she do it each year? no

so how can the son be sure who is calling? he can trust the
combination of TOFU, perspective and provider keys. uhm, well -
noone has talked to his grandma yet, so perspective is out.
provider keys, which seems to be a WOT-based certification
structure, isn't useful either (not talking about exposing
your interest for a certain public key to some external
authorities...). so the only thing remaining is TOFU:
trust on first use.

in practice he has no other choice than to call her up on
the phone and ask her to click on some menu items and have
her read the public key hash to him. or he just doesn't
care and just deals with it if there's a man in the middle.

under these circumstances i think 7yuogiqxgrak36kk is easier
to handle, or one of the other ways for true end to end
safety. how much do i get for this free review of the
usefulness of the LEAP strategy? is see in the document that
you know how to criticize DANE yourself, so i won't bother.
whereas the criticism on shared secret is rather lame.
it's enough to apply some normalization to the user string
to avoid such problems.

so, not only i disproved your accusation of having provided
a straw man argument.. according to
    http://www.wisegeek.org/what-is-a-straw-man-argument.htm
that was a wrong assertion in the first place: i didn't look
at any argumentation of yours before you proposed it, so i
couldn't have made a straw man argument against it.

i just stated what my current knowledge is, and you have
unvoluntarily reconfirmed it.

> > even if you starttls, you are still making direct links from sending to
> > receiving server. there are two bugs here: (1) the path and meta data is
> > exposed, (2) servers get to have an important role which is bad because
> > servers are prone to prism contracts.
> 
> I am beginning to suspect you are just trolling me now. Obviously,
> starttls alone does not solve these problems, that is why I said the
> solution requires opportunistic encryption of content and meta-data
> resistant routing.

i hadn't read point (3) yet when i wrote that. starttls is just less
efficient than having an encrypted protocol rightaway, but other than
that the problem with it is rather in the server-oriented architecture
of smtp which is inherently prismable. from amsterdam you should know
that i don't troll you (what for?), but i may misinterpret you as it
has happened before.

> > as long as it is backwards compatible to plain old unencrypted email
> > we are unnecessarily risking downgrade attacks. also we are exposing
> > our new safe mail system to st00pid spam problems of the past.
> 
> No and no. There are lots of ways to prevent downgrade attacks and lots
> of ways to prevent spam.

so you expect all nodes to be properly configured against downgrade
attacks. great. and you filter spam because it's the only unencrypted
content left?  :)

> > well, email is getting replaced today - and i
> > don't want to be on the side of the ones getting replaced.
> 
> email usage is a lower percentage of messages, but absolute email
> traffic is still growing. email is not going away for a very long time.

as long as the internet is growing as such. still even old netheads
catch themselves typing an old friend's name in facebook rather
than to dig out her email address.. and then you get to see the
photo of her as you type.. email can't beat that.

> > fine, but the federated client/server architecture is unnecessary and
> > servers are always prone to getting tapped. if you make servers
> > sufficiently dumb then they're essentially just some more nodes in
> > the network and there is no technical reason to distinguish clients
> > and servers much.
> 
> another way of saying this is that successful peer-to-peer networks
> follow a power law distribution and effectively look much like a
> federated architecture except with no one responsible for keeping the
> lights on and with really poor support for mobile devices and devices
> with intermittent network access.
> 
> so, yes, my goal is federated client/server where the servers are dumb.
> by doing this we gain a lot, including organizations responsible for
> maintain the health of the network, data availability and backup for
> users, and high functionality on devices on bad networks or limited
> battery, and (most importantly) the potential for more human friendly
> secure identity.

no, not federated. federated means people have a fix home address and
the network is to a large extent static. there can still be people
responsible for keeping the lights on. in secushare running a node
serves the people in your social neighborhood the most, so there is
a motivation to run one on a server, too. i know that's different
from your average p2p thing. so the criticism that still goes is mobile
use. well, we want privacy. if the thing is usable from a device you
do not own, you don't have that privacy. so first thing you do is
install a proper free operating system with a proper onion router
preinstalled. then it can send and receive messages and still choose
to participate in the network in a way that is battery and bandwidth
friendly. it doesn't mean you have to have a client-server role model.

> I suspect you will continue to claim, as you have many times in the
> past, that federated models are inherently insecure. There is simply no
> basis for this claim, and the more you make it the less credible you
> seem. So, please stop making this claim. We both share the same long
> term goal, and we both think that eventually peer to peer architectures
> will get us there. We disagree on the schedule, in that I think
> federated approaches are better for the immediate future and you think
> peer-to-peer approaches are the only way.

well, maybe you have changed the definition of federation so much that
the criticism no longer applies? if federation means that your client
has a home server where the social graph resides then you can do all
the cryptography you want - you HAVE exposed meta data to such a server
and servers are no longer safe.

so here is the basis for that claim. do you have any argumentation
against it? feel free to also criticize http://secushare.org/federation

> Fine, reasonable people can disagree, but there are real trade offs to
> each approach [1], and by refusing to acknowledge the trade offs you are
> making you do a disservice to the cause we share.

that much can't be denied. but i think my trade-off is in line with
what RMS would expect: you can only run a proper secure communications
system if you have a free operating system installed on it. luckily
even iPhones can be reprogrammed with a free version of android, i was
told - so we can make it - we can achieve a revolution of privacy by
reflashing all of our devices worldwide. guess it's worth it. once we
do so, there is no reason to take half measures about the rest of the
architecture.

> [1] https://leap.se/en/infosec

ah great page.. i love cryptocat right next to skype!

let's extent the tables by "P2P/F2F hybrid" which is something between
Tor and Retroshare.. or GNUnet combined with PSYC.. the column is
just like "peer to peer" except for...

Availability.. higher than high, because more than one node keeps the
pending messages for you - which is technically better than a "home
server" in federation thinking.. also consider that "server"-like nodes
are incentivated so it isn't just nodes on some laptops.

Identity Security.. is solved better, thanks to the 3 approaches.
so Authenticity and Unmappability are high and Usability is medium -
since you still have to do a minimum effort for it - like printing
business cards. but i am glad you added Unmappability to the list
of priorities since last time we met...  ;)  what is the reason
why you believe LEAP has better Unmappability than generic P2P?
i talked of "social neighborhood" before, but i don't mean connecting
directly your friends as Retroshare seems to still be doing.

btw, gnunet is a really bad example for your P2P scores since it
comes with QR business cards, F2F mode, GADS and other things you
probably didn't take in consideration.

concerning User Freedom, Control can be the highest because only the
intended recipients get *any* data - and if they participate in a
distribution tree for your tweets they may not even see who else is
in that tree (you can decide if the member list is viewable).
in federation approaches at least the home server needs to know
where to send stuff to, right?

Usability.. Tor is indeed difficult to use in a way that you don't
expose your identity.. but that's because the web is in the ballgame.
approaches like Retroshare or ours require you to actually write a
custom broken version of the software to damage yourself and others.
what other potential problem where you thinking of?

"Compatibility: None" - lol. actually since all data is on your own
hard disk i think you have never been so in control of it and you
can use any damn editor, file manager or photo manipulation software
which is on your computer to interact with it - so from my perspective
compatibility has never been so high. But of course you were intending
the ability to also upload the stuff to facebook and diaspora - well,
it can be done, no sweat. wouldn't be surprised if Retroshare already
has a plug-in for posting stuff to traditional surveilled social
networks. oh, you meant federated social web protocol standards? well,
excuse me if i dare say so, but 99.999% of users out there wouldn't
give a $*.

in other words your assertion that "reasonable people may disagree"
and "adjust one or two cells" is either quite inaccurate or i must
deduce that i am very unreasonable...  :-D