First, xmux: I want to sincerely thank you for participating in this conversation. I really respect your expertise (and your strong familiarity with a side of this debate) and I strongly hope that you will remain a contributor to this conversation. Much better than bitter tweeting!
I want to point out two things here: 1. Cryptocat's goal is to find the best balance between accessibility/usability and security. 2. Cryptocat does not mean to compete with GPG, it means to replace * plaintext.* Now, I want you to consider the following paragraph *in light of the two conditions outlined above:* I have recognized the security advantages of having a browser plugin by default, which is why if you look at the proposed new Cryptocat web splash page (http://i.imgur.com/Y56I7.png) the "web" version is only *a barely *visible option in comparison to the browser plugin. And I must stress that the web version will have a *huge* warning that cannot be hidden, in the form of a big red bar in the user's language literally beseeching them to install the local browser plugin. NK On Mon, Aug 6, 2012 at 6:08 PM, Eleanor Saitta <e...@dymaxion.org> wrote: > On 2012.08.06 17.51, Jacob Appelbaum wrote: > > Jillian C. York: > >> It's difficult. I'm not a technologist, but I understand the issues and > >> the user needs well. My "type," I'd surmise, is few and far between. > >> > >> Security experts have obvious reasons for being conservative, and I get > >> that. Nevertheless, there are a lot of users who would benefit from *a > >> little bit* of added security. The question, then, as I see it, is: > >> > >> *How do we provide that little bit while still making users aware of > risks?* > > > > The problem is that the little bit is effectively zero. > > > > What's the difference between Facebook chat over SSL and Cryptocat over > SSL? > > > > Without a browser extension/plugin - there is little to no difference. > > > > You have to trust the server and the server operator to not be a bad > > actor in both cases. > > It is true that you have to trust the server operator in both cases. > However, having a server configuration which does not completely > compromise user privacy (vs. the operator) by default, like Facebook > does, is still a significant improvement in many use cases, as is the > ability to have a diversity of server operators. > > If you insist on only permitting tools which offer a mythical "perfect" > standard of security, you ensure that many at risk users will use > plaintext tools that offer no security at all. > > Yes, it is likely that cryptocat will be broken in a non-plugin version, > and that people will die because of it. However, it is also likely that > cryptocat will save lives, vs. plaintext alternatives, and that a plugin > version of cryptocat will also be broken at some point, and that people > will die because of that. > > We need an ecosystem of tools, not a magic bullet. The Security > Community as such has done much good over the years. However, security > professionals who are unwilling to acknowledge that different users have > different needs, that online security exists within a larger > constellation of risk analysis, and that usability can and often does > trump pure security even when viewed purely through risk analysis and > outcomes are doing a grave disservice to both their field and their users. > > It has been 21 years since PGP was released. To this day, it remains a > niche product at best. Users with real world security concerns rarely > if ever use encrypted email. It is exactly this attitude which is to > blame. > > If you want to continue being irrelevant, go right ahead. The rest of > us have real world problems to solve. > > E. > > -- > Ideas are my favorite toys. > > > _______________________________________________ > liberationtech mailing list > liberationtech@lists.stanford.edu > > Should you need to change your subscription options, please go to: > > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > If you would like to receive a daily digest, click "yes" (once you click > above) next to "would you like to receive list mail batched in a daily > digest?" > > You will need the user name and password you receive from the list > moderator in monthly reminders. You may ask for a reminder here: > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > Should you need immediate assistance, please contact the list moderator. > > Please don't forget to follow us on http://twitter.com/#!/Liberationtech >
_______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
