Command-Tab

To kick off their WWDC 2006 conference, Apple yet again delivered the goods to the Mac faithful. The Intel transition is now complete, and this coming spring will see a shiny new release of Mac OS X.

New “Mac Pro” towers touting Intel Xeon dual-core chips and a massive amount of room for expansion lead the way for high end computing, leaving all but the aluminum G5 case behind. These are also the first Apple machines to hit 3 GHz, which is a huge leap in performance for Macs. I’m looking forward to see just how well these machines perform – running Mac OS X or Windows. Finally, owners can take advantage of the best of both worlds using one ultra-fast machine.

While the Mac Pro towers are great, I’m more excited by the sneak peek of Mac OS X 10.5. Apple’s new “Time Machine” backup strategy will be fantastic if it works as seamlessly as it was presented. I’m curious, though, how it will handle changes such as a large temporary file that’s created, such as joined video segments. Will a backup state exist with all the files and thus eat up a huge amount of Time Machine “space” on the backup drive? We’ll know shortly. The Spotlight improvements are a welcome addition, too, as the current Spotlight search is rather slow. What really interests me, though, are the “Top Secret” features not announced or installed in the WWDC build of 10.5. What other cool stuff could Apple have in store that’s not yet ready for public consumption? And I say “public” because you just know that WWDC build of 10.5 is going to be all over the web in no time…

Update: Also, did anyone else notice the huge icons in the Time Machine demo? It looks like Leopard will increase the maximum icon size.

Update: Andy Ihnatko has a great article at MacWorld about the Top Secret Leopard features. Which, by the way, are speculated to be:

• Complete 64-Bit support for Intel and PowerPC through all frameworks excluding QuickTime C, QuickDraw, Sound Manager, Code Fragment Manager, Language Analysis Manager and QuickTime Musical Instruments. These modules are deprecated and one should use the modern equivalents instead.
• Leopard will feature resolution-independent user interface and there are several functions to get the current scaling factor and apply it to pixel measurements. It is a good idea to use vector controls and buttons (PDF will work fine) or to have multiple sized resources, similar to Mac OS X icon design, so you can scale to the nearest size for the required resolution.
• Address Book adds support for sharing accounts, allowing an application to restrict content according to user.
• Automator includes a new user interface and allows things such as action recording, workflow variables and embedding workflows in other applications.
• Time Machine has an API that allows developers to exclude unimportant files from a backup set which improves backup performance and reduces space needed for a backup.
• A new Calendar Store framework allows developers access to calendar, event and task information from iCal to use in their applications or to add new events or tasks.
• Carbon, the set of APIs built upon Classic MacOS and used by most 3rd party high-profile Mac OS X applications, now allows Cocoa views to be embedded into the application. This could provide applications like Photoshop and Microsoft Office access to advanced functions previously only available to Cocoa applications.
• A new control for creating matrices of views is available, NSGridView. This allows a grid to be created from any view in the system, including OpenGL or Web Views.
• Core Animation allows layers to be used as backing stores for a view, windows to use explicit animations when resizing (can be three dimensional, akin to the Time Machine view). Any view can now be put into fullscreen mode and a CoreImage transition effect can be used. Using Core Animation you can create anything including GPU-accelerated Front Row-style user interfaces without having to write OpenGL code. A Core Animation layer can include OpenGL content, Core Image and Core Video filter effects and Quartz/Cocoa drawing content, like views and windows.
• Text engine improvements include a systemwide grammar checking facility, smart quote support, automatic link detection and support for copying and pasting multiple selections.
• Core Image has been upgraded to allow access to RAW images directly.
• Apache 2.0, Ruby on Rails and Subversion are included, and support for script-to-framework programming is available, allowing Python and Ruby scripting to access Mac OS X specific APIs.
• The iChat framework allows a developer to add shared content to an active iChat session, for example a video, an image slideshow or even an online multiplayer game.
• “Sharing accounts” are possible, with users being restricted via an access control list (ACL) to certain applications or files. Developers can integrate with this by restricting access to a specific piece of content by connecting it to a sharing account. Sharing accounts have no home folder.
• An Image Kit is included, to allow a developer to easily create an application that can browse, view, crop, rotate and pick images, then apply Core Image filter effects through an interface. A slideshow interface is also open to developers, allowing any application to display a fullscreen slideshow of images.
• Leopard also gives developers access to a “Latent Semantic Mapping” framework, which is the basis for spam protection in Mail. It allows you to analyze text and train the engine to restrict items with specific content (like spam e-mail for example).
• Mail stationery is open to developers, allowing any web designer to create fantastic-looking Mail templates, with defined areas for custom user content.
• A new framework is included for publishing and subscribing to RSS and Atom feeds, including complete RSS parsing and generation. Local feeds can be shared over Bonjour zero-configuration sharing and discovery.
• Quicktime 7.1 is included, and the underlying QTKit framework is greatly improved. There is improved correction for nonsquare pixels, use of the clean aperture which is the “user-displayable region of video that does not contain transition artifacts caused by the encoding process”, support for aperture mode dimensions, improved pitch and rate control for audio and a number of developer improvements, like QuickTime capture from sources like cameras and microphones, full screen recording or QuickTime stream recording. Live content from a capture can be broadcast as a stream over the network.

