Last week I was thinking about how cool it would be if Amazon’s Kindle supported O’Reilly’s Safari Books Online service, and I decided to dust off the XO to see if it could be used as an ebook reader for Safari Books. With a little help, it can.

In ebook mode you can scroll in all four directions, page up/down, and jump to the top or bottom of a page, but you cannot click the next/previous buttons within Safari Books. However, GreaseMonkey and a simple userscript can solve that.

The first step is to install the Firefox “Activity”, or a version of Linux that runs a stock Firefox. Then install GreaseMonkey. Finally, install this userscript:

http://tlrobinson.net/userscripts/xo-safari.user.js

This simple userscript intercepts page up and page down (the “O” and “X” game pad) buttons and maps them to “previous” and “next” actions in Safari Books, allowing you to easily switch pages in ebook mode.

Most Mac OS X power users know about the “open” command line tool which opens the files specified as arguments in their default (or a specified) OS X application. Additionally, many OS X text editors, such as TextMate (”mate”) and SubEthaEdit (”see”), come with command line tools which can be used to open files.

These are great when working locally, but obviously do no work remotely. Often when working on remote servers you end up using command line editors which you may not be as familiar with.

ropen’s Solution

The ropen tool solves this problem using two simple shell scripts, which make use of MacFuse’s sshfs. You run the “ropen” program on your remote machine(s) when you want to open a remote file locally (this is equivalent to the OS X “open” command). The “ropend” daemon runs on your local OS X machine waiting for open requests, and the “ropen.php” PHP script proxies requests from ropen to ropend.

How it works

1. When ropen is executed it makes an HTTP request to ropen.php with the paths to be opened and application to open them with, if any, as well as the SSH user, host, and port of the remote machine.
2. ropen.php stores this open request in a queue that is tied to ROPEN_SECRET via PHP’s sessions.
3. ropend polls ropen.php every 1 second waiting for open requests. When it receives one it mounts the remote filesystem using sshfs (if it’s not already mounted) and opens the files or directories specified.

More information

See more information about ropen on the ropen project page.

I wanted to hook all the browser’s asynchronous JavaScript “entry points” : events, timers, asynchronous XMLHttpRequests, script tags, and “javascript:” URLs. This article deals with the first two, events and timers.

To do this, I figured I could somehow “wrap” all the callback functions passed to setTimeout(), setInterval(), and addEventListener(). By “wrapped” I mean another function that we specify calls the original function, rather than the original function getting called directly. This allows us do whatever we want right before and after calling the original function, including manipulating the arguments and return value, logging to the console, calling other functions, putting it in a try/catch, etc.

Here’s the implementation of “callbackWrap”, the function that does all the work:

To use it, you need function that takes another function as a parameter and returns a wrapped version of that function which does whatever you want it to. In this case it just prints out “whoooaaaaa:” followed by the “extra” parameter:

Finally, to actually use this, we call callbackWrap with the object that contains the function we want to wrap, the name of the function property, the index of the callback argument to the function (0 for setTimeout/setInterval, 1 for addEventListener), a wrapper “factory” function, and optionally an extra argument that’s made available (via the closure) to the wrapped function. The extra parameter can be used for any data you need to pass to the wrapper function, or it can be ignored.

Here’s how this would be used on setTimeout, setInterval, and addEventListener on window, Element.prototype and Document.prototype (so it applies to all Elements and Documents):

Here’s a live example. (edit: the button example seems to be broken in Firefox)

The first thing callbackWrap does is save the original function (window.setTimeout, for this example) in a local variable, “original”, since we’ll need it later. We then replace the original with a new function. When this new function is called (the new window.setTimeout), we first call the “wrapperMaker” function (”logWrapper” in the example), passing it the callback function, which is the argument at the argumentIndex position, and the optional “extra” argument. That function returns a new function which replaces the original callback argument, before we then call the original function (saved in the local variable “original”) with the same arguments (except the callback is now wrapped).

So really this blog post should have been called “a function that wraps other functions such that all callback functions passed to it are wrapped by yet another function”. There’s two levels of wrapping going on: the original function is wrapped, such that it wraps every callback given to it. If you’re confused I don’t blame you.

