Thursday, February 17, 2005
iComic 4 - the itch you can't scratch... yet
So there's finally some news on the iComic front!!
I'm working on a new version which I guess will be called 4.0 ... but could equally well be called the iComic Dashboard Edition.
In case you didn't guess, the new version runs as a widget in the Dashboard of Tiger (aka MacOS X 10.4).
There's still quite a few things left to do. The background updating is horribly messed up right now, but the app functions in principal - check out the screenshot below.
With this new version I've taken a different tack in terms of greatly simplifying the app logic, mostly by removing features that would be either hard to implement in a web-based app, or which are seldom used features that complicate the app beyond reason.
A summary of changes:
In iComic 4 you can have a text-only plugin - an XML document with a .xcomic extension. The format of the file is like a simplified version of the old inventory.plist file. The benefit of this approach is that it makes it very easy to develop a new plugin and get it out there - you don't have to create a .sit file because its just text.
I have an example of the Dilbert plugin in iComic 4 implemented as a .xcomic file in case you are interested.
A few things about the new JavaScript plugins:
I'm working on a new version which I guess will be called 4.0 ... but could equally well be called the iComic Dashboard Edition.
In case you didn't guess, the new version runs as a widget in the Dashboard of Tiger (aka MacOS X 10.4).
There's still quite a few things left to do. The background updating is horribly messed up right now, but the app functions in principal - check out the screenshot below.
With this new version I've taken a different tack in terms of greatly simplifying the app logic, mostly by removing features that would be either hard to implement in a web-based app, or which are seldom used features that complicate the app beyond reason.
A summary of changes:
- Runs as a Dashboard widget. Press F12 - there are your comics
- You can open as many iComic windows as you like. Each can be pointed at a different comic, which you choose by "flipping over" the comic window and choosing a comic plugin from a list
- Rather than using the "metal" interface and having a bunch of toolbar buttons, iComic 4 looks like the comic was cut from a newspaper and stuck to your screen!
- To navigate between comics, click on the curled up edges, or use the arrow keys on the keyboard
- iComic 3 used Perl for plugins, but that isn't a secure scripting environment. iComic 4 uses JavaScript and doesn't support the old Perl plugins. While this may seem like a terrible move, I think the new system will be a lot better.
For example: in the new model, all HTML and image downloading is done by Safari, so it automatically supports proxy servers.
Secondly, because Safari loads HTML into a DOM, your JavaScript plugin gets given a DOM so you're using a well known, well documented way to find the images. iComic then provides callbacks to let you load other documents or register the images you found. - I dropped several features, notably: Calendar, Comments and Favorites.
The calendar seemed useful, but it didn't really buy you very much, as the most common scenario was to use the app to browse today's comics across a number of strips. In iComic 4 you can have several strips all open at once and they'll all be up to date, so this most common scenario is greatly improved.
Favorites seemed like it might be useful to, but I personally never used it. It just made the app code more complicated but didn't do much.
Comments was my favorites useless feature. I know of almost nobody that bothered to comment (and subsequently search) their comics, but the code for this feature was evil.
In iComic 4 you can have a text-only plugin - an XML document with a .xcomic extension. The format of the file is like a simplified version of the old inventory.plist file. The benefit of this approach is that it makes it very easy to develop a new plugin and get it out there - you don't have to create a .sit file because its just text.
I have an example of the Dilbert plugin in iComic 4 implemented as a .xcomic file in case you are interested.
A few things about the new JavaScript plugins:
- The main() function is what iComic runs first. This is where you would load the comic's initial page.
- The loadDocument call returns immediately. Once the HTML has loaded, your onloadDocument() method is called.
- There is another method called loadDocumentForDate that can be called to load a HTML page that you know to be associated with a specific date. This gives iComic a chance to ignore the request if it knows it has already loaded the image from the target page. Therefore for the Dilbert site, if the plugin was run every day, it would only ever load the archive page because it would have already seen the others.
- The registerImage method is what you call to tell iComic the image url associated with a particular day.
- Finally, there is a log() function that you can use to log messages in the Console log. This means you can use Console.app to help you debug your plugin - something that was hard to do in iComic 3
Thursday, February 03, 2005
Got less junk email lately? Thought not
The CAN-SPAM act has been with us for a year now, but my inbox seems just as full of Cialis and other body-part-enhancing offers as it ever was.
CAN-SPAM gave legislators teeth to prosecute spammers once caught, but there was the rub. A lot of spammers bounced messages through several hosts and obfuscated the trail back to themselves, so while a few less careful individuals have been caught, many more have continued to spam with impunity.
Microsoft had an interesting idea, which was to introduce a "tax" for sending email - the tax being that sending email would require some kind of computationally intensive activity that would not affect you much sending email from your desk, but would limit the output of a spam house (because it might take several seconds to compute some value needed to be able to send the message, so you'd need a lot of computers to send the same number of messages, and computers cost money).
What I find most interesting about this is that a technique for enforcing it already exists in the form of digital signatures. When you take a message and digitally sign it, your email client uses a certificate containing your public and private key and uses it to calculate a large (typically 2048-bit) number called a hash code from the content of the email.
Once the signature has been computed, it is attached to the email message (just like any other attachment) and the message goes out. The receiving mail client sees there is a signature. The signature includes information about the sender along with the sender's public key that is used to verify the hash code. At that point we can say that the message came who it says it did.
You can immediately see that this has an added side benefit in cutting down on phishing scams - those emails that say they come from PayPal or eBay and ask you to enter your username and password (and heaven help you if you give it to them!)
Of course, there is a downside to this. If you have ever received a signed email you will know there is a lot more in the signature than just the public key. A lot of the metadata held in the sender's certificate is sent too, such as their name and email, and information on who issued the certificate to them. This last part is necessary to build a "chain of trust" that means you couldn't just make a certificate on your PC and use it and have people trust you - to be trusted the certificate needs to come from a signing authority such as Verisign or Thawte.
The issue with this is that all this information adds bulk to the message. That might not be a bad thing if you're trying to slow a spammer down but it also means your inbox will rapidly fill your hard disk.
I have an alternative suggestion that I called sign by reference. Instead of attaching the whole signature complete with sender certificate info, just send the signature itself (the computed hash code) and a url pointer to where the public certificate information is found. I would suggest this pointer be a domain name only, with the certificate living in a well known location just like the P3P (Platform for Privacy Preferences) XML file must be at
Because we're only sending a hash and a url (domain name) we could now get away with just storing them in the SMTP message header instead of as attachments, so the full message might look like this:
The mail client would go load the certificate from http://www.senderisp.com/w3c/email.cer and verify the signature, just as if the whole signature had been attached.
There are a raft of other things you could do with this:
At the end of the day, if there was an easy solution to the junk email problem you would have seen it by now, but I think with this proposal you can see a raft of coverage:
CAN-SPAM gave legislators teeth to prosecute spammers once caught, but there was the rub. A lot of spammers bounced messages through several hosts and obfuscated the trail back to themselves, so while a few less careful individuals have been caught, many more have continued to spam with impunity.
Microsoft had an interesting idea, which was to introduce a "tax" for sending email - the tax being that sending email would require some kind of computationally intensive activity that would not affect you much sending email from your desk, but would limit the output of a spam house (because it might take several seconds to compute some value needed to be able to send the message, so you'd need a lot of computers to send the same number of messages, and computers cost money).
What I find most interesting about this is that a technique for enforcing it already exists in the form of digital signatures. When you take a message and digitally sign it, your email client uses a certificate containing your public and private key and uses it to calculate a large (typically 2048-bit) number called a hash code from the content of the email.
Once the signature has been computed, it is attached to the email message (just like any other attachment) and the message goes out. The receiving mail client sees there is a signature. The signature includes information about the sender along with the sender's public key that is used to verify the hash code. At that point we can say that the message came who it says it did.
You can immediately see that this has an added side benefit in cutting down on phishing scams - those emails that say they come from PayPal or eBay and ask you to enter your username and password (and heaven help you if you give it to them!)
Of course, there is a downside to this. If you have ever received a signed email you will know there is a lot more in the signature than just the public key. A lot of the metadata held in the sender's certificate is sent too, such as their name and email, and information on who issued the certificate to them. This last part is necessary to build a "chain of trust" that means you couldn't just make a certificate on your PC and use it and have people trust you - to be trusted the certificate needs to come from a signing authority such as Verisign or Thawte.
The issue with this is that all this information adds bulk to the message. That might not be a bad thing if you're trying to slow a spammer down but it also means your inbox will rapidly fill your hard disk.
I have an alternative suggestion that I called sign by reference. Instead of attaching the whole signature complete with sender certificate info, just send the signature itself (the computed hash code) and a url pointer to where the public certificate information is found. I would suggest this pointer be a domain name only, with the certificate living in a well known location just like the P3P (Platform for Privacy Preferences) XML file must be at
/w3c/p3p.xml. When you receive an email signed by reference, your client would check to see if it already had a valid certificate from the sending domain. If not it would request (and store) the certificate and verify the signature. For the sake of this discussion lets say the location is: /w3c/email.cerBecause we're only sending a hash and a url (domain name) we could now get away with just storing them in the SMTP message header instead of as attachments, so the full message might look like this:
Received: from unknown (HELO mail.senderisp.com) (aa.bb.cc.dd) by mail.yourisp.com with ESMTP; 13 Sep 2004 22:10:40 -0500To: Steve Saxon Message-Id: From: John Doe Subject: Sign by referenceDate: Mon, 13 Sep 2004 22:10:32 -0500X-Mailer: Senders Mail Client (1.0)Return-Path: johndoe@senderisp.comX-SignHash: rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9Hf8HHGTrfvh JhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF40GhIGfHfQbnj756YT64VX-SignOrigin: www.senderisp.comThis is the signed message bodyThe mail client would go load the certificate from http://www.senderisp.com/w3c/email.cer and verify the signature, just as if the whole signature had been attached.
There are a raft of other things you could do with this:
- You would want to verify that the signing original and sender's email were in the same base domain (senderisp.com in my example above).
- You could require the certificate's well known location to be secure (using SSL), adding another layer of computing tax to the sender. And of course, you would want to verify the SSL certificate against the sender's base domain too.
At the end of the day, if there was an easy solution to the junk email problem you would have seen it by now, but I think with this proposal you can see a raft of coverage:
- A sender can be trusted if they are in your address book (most email clients can handle this)
- A digitally signed message tells you the person that sent the message is who they say they are, which in theory at least gives the authorities someone to go after in a spam case. But there is a cost in terms of space taken on your hard disk.
- Having email clients support sign by reference would mean less weight in your inbox, while still verifying the sender
- Customer's get peace of mind of knowing the email really did come from who it says it did.
- Online shopping sites such as Amazon.com would need to sign their emails, but at least they don't have to attach the whole certificate, so their bandwidth costs don't go up much.
