@ Luke Maciak: Sure, I get your point and I agree.

Then maybe another thing as an improvement: handle the paper clip, so that if you have a key into your clipboard, it can extract it automatically and use it as the pre-filled public key :-)

@ xgbi:

I definitely could but… Well, we get back to the key management issue. I really like the idea of “TEMPORARY” public keys. You generate them as needed, and discard them just as fast. That’s why the app has a huge button that allows the user to do just that – generate a new key. I want them to hit it every once in a while. I would prefer users to think of these keys as “random passwords” tied to specific email/file rather than an encryption key associated with a person. People already know how to use passwords fairly well.

I have worked with end users in the past and I noticed that the file system is scary for many people. I had many users who would live in Outlook. They use it like a version control repository / filing cabinet. Shuffling through email is not an issue to them – getting out of the email and into the file system is an inconvenience. Which is why I actually want to implement drag/drop functionality for the encryption/decryption part. It would be nice if they could just drag the outlook attachment onto this tool.

I could add a key management feature, but by design the keys will become stale and out of date quickly. Not to mention the additional hassle of naming the keys properly.

You could also provide a very simple way to keep the already used public keys for encryption in memory/a file, with the ability to give it a name (kinda like a key store, or an address book…), so that the user can reuse a public key he already used without shuffling through his emails.

Chris Wellons wrote:

One suggestion I’d make, since you’re really trying to create this for the most novice of users, is to cut down on the wordiness even more. If it’s more than about five words, no one will read any of it.

Yes. Good point. Brevity is king. I often forget that. :)Chris Wellons wrote:

But for all the emphasis on security, asking the user to go download this new program and execute it sounds out of place! :-) How much does this other user trust you? In your phone conversation it seemed you know each other fairly well. But do you want this person to so unquestioningly execute some strange software just because someone told them to over the phone?

Well, I didn’t really think about that. My approach was more along the lines of: here is a problem, let me throw some code at it. :)

Chris Wellons wrote:

I wonder how hard it would be to implement this as a JavaScript web application that runs client-side-only inside the browser. Then the user wouldn’t have to execute potentially untrusted code with normal permissions. But it seems it would put a limit on the size of the file being encrypted — whatever amount of memory the browser supplies to JavaScript — and there would also be clipboard interaction problems: you couldn’t make a convenient “Copy to Clipboard” button like your program currently has.

Ah, but then there is another problem: do you trust the server where the script is hosted. It could always be uploading your file silently to the server while it is encrypting and a regular user would be none the wiser.

I guess with any encryption scenario you will always have a trust issue coming into play.

Oh, and thank you for the OTR link!!

@ road:

Yes… But this is still slow, error prone and requires synchronous communication over the phone. Not to mention that the phone conversation could be intercepted too – although at this point we are entering a tin-foil hat territory. Public key solution however is completely asynchronous, and is not vulnerable to eavesdropping.

@ MrJones2015:

You could. It depends on the circumstances. Some companies have very strict rules about this and you can get in trouble for sending passwords and/or confidential data in plaintext.

@ MrPete:

That’s actually exactly why I chose it. :) Not to hijack the thread, but what do you play?

I used to do a lot of Warhammer FRP and Star Wars D6. I also did some Mutant Chronicles, Vampire Masquerade and Space Master. :)

Hrhr, “MyTPK” made me smile.
The idea is nice and the way you created the program is really great!
Simple, elegant, easy enough to understand that there shouldn’t be many problems.
But the name -for me as a long-term-roleplayer- is just the best.
TPK is roleplayerish short for Total Party Kill :)

Or you jst send it in plain text, i mean what are the chances? This is not Volkswagen

pilots also solved this problem a long time ago:

http://www.aopa.org/letsgoflying/dream/takeflight/0901alphabet.html

This is an interesting problem. I think it’s related, or at least similar, to the problem of file transfer across the Internet (I think you wrote about this once, but I can’t find it right now). The layman’s computer setup isn’t configured for easily sending data directly to another party across the Internet. Windows doesn’t come with HTTP, FTP, or SSH servers. In the same way, it doesn’t come equipped with any encryption software, so the use of encryption involves the large overhead of obtaining, installing, and operating some additional piece of software.