Not long ago I bought a small, cheap 256 MB Memorex USB flash drive to get files from here to there – the kind of files that are too small for a CD-R but also too big for a quick internet transfer. Unfortunately, it came preloaded with U3, a library that allows the USB drive to run specially designed programs without leaving data behind. Programs like Portable Firefox and Thunderbird are available, letting you bring all your day-to-day software wherever you go.

I, however, disliked the idea of bringing sensitive data such as email settings out into the open, in the event my drive got stolen or lost. Also, U3 launches each time you plug the drive into a Windows machine, and the last thing I need is more little alerts popping up when using Windows. It appears that the U3 company recently gave in to public demand and released a U3 uninstaller to completely remove the software (which has the side effect of formatting the entire drive). It worked like a charm. Now I’ve got my 6 MB partition back and I couldn’t miss U3 any less.

Update: Some more technical information on the U3 drives.

When updating my copy of Xbox Media Center earlier today, I noticed that the XboxMediaCenter.xml file was missing. Looking into the matter further, I found that some significant changes had been made to the development of XBMC earlier this month.

The original XML configuration file has been removed, and most of the important options have been added to the program settings, allowing new shares to be connected directly inside Xbox Media Center. Bookmarks can now be added by starting up XBMC, pressing the white button on the controller, and choosing “Add Source.” For those who still prefer to open a file and type in the paths manually, edit the UserData/sources.xml just as you did before.

About two months ago, Apple limited iTunes album art access to users who download a song or album requiring the artwork. While this has no effect on those who simply buy from iTunes, many people – myself included – found it very useful to be able to retrieve 600x600 pixel artwork from iTunes and apply it to music gotten elsewhere. The download scheme has been changed, most likely with the sole purpose of breaking third-party systems that gather artwork automatically. While Apple has every right to do this, it makes adding metadata to a new album just slightly more complicated than it used to be. iTunes has always had great quality album art, even beyond what Amazon provides, and it was great to be able to add that into new music with very few steps.

Back when album art was “easy” to get from iTunes, all one had to do was control-click (right-click) on the album title, choose “Copy iTunes Music Store URL”, paste the link into the field on this site, and click Submit. The high resolution artwork for the referenced album was then displayed, and it could be pasted directly into iTunes’ song information windows.

From the front, the iTunes artwork-grabbing script was easy, fast, and painless. The code side was more complicated, as the given album URL had to be retrieved from the iTunes Music Store, decrypted using a symmetric key (which must have been derived from the iTunes binary), and scanned for image links. If found, the medium size album image URL – the very image seen when an album description page is loaded in iTunes – could then be modified to produce the full size artwork URL.

To see what changes Apple made after I became aware of the situation, I first opened the iTunes Music Store and added the “Free Single of the Week” to my cart (I shop in iTunes using a shopping cart system because I’m indecisive, okay?). I then started up my OS X packet-sniffing program of choice, Eavesdrop, and began watching web traffic over my WiFi connection. Since iTunes uses a web-based store, presumably to slip effortlessly through firewalls, every byte of communication between the Music Store and my computer would be logged for review. Upon clicking the “Get Song” button, a small bit of activity began, ending with a bunch of packets coming my way. My song arrived, but that was the least of my interests as my attention turned to the timing of the data that was sent and received. As soon as the transaction was initiated, my computer first requested a set gzip compressed of font styles, perhaps for display somewhere in the Music Store or new Mini-Store. Nothing spectacular there. The very next request was for the URL http://a1.phobos.apple.com/r10/Music/14/36/a4/mzi.aihenrgv.600x600-100.jpg?downloadKey=1154640230_abe417e7d789521ccd1ccb355b23775a. Before the album art method was changed, it was possible to load the part of the URL above up to the “?” and ignoring everything after, resulting in the download of the full 600x600 image. The unmodified URL retrieved by the artwork script above was similar to the one requested today, with the slight difference of the size parameter tacked onto the end. In the Music Store, the 600x600-100 shown above is replaced with 170x170-99, and that link still returns a smaller, store-sized version without requiring a downloadKey section.