Why would I want to do this, you ask? There are a couple scenarios I had in mind, and I’m sure you can think of others.

First, I wanted to catch all uncaught exceptions for a debugging tool I’m working on. Sure, you can assign an error handler to the “onerror” property of the window object, but this only gives you the error name, file name, and line number – I wanted the full exception object to be caught by a try/catch.

Here’s a wrapper that catches all uncaught exceptions and alerts them:

Second, in Cappuccino we mimic Cocoa’s concept of a “run loop”, but due to the way browsers work the implementation is a bit different. A consequence of this was that we couldn’t automatically call “[[CPRunLoop currentRunLoop] performSelectors];” at the end of each run loop, which is required for various pieces of Cappuccino. If you’ve ever come across a situation where you perform some action but the UI doesn’t update until you move the mouse, it’s probably because performSelectors isn’t being called. This isn’t common, since Cappuccino encapsulates events, XMLHttpRequests, and now timers with CPEvent, CPURLConnection, and CPTimer, respectively. These Cappuccino classes handle calling performSelectors for you. However, if you wanted to integrate with a third party library or use setTimeout, XMLHttpRequest, etc directly, currently you would need to call performSelectors manually. With this new trick we can call it automagically.

Here’s the wrapper that does exactly that (note the inline Objective-J call to “[[CPRunLoop currentRunLoop] performSelectors]”):

One minor feature I didn’t demonstrate was that callbackWrap returns the original function that it wrapped. If you need the original for any reason you can save it to some other variable.

callbackWrap could use a few improvements. Currently this breaks on cases where you pass a string instead of a function. A simple check for the argument type, and appropriate handling would solve this (either skipping the wrapping, or compiling the the string with a “new Function()” call). But using strings instead of functions is considered poor practice anyway.

Ultimately I failed to recover most of the censored text (except “to”), so I had to cheat a little. The following video is the program running on a very similar image I created. This proves it works in ideal conditions, but needs some improvement to work in less than ideal cases.

(and no, as far as I know my friend’s project has nothing to do with eating monkeys)

Applying a filter like Photoshop’s “mosaic” filter obscures the original data, but doesn’t remove it entirely. If we can reconstruct an image with known text that looks very similar to original image, then we can be pretty sure the original text is the same as our known text. This is very similar in principle to brute-force cracking a password hash. For a more detailed explanation see this article.

Photoshop was an obvious choice since I needed to recreate the exact same fancy styling as the original image, then apply the exact same mosaic filter. I figured I would have to write a script that tells Photoshop to generate images, then use an external tool to actually compare them to the original.

It turns out that Photoshop CS3 has all the features necessary to pull the whole thing off without any other programs or tools. The most important feature is the JavaScript scripting environment built into Photoshop, which is far more powerful than the AppleScript environment (and a much nicer language, in my opinion).

CS3 added two other features that are critical to this task: Smart Filters, and Measurements. Smart Filters lets you edit a layer (namely the text with effects applied) after you apply a filter that would have previously require rasterization. This lets us apply the censoring filter to our styled text, and later change the text without having to manually reapply the filter. The “measurements” feature lets you record various statistics about an image or portion of an image: in our case we’ll want the “average gray value” of the “difference” between the original and generated images.

First we need to prepare the environment. Open the original image in Photoshop, and attempt to replicate the original un-censored text as closely as possible (you need some uncensored text as a reference). Place your text layer on top of the original and toggle between normal and “difference” blending modes to see how you close you are. Ideally everything will be black in “difference” mode. It’s very important to precisely match the font, size, spacing, color, effects like drop shadows or outlines, and even the background. If these are off even by a little bit it will throw things off. I ended up having to cheat because I couldn’t match the slick styling of the original text with my lame Photoshop design skills.

Once the text matches and is lined up perfectly, select the layer then choose “Convert for Smart Filters” from the “Filter” menu. Now select the censored portion of the text and apply the same filter used on the original image, again matching it as closely as possible. For the mosaic filter, you can line up the “grid” by adjusting the origin and size of the selection (yeah, it’s a pain).

