You can see Typekit in action on Jeffrey Veen’s website (I assume this is the proposed implementation of Typekit). [Update: 3rd June 2009, It looks like Jeffrey is no longer using Typekit on his website. No previews for you.]

A remote javascript file is linked by the website owner that includes a copy of the jquery framework, and a Typekit class that writes in the dynamic CSS and javascript files specific to that website.

From what I can make out, .otf fonts are embedded in a dynamically injected CSS file using a base64 encoded data url. Although this increases the size of the file compared to its binary equivalent, it can benefit from server compression like gzip. I’m not sure if this is an attempt at obsfucation, or used for convenience, but it’s trivially easy to obtain a fully functioning .otf file. Older IE browsers (IE7 and below) are Internet Explorer (including IE8) is served a fallback to an EOT file.

Because Typekit injects cross-site scripts, you the web developer have to be able to trust the security of their service as much as you would trust your own server setup. Potentially, if they are compromised, any file they inject into your page could also compromise your visitors.

In common with other font replacement techniques, Typekit relies on Javascript and (in Safari at least, I didn’t test in other browsers) suffers from Flash of Unstyled Content.

It seems to me that Typekit is a service where users can subscribe through a single portal to manage the embedding of @font-face compatible fonts (falling back to EOT where necessary) from participating foundries (who?). That’s nice, as far as it goes, but the hyperbole about changing the face of the web is getting way out of hand. The new thing here isn’t Typekit, but the tipping point that’s been reached of browsers that support @font-face.