On 8/6/12 7:29 PM, Moxie Marlinspike wrote: > > On 08/06/2012 06:59 PM, Eleanor Saitta wrote: >> Except that with your harm mitigation, you push many potential users >> back to plaintext, where they are guaranteed to be owned. What >> percentage of potential cryptocat users would the plugin version have to >> stop from using the tool for you to accept that there was a place for >> the non-plugin version?
I believe pure client side web apps that deploy cryptography also have another value that is overlooked or not considered. That is that they provide a sort of plausible deniability to the operator of a such a site. The operator of such a system cannot trivially log the conversations of their users, but the are required to do an *active* attack that replaces content of the web app with malicious one. This is theoretically detectable by the client. I also don't think that there is that much value in having native crypto implementations in browsers. That really does not help security at all, it just makes things a bit more performant. What would be really nice is a way to sign javascript code that comes from website and disallow by default intag event binding (why should we still be supporting sloppy coding practices?) a-la CSP. just my 0.02€ - Art. _______________________________________________ liberationtech mailing list [email protected] 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