Finally, make sure your layer is on top of the original, and the blending mode on your layer is set to “difference”. Double-click the Smart Object layer to open it’s source document, and adjust the variables listed at the top of the JavaScript to match the names and layers. Also, in the menu “Analysis”: “Select Data Points”: “Custom…” make sure only “Gray Value (Mean)” is checked.

Code

Rather than attempting to explain it in detail here, just read the code and comments. Here’s a quick summary:

1. Start with the first character. Try setting it to each of the possibilities (a through z, and a space), and record the difference score between the original image and generated image. Only look at the first half of the current character (since the second half will be influenced by the *next* character).
2. Sort the results. Lower scores are better (less different)
3. Now try each of the top 3 characters along with every possibility for the *next* character. This time record score for the whole width of the current character since we’re checking the next character as well.
4. Pick the best choice, either the best permutation out of all 81 combinations (3 best * 27 possible), or out of the 3 averages for each best.
5. Repeat for the next character until done.

The raw code and sample Photoshop file are available on GitHub.

Issues

This problem is particularly tricky for proportional fonts, since if you get any character wrong and it’s width is different than the actual character, then all subsequent characters will be misaligned, causing more incorrect guesses, compounding the problem even more, and so on. I’m not sure how to deal with this, other than improving the overall matching quality. Ideally we would test every possible combination for the entire string, but that would require 27^n tests, where n is the number of unknown characters. This is obviously not feasible.

With the simplistic method of iterating over each position and trying each possible character, it turned out that almost every single “guess” was for the letters “m” or “w”. This was because for positions where the original was narrower characters, the “m” would “bleed” over into the next position, improving the score regardless of how well it actually matched the current character. To get around this, we only look at the difference for the first half of the character’s position.

Since looking at the first half of the character removes some valuable information, we then do a second pass using the top several guesses from the first pass, this time looking at the full width of the current character along with each of the possible next characters (27 tests + 3 runs times 27 tests results in 108 tests per character).

Further improvements could definitely be made, but I’ve already spent several hours too many on this.

The current algorithm runs at about 3 characters per minute. The overhead of Photoshop saving the Smart Object document on every individual test case is significant. If this were a special purpose program manipulating images directly it would likely be much faster. The tradeoff, of course, is you have all of Photoshop’s flexibility at your disposal for matching the original document’s font, size, style, spacing, and censoring effects, which is very important. For small amounts of text speed isn’t a problem.

Conclusion

While my original goal of recovering the censored text on my friend’s page was never achieved, the project was a success. It works well on my test image, and I learned about 3 obscure but cool and useful features of Photoshop!

Oh, and that’s why ██████████ uses black ink to ██████ their ██████!

It’s a very capable API, and you could write an entire framework around it (as some people have), but I don’t think it’s necessary. A few little helper functions and Google’s documentation is all you really need. Here’s the heart of my “framework” in JavaScript:

And PHP:

And here’s a simple bar chart example in PHP:

The nice thing about this “frameworks” is it takes 30 seconds to implement in many languages, and the actual API is identical across every language, since it just uses a hash object and the original API as a very simple domain-specific language.

This could be improved with a few more helper functions for different parts of the Google Chart API, but this function remains the most important.

Here’s a simple testbed for trying out the JavaScript version. Simple edit the JavaScript and click “Update!” to see the results: gchart_tester.html

Polling is perfectly sufficient for this sort of updating (it’s not particularly latency sensitive), but none of this is relevant to the rest of this post anyhow.

As neat as it is, I’m not going to sit around all day watching Facebook, waiting for updates. I want to be notified of updates unobtrusively, at which point I can decide if I want to ignore them or check it out. Growl is perfect for this.

Many OS X apps use Growl to display notifications to the user. They use either Distributed Objects or a UDP protocol called GrowlTalk to post the notifications, neither of which is suitable for a client-side web app. Google Gears promises to provide NotificationAPI at some point, but it’s not currently ready. Fluid also has a notification API, but we need Firefox’s Greasemonkey plugin to inject some JavaScript.

Brian Dunnington wrote a version of Growl for Windows, which adds one neat feature: an HTTP interface. This lets the browser (or anything else the speaks HTTP) post notifications directly. Unfortunately the OS X version of Growl doesn’t have this interface built in, but it’s nearly trivial to create a bridge to the GrowlTalk protocol in Python:

