Archive for August, 2008

Archive for August, 2008

PGP UI Suggestions

Posted on

Lets face it: currently, PGP is hard.  Most geeks even consider it “geeks only”.  While few average users can benefit from encryption (few people say things that secret) – everyone can benefit from signed authenticity (at very least to cut down on spoofing).  The biggest obstacles to end users are (a) they don’t see the point (b) they freak out when they see “weird” inline content or attachments (c) verifying long hexadecimal signatures is hard.  I will make suggestions about these is order.

The fact that users don’t see the point really is the biggest problem.  If more users cared about authenticity, more would be willing to endure the pain of doing things “right”.  My hope here is that if seamless enough solutions become common enough, some people will use it because it is “right there” and as more people they know are sending signed messages perhaps some network effect can be leveraged.

Weird content is on it’s way to being fixed.  If everyone installs FireGPG and uses a mail client (/webmail supported by FireGPG) that supports PGP (a growing number) then at the very least, the noise gets hidden behind a “this message is signed” notice.

Few people want to read off long hex number to each other in person.  Here’s where it gets touchy, because anything we change here changes the security of the transaction.  I’m ok with that.  I’d rather my non-geek friends have a somewhat-trusted key than an untrusted key or no key at all.  My geek friends and I will still verify each others’ fingerprints.

Alice receives an email from Bob, with whom she has never previously shared cryptographic information.  Neither Alice nor Bob is a geek, tech savvy, or familiar with cryptography.  Alice knows her email program has a new feature that lets people verify each others’ messages and decides to try it out.

Alice elects to share her PGP key with Bob.

Alice has never shared her key with anyone before (she doesn’t have one).  She is told this and asked to wait while “some setup occurs”.  The key is generated and UI moves to the next step.  Somewhere in here there should be a notice to backup the key, “since if you lose it you can no longer send verified messages”. Public keys should be sent to a public key server automatically.

Alice secures her key to Bob.

Alice now picks a secure question and answer to prove to Bob (within a reasonable, but not cryptographically rigorous) measure of certainty.  An email is sent to Bob’s address with the output of `gpg -a –openpgp –export KEYID | gpg -ac –openpgp -` attached.  Also attached, it sends an unencrypted export of the public key, for use (moot in this case, on a new key) if this key has been signed by others Bob knows.  That is, Alice’s public key is symmetrically encrypted with an algoritm allowed by the OpenPGP standard (currently 3DES) with the passphrase as the answer to the secure question.  I’ve marked it case sensitive, but all UIs COULD downcase passphrases to simplify this.  The secure question becomes the body of the email and the subject can be something like “Alice is sharing her verification key with you!”

Bob recieves the email, an his client flags it (with an icon or similar) as containing verification information.  Some clients may find it makes more sense to process the message immidiately upon receipt, instead of just flagging it.

Bob opens (or his client auto-opens) the message.  Instead of being presented with an email full of gook, he is presented with a window by his client.

Bob decrypts the key.

Bob enters the answer and is presented with a window describing the key.  This window should say “Alice is claiming…” or similar and display the image in the key (if there is one) and all UIDs/comments.  There should then be a list of how well Bob knows this key:

It claims to be and was sent from there: very low

It was found to be the same as one available on public key servers: very low

It was verified using a secret question: medium

It has not been verified by anyone you know [aka, key signatures, high]

[Button: Advanced Verification, showing the key fingerprint – for advanced users]

[Button: trust this key]

[Button: I have talked to Alice and know this is her key (ultimate trust, signs key)]

If three or more signatures from people Bob trusts are on the key (remember, the unencrypted one) the client may skip to this step and provide a “verify using secret question” button.

Opening this message in the future should sync with keyservers, and then show the last dialog again, showing any new signatures from people Bob trusts, and allowing him to verify/sign it.

Give Raw Pages a Lift

Posted on

We’ve all seen it: the harsh white background, serif fonts, and window-border hugging indicitive of unstyle (or very lightly styled) (X)HTML.  Today I discovered something: it takes very little CSS to take a basic HTML page and give it some flavour (and make it less painful on the eyes).  Just eight lines of CSS.