This isn’t a problem I run into personally anymore. Ever since I did some convincing of family members and friends a couple years ago, 99% of my IM conversations are encrypted with Off-the-record (OTR), so any sort of password sharing, or other confidential info, can be handled over that existing channel. Also, half of the people I would call my friends know how to make use of GPG and maintain their own public keys — not that they get used much, because OTR has proven to be so useful.

In fact, just over this last weekend I wanted to give a friend SSH access to one of my servers. Passwords weren’t mentioned at all: he sent me his public SSH key (id_rsa.pub), I made a new unix account, dropped the key in ~/.ssh, and told him to go ahead and log in.

At work some of us make pretty heavy use of our public key infrastructure. They’ve implemented it fairly well, too. Everyone has a public/private keypair. Before the certificate authority will sign off on a new keypair, the owner of the key has to arrive in person at the IT office to attest the identity of the key. I personally go the extra step and sign all my outgoing e-mail. I do this both because it’s fun and because it makes people less likely to reply to my email (replying usually means more work for me!). Why is that? Outlook tries to force the reply to be signed, refusing to send otherwise. This means the sender has to type in their long passphrase, which may have even expired from disuse. That’s just enough to discourage many replies. :-D You can tell Outlook to not sign the e-mail, but few know how to do this, especially the ones that already struggle with key management.

Your project is an interesting idea, and I think it could see it being useful in certain situations, like the one you described. Seeing your screenshots makes me want to try my own hand at making one! One suggestion I’d make, since you’re really trying to create this for the most novice of users, is to cut down on the wordiness even more. If it’s more than about five words, no one will read any of it.

For example, in “Step 2” on the send screen, you have, “Pick a file to send to your friend. You can only pick one at a time.” I’d make one single bold sentence with something like, “Pick one file to send.” More information can be added in a non-bold in case it’s needed, but it will be unemphasized as to be non-distracting.

But for all the emphasis on security, asking the user to go download this new program and execute it sounds out of place! :-) How much does this other user trust you? In your phone conversation it seemed you know each other fairly well. But do you want this person to so unquestioningly execute some strange software just because someone told them to over the phone?

I wonder how hard it would be to implement this as a JavaScript web application that runs client-side-only inside the browser. Then the user wouldn’t have to execute potentially untrusted code with normal permissions. But it seems it would put a limit on the size of the file being encrypted — whatever amount of memory the browser supplies to JavaScript — and there would also be clipboard interaction problems: you couldn’t make a convenient “Copy to Clipboard” button like your program currently has.

Anyway, I look forward to your follow-up post.

IceBrain wrote:

You wrote down a password? Heresy!

Yes, I know… I figure it’s ok for temporary passwords that will get discarded/changed in a day or two. This one was a password for a temporary test user on one of the machines.

IceBrain wrote:

I would probably try to “hide” the key from the user, by letting him/her send it directly to a email address from the app itself as an attachment, and then the recipient would load the file.

Sounds like a good idea. On the other hand I’m a bit concerned it will involve too many extra steps… Like save the file to disk, load the key, load the file, etc…

I’m figuring that copying and pasting is fairly easy and if I remember to trim the leading and trailing whitespace most users should be able to do it without messing up. I guess I will have to test this on some users and see which method tracks better with the clueless.

@ Eric:

I was about to say the same thing. It would be trivial for them to envelop your data in SSL but you still could not be sure that your data can’t be intercepted or logged by someone with access to your IM providers servers. I mean, you can trust your IM provider but if you are a company, this is a bit more complicated.

This is also the reason why we are not allowed to roll out Mozy on the laptops for remote workers even though it would make backups so easy. I pitched it to the powers that be and they shot me down as soon as I said “the data would be encrypted and stored on their servers”.

I vaguely recall trying to set up a encryption cert for AIM back in the day, so I’m thinking it used to support some third party encryption. Maybe I was using Pidgin though. But yeah – it involved work up front to set it up.

@ IceBrain:
I think the encryption should come from a third party. So you can be sure that the private date can’t be tapped into by the transportation provider.