So, what is this downloadKey that Apple has implemented? Keen observers will note that the first chunk of the downloadKey string contains a Unix timestamp of the instant of purchase/download. 1154640230 is the number of seconds that have passed since the Unix epoch, marking the exact time the tranfer was initiated. The second half is 32 bytes long, which happens to be the same length as an MD5 hash. Unfortunately, hash functions are designed to work one-way only; Getting the original text out of the hash is (damn near) impossible except for brute force attacking it, and that could take eons. Where does that leave those interested in continuing being able to get great quality album artwork from iTunes? Out in the cold, for now. Until someone disassembles iTunes and figures out what data is being hashed, the downloadKey cannot be recreated without first purchasing the song and thus defeating the whole purpose. On top of that, the time marker in the downloadKey is also one week from the date of purchase, likely limiting access to the image for that time period. After the noted time has passed, I’m betting that the access privileges are revoked.

Both the expiration date and the mysterious hash in the downloadKey are probably stored in a database on Apple’s end, and the full size image is served back only if the request has the right hash and is within the noted time period. I can’t even begin to speculate why the time is in the URL to begin with, as the webserver can compare the hash and timestamp of any particular request without revealing the timestamp. Unless the webserver is taking in the timestamp from the URL, I can’t see the purpose of displaying it. If it is being done that way, why even bother if we can freely modify the timestamp anyway? Such an obstacle would be like locking a keypad protected door, but allowing any code to reopen it.

While I’m disappointed to have inconclusive results for my analytic efforts, here are some facts I’ve discovered:

• Neither the timestamp nor the hash can be changed without resulting in an immediate rejection of the image request.
• The source computer – the one downloading the song – is able to generate the downloadKey without any meaningful communication to the Music Store. The answer is right in front of us, it’s just hidden. Security methods that allow the “attacker” to hold all the pieces of the puzzle tend not to stay secret.
• The hash is not an MD5 of the timestamp, nor is it an MD5 of the song itself, as it has not even begun to download at the time of the image request.
• Both the timestamp and hash change each time the same song is downloaded. The timestamp’s reason for changing is obvious.
• Unix timestamps can be quickly converted to a readable date by doing php -r "echo date('r',1154640230);" in the Terminal.
• It appears that the full size artwork must be requested prior to the song download, as it is then applied to each finished transfer. One would expect that the artwork is already in the songs, but it must not be if it’s being requested independently.
• References to an MD5 function exist all around every instance of “downloadKey” in the iTunes binary. Apple is either most definitely using MD5 for a hash, or they are going to an awful lot of effort to create a wild goose chase. My bet is on the former.

Here are a two downloadKey strings for those interested in pursuing this topic further: 1154640230_abe417e7d789521ccd1ccb355b23775a 1154667369_c0d7aa281b0b0247e094c194ed360659

Short of disassembling iTunes, which is out of my skill level, I think this is far as I can go. Hopefully someone with more skill can pick up here. For now, I’ll have to resort to Amazon and Google Images for album art sources.

I love Apple’s new MacBooks and would be selling my PowerBook right now in order to help cover the cost of a new portable, but I simply can’t get over the glossy screens Apple chose to install. The MacBook Pro line at least has the built-to-order option of a matte screen, but the “consumer” level MacBook has none. As the glossy LCD is really the only factor stopping me from shelling out for a new notebook this very second, I think it may be time to take matters into my own hands.

After doing some searching, I discovered that LG-Philips manufactures the glossy MacBook LCDs. This shouldn’t have come as a surprise, as Apple uses LG and/or LG-Philips LCD panels in most, if not all of their computer products. The particular model used in the MacBook is LP133WXT, which appears to be a very new model, as a Google search turns up only the page linked to above.

The hack comes into play here, if you search for the first part of the LCD model, LP133, on eBay. To get better results, search for LP133*, where * is a wildcard. This search turns up a number of matte 13.3” LG-Philips LCDs for auction, mostly from PC notebooks. As the glossy and matte versions are both manufactured by the same company, are the same size, and (more than likely) take the same power, I’m betting that the LCDs would be swapped with no ill effects.

I’ll keep my eyes open for more information as I save up some extra cash for a MacBook. Maybe if I wait, Apple will add the matte option in the near future…