Not all pages have such CSS, however, and sometimes it might be nice to just hit a button and get some style.  So I created a bookmarklet.  Drag it to your bookmark bar, and next time you see an unstyled page, hit it.  Basic styles will be added instantly. API

Posted on

First off, my social network search engine now has a domain thanks to Tantek!  It’s just a redirect forwarder for now, but much easier to remember!

I have been polishing some bits of the search engine and am pleased to report that it now has a complete API!

First off, the microformat API.  All data is marked up with hCard, this allowing pages on the engine to double as API output.  This is the preferred method.  If you really must, a JSON(P) variant is available.

These are the endpoints for a standard search:

These are the endpoints to search from the “point of view” of a particular person (specify a URL):

To retrieve data about a specific user use:

And that’s it!  This stuff powers my contacts page and the bookmarklet.

DiSo Gets Search

Posted on

Tantek Çelik has purchased for this service! Thanks!

Never tweet about something you don’t want to go public.  I’ve been annoying my followers for some time now about my new social search engine.  Tantek then linked to it from his WordCamp SanFrancisco presentation.  Not that I’m upset at all.  I’m ecstatic that he thought it was worth linking to!  Still, a word to the cautious 😉

So how does this search engine work? What does it do? Basically, it’s an hCard search engine.  Unlike the Yahoo or Technorati Kitchen implementations, however, this search is focused on social networking and profiles.  If DiSo were Facebook, this could be the friend search functionality.  So instead of having the results be links to pages that contain matching hCards, the results are profiles with social networking data (including contacts) and names, etc.

One other key thing that is different here from pure hCard search is that I am only spidering representative hCards (with some small hacks for well-known sites like Twitter).  This means I don’t spider arbitrary hCard data, instead I am only indexing profile pages.  I use both XFN parsing and the SGAPI to verify claims that two pages represent the same person, and then associate them.  Data from both pages goes into the index as if it were all on one page.  Only one page needs an hCard, since connections are made through rel=me and XFN.  This way, although my profile is on my main page and my contacts are at, the search engine indexes them both.

To find new pages to index, I spider along XFN (and FOAF, since I also ask the SGAPI) to find pages likely to have the sort of data I’m looking for.  Interestingly enough, this means that social networks like Twitter, Pownce, and Digg, who support hCard and XFN, get almost completely indexed.  There are over 100000 profiles in the index now, and I have only given it one manually :

I’m not entirely sure how the data will be useful yet, but I’m really excited about the possibilities.  I firmly believe in making XFN lists, static though they may be, come alive with potential through layers of functionality, be in through plugins, 3rd party services, or bookmarklets.

Speaking of bookmarklets, I have one.  Go to that page, add the bookmarklet, and visit my contacts page (or any other page with lots of XFN data).  Click it and watch that boring list of links and names turn into a more functional social-networking list.

The code has been released under an MIT-style license on my repository.  Front-end is PHP, back-end is Ruby.

DiSo : on our way to fixing your addressbook 😉

Messaging: What I Want

Posted on

I’ve blogged numerous times about XMPP, SMTP, and communications evolution on the web.  I’ve suggested what I want ultimately and snippets of how we might get there.  Here, I am going to outline just briefly what I consider “next steps”.  The big ones.  Get these done, and you will have made a *huge* stride in online messaging:

  1. Allow offline messages (type normal or chat) to be collected as “email”.  Gmail sort-of does this by presenting unseen offline messages in the web interface inbox.  I want IMAP access to these in the inbox and their archive.  Heck, store them in a Unix mailspool (have to store them somewhere anyway) and existing IMAP servers will just work for you!
  2. SMTP messages are type=normal.  If you store offline messages in a mailspool and run an SMTP server on that spool, you’re mostly done.  Might be good to offer real-time deliver of those messages to the user of XMPP as well though.

That’s it! Sure, more can be done, but if you get the first one done I will be your biggest fan.  Do both and you’re well on your way to an evolution in how we deal with email (both from a user and a protocol perspective).  Yes, I’ve tried to build this.  I want to do it as an ejabberd module, but ejabberd is barely documented.  I’ll try again sometime if no one else does – maybe with ejabberd, maybe with someone else.