growlbridge.py.gz

Of course this opens up a port on your machine, so you should take the necessary precautions to firewall it. It uses Rui Carmo’s netgrowl and also requires Bob Ippolito’s simplejson.

We can now use Brian’s growl.js library with both Mac OS X and Windows versions of Growl. The next step is to connect it up to Facebook with Greasemonkey:

This fairly simple userscript loads growl.js, then overwrites one of Facebook’s JavaScript functions that gets called when updating the feed, HomeFeed.prototype._addStoriesToQueue(). The new function should call the original one (so that the feed is still updated), but it should also post a new notification for each new feed story.

That’s about it. Run “python growlbridge.py” if you’re on a Mac (make sure you have netgrowl and simplejson), or Brian Dunnington’s Growl for Windows, install the above Greasemonkey userscript, and open up http://www.new.facebook.com/home.php?tab=2.

Unfortunately, there appears to be some bugs (or new security restrictions) in Firefox 3 that prevents this userscript from working correctly, but it works fine in Firefox 2.

In the future growl.js could be swapped out for the Gears or Fluid notification APIs, or anything else (ideally some standard). Also, hopefully Growl for OS X will have the same HTTP interface built in.

I’m not sure what to make of the article. I feel like the author said a bunch of big words hoping that most people would assume he knew what he was talking about and move on. Let’s try to break it down:

Data transaction security in MobileMe’s web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple’s cloud, rather than the SSL web page encryption used by HTTPS.

So the “JSON data exchanges” are “authenticated”. This is like saying “You can only read your email if you’re logged in”. I should hope so.

The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication

This implies that while the app itself isn’t encrypted, it doesn’t need to be since the data itself is. This would be nice, but:

• As Andrew Wooster points out, if a man-in-the-middle attack is possible, the app itself can by hijacked, and all bets are off. In addition to providing encryption, SSL can protect against MITM attacks. See below.
• The data is actually NOT encrypted. Doh. See screenshots below.
• Even if MITM attacks are taken out of the equation, and Apple wanted to encrypt the data but not the app, it’s simply not possible to make HTTPS requests from a page loaded over plain old HTTP due to the same origin policy. There are numerous tricks (iframes, script tags, etc) to get around the same origin policy but none that I’m aware of would be useful in this sort of situation.

Viewing MobileMe’s traffic in your network sniffer of choice (I prefer Charles and Wireshark) shows your data is actually unencrypted.

Calender:

Email:

Finally, the article states:

This has caused some unnecessary panic among web users who have equated their browser’s SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.

SSL is, in fact, the standard for securing web apps. I am much more inclined to trust SSL, which is known to work well, than a proprietary solution (or in MobileMe’s case, none at all).

Regarding email being unencrypted, it is true that email is often unencrypted between mail servers, but the more important link is between the user and their mail server, especially with widespread WiFi usage. Any sane person will use POP, IMAP, or web mail over SSL, which is more than MobileMe can claim to offer. And don’t forget it’s not just email we’re talking about: calendars, contacts, files, etc are also transmitted in the clear by MobileMe.

[Clarification: this article only pertains to the MobileMe web interface. IMAP email and OS X syncing do offer encryption]

The article reminded me of the recent Mozilla SSL policy bad for the Web article and ensuing comments on Hacker News. Some people are upset that Firefox 3 makes it harder for users to visit sites with self-signed SSL certificates. They claim this is bad for the web because it forces anyone who wishes to use encryption to pay a certificate authority (CA) for a signed SSL certificate, which goes against the openness of the Web.

They point to the fact that self-signed certificates can offer encryption without authentication. This is true, until a MITM attack is possible, at which point the encryption becomes useless. The attacker simply inserts himself between you and the server, encrypting both channels with his own self-signed certificate, while still intercepting all communication. This is much worse than no encryption at all, since the user may naively believe it’s a secure connection.

If browsers were to blindly accept self-signed certificates, the system would break down. Just because you wanted to save $15 on a SSL certificate, I would no longer be warned of MITM attack on my bank website. Clearly not acceptable.

