On 8/7/12 3:30 PM, Tom Ritter wrote:
Yes, yes, yes. There is a *tremendous* amount of implicit and
unmentioned TRUST in the person operating the service or relying on
the software. That's why anyone would use RedPhone, TextSecure or
WhisperCore back when it was closed source. Because people *trusted*
Moxie.
I was writing a response when i read you email explaining the same
concept about the TRUST.
I 100% subscribe your point, and would like to add something about
"average users and trusts".
The average user (a very stupid, dumb user but with very strong
political commitment in freedom fighting) will always trust the website
/ operator.
We CANNOT FIX that problem in any technical/cryptographic way.
That kind of user will do whatever the "server operator"/"website" will
tell/ask him to do.
If the "server operator" will tell that kind of user :
"Hey, install this plug-in, because it's much more
secure"
then the users will click to install the plug-in.
Now the user fully delegate his trust to the operator that delivered him
a backdoored plugin.
So it's a chicken-egg problem, you cannot just fix from technical point
of view.
We can only have good practice, making whatever is possible, communicate
the risks in a clear way, teach people to be more aware and pay
attention to various risks.
But imho we cannot technically fix that problem.
For that reason there is a ticket about creating "Portable CryptoCat
Servers", that can be easily installed on Desktop computers, so that
"group of people with relative trust among them" will be able to use
their own servers on Tor Hidden Services (or via Tor2web)
https://github.com/kaepora/cryptocat/issues/81 .
With many CryptoCat servers working within an XMPP Federated approach,
with Riseup having it's own CryptoCat installation, but also a a small
activist group with their own CryptoCat installation, all of them
standalone or federated.
I like to see CryptoCat security in that context of
setup/operations/distribution, with *partially delegated* trust to the
server operator (that it's better than *fully delegated trust* to server
operator)
-naif
_______________________________________________
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
