On Tue, Oct 9, 2012 at 2:24 PM, Jacob Appelbaum <[email protected]> wrote: > This is an interesting observation - it is a self-selecting user base - > it is easy to use as long as you know 0) how to make a bootable disk, 1) > you know how to decide if your computer supports it, 2) it does support > and it all loads properly and 3) everyone you care to communicate with > also fits that model. > > We have seen with Tails that the 0-2 is rare except in groups where 3) > is really very solidly true.
I tend to think that locating appropriate technical solutions and absorbing the required educational materials is a responsibility of the userbase. Once someone is willing to actually extend the effort (which is a non-trivial assumption, as there is no shortage of people who expect to be babysitted after professing lack of relevant knowledge), and as long as the tasks to be performed are relatively simple, there is no shortage of detailed guides, especially in communities that recognize the need for anonymity, for instance. Moreover, simple tasks tend to become simpler with time. E.g., taking the bootable disk example, the task is often problematic for non-experienced users, as many things can go wrong during the process of making the media actually bootable. With UEFI, however (despite the frequent FUD), everything becomes simpler — the user only needs to extract a .zip archive into the USB key root. > I personally think the cables design in Liberté is really quite > interesting. If it was possible for Tails to support it and for other > chat programs to support it as well, I think we could shift the burden > presented above and it would help to attract a different user base. I would certainly like to see cables used in many different contexts. I intend to eventually transform the MUA side interface to SMTP, and rewrite remaining shell scripts in C, in order to make integration in other projects easier, including non-Linux environments (the interface right now is a script, sudo-invoked if one desires a separate cables account, that accepts the message on stdin). > Then there is stuff like NameCoin and other designs. Ultimately, I think > we agree that no solution is worth the security trade offs as of yet. I > think it isn't a totally lost cause for private groups that run their > own servers or some kind of TOFU bootstrapping model. I agree that there is currently no good option for recognizable names. I dislike BitCoin-like designs, because they are heavy (in the sense of requiring continuous waste of resources just to maintain the system), and are cumbersome to use. I.e., imagine a new user who has just installed an anonymous communication package, and who then discovers that in order to get a short alias they need to either buy some expensive mining hardware, or to spend some potentially traceable virtual currency. Even Google's method of relying on a scarce resource during registration (access to a phone number) starts to look better, especially if you are in a country where cellular phone companies didn't yet manage to form a cartel, and where buying a SIM card without tying it to a government ID is not hard (e.g., I think that in Russia one can buy a SIM card with quite a few minutes on it from dealers on the street for ~5 USD in cash). > Imagine an OTR extension that allows you to pass your .onion address > over an authenticated jabber/aim/whatever session - now you can meet > again on a decentralized system. You'll also already have the > username/alias/realname in the chat client, I think. That would be great, although I think that the extension should explicitly require authentication of the contact, which is currently optional, as far as I remember. > Another useful thing is a dynamic, cryptographically secured but time > limited, federated meeting protocol. I've been working on such a > protocol and I hope to finish it before the end of the year. If you'd > like to talk about it, I bet we could put it and cables together for > something quite usable. Sure, I would be glad to collaborate — feel free to ping me once you want to discuss further, or get feedback on the design. > Solving the problems presented are pretty easy - if users explicitly > want security *and* another goal - such as an easy to remember name - > they must understand that currently, we have no way to satisfy both > safely. Users can't always get what they want but perhaps there are > better ways to communicate that issue? I think that one of the underlying complexities here is that while users are in general aware of the concept of security-usability tradeoff, they generally incorrectly estimate where they should place themselves on the tradeoff axis. E.g., a political activist in the US is often fully aware of state surveillance capabilities, expects all his communications to be inspected, is (relatively) technically educated, and will attempt to use top-of-the-line technology and software to protect himself from black helicopters. However, the most he can expect (unless doing something explicitly illegal) is some harassment at the border. A political activist in UAE (taking a recent example posted on this mailing list) knows that his country is incapable of sophisticated US-style mass surveillance, and does not pay too much attention to computer security, besides some simple guidelines. Then, his country deploys the most sophisticated individual surveillance technology money can buy against him, and he is beaten and/or killed after being confirmed as a danger to the regime. Maybe if he knew this could happen, he wouldn't use regular non-authenticated and non-encrypted email at all? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