So they suggest making the warning less obtrusive, but then average users who don’t know what SSL will simply ignore it. The more sites that use self-signed certs, the more they ignore it, and the more they become used to it, until the day they go to their bank’s website and get a warning they ignore out of habit. It’s a user interface problem just as much as a technical problem.

Making the warning scary and difficult to ignore accomplishes two things. It makes it harder for the user to accidentally ignore it, and it encourages webmasters to use CA signed certificates, which are far more secure.

My point is that when thinking about security you must take the whole system into account, not just pieces of it. SSL encryption on MobileMe’s login page is useless if the attacker can then sniff all the data, just as SSL encryption is useless if you can’t be sure who you’re talking to.

It’s about 100 lines of JavaScript. It grabs the 10 latest photos from Flickr’s “interesting photos” API and randomly places them on the screen for you to play with:

This is great if you have an iPhone with the 2.0 software, but desktop browsers should get some multitouch love too. So I started writing a little bridge that fakes multitouch events in desktop browsers. It’s far from complete, but it’s just good enough to get the virtual light table demo working.

So go ahead and load it up in the new iPhone MobileSafari or Safari 3.1+ / WebKit nightly (requires CSS transforms):

http://tlrobinson.net/iphone/lighttable/

In desktop browsers it uses the previous clicked location as a second “touch”, so you can click a photo then click and drag another spot on the photo to resize and rotate (notice the yellow dot).

For a good overview of touch events and gestures, check out this SitePen blog post and Apple’s documentation.

Here’s the source for the fake multitouch bridge:

http://tlrobinson.net/iphone/lighttable/multitouch-fake.js.

Clearly the reverse of this bridge would be even more useful, since iPhone only sends mouse events under specific conditions. The mousedown, mouseup, and mousemove events could be emulated using the touch equivalents to make certain web apps work on the iPhone without much additional work. Of course you would need to either cancel the default actions (i.e. panning and zooming) on touch events, or have some way to manage the interactions between them.

For those unfamiliar with OpenID, it is a single sign-on system, which allows users to remember a single username and password for signing in to any site which supports OpenID . There are two basic parts to the OpenID system: sites which wish to allow users to sign in using an OpenID (the “relying party”), and sites which host your OpenID (the “OpenID provider”). Yahoo has chosen to be the latter, an OpenID provider.

Most OpenID providers give their users a simple, easy to remember OpenID like “username.livejournal.com” or “username.wordpress.com”. However, by default Yahoo provides their users with an obscure OpenID like “me.yahoo.com/a/1bjkvd893414lka09i23″, impossible for any normal person to remember. Why not use “me.yahoo.com/username” like most other OpenID providers, you ask? Simple: so Yahoo can force other sites (the “relying parties”) into placing “Sign in using Yahoo” buttons on their login pages. If a site wants to allow millions of Yahoo users to easily sign in, they must include this button. Free advertising for Yahoo.

If other OpenID providers follow this trend we’ll soon end up with login pages covered with dozens of “Sign in using ________” buttons. This is definitely not then intention of OpenID. Any user with any OpenID provider should be able to type their OpenID into any site which supports OpenID, and it should just work.

Additionally, Yahoo has chosen not to be a relying party themselves. This means that users who have OpenIDs from any number of other providers can’t sign into Yahoo using their existing OpenID. They’re basically saying “Yeah we support OpenID… as long as WE’RE in control”.

To become an acceptable OpenID provider, Yahoo should:

• give users https://me.yahoo.com/username by DEFAULT, not as an option buried somewhere in the settings.
• educate users to type either me.yahoo.com/username or yahoo.com into OpenID login pages, NOT have Yahoo-specific buttons.
• become an OpenID relying party, i.e. allow other people to log into Yahoo using their OWN OpenIDs.

In the meantime, I suggest getting an OpenID from an another provider such as myopenid.com. If you have a personal website or blog, you can easily use it’s URL as your OpenID via delegation. Sam Ruby has an excellent overview of various OpenID options.

rlwrap gccalc

It’s useful with many other tools, like telnet and netcat, and interactive interpreters that don’t have line editing or history, like Rhino (Javascript) and others.