Apple Special Event Coverage — This week’s issue goes out a day before an Apple media event on 28-Feb-06, and although we could prognosticate until our keyboards break under the strain, we’ll instead do the sensible thing and report on Steve Jobs’s announcements in ExtraBITS shortly after they happen. [JLC]

<http://www.tidbits.com/extrabits/>

Next time I visit Cupertino, I’ll be looking to see if Apple has co-opted one of those McDonald’s signs touting the number of burgers served to advertise the number of songs sold on the iTunes Music Store. If such a sign existed earlier this month, it would have had to add an extra digit on February 23rd, 2006, when the iTunes Music Store sold its one-billionth song (that’s an American billion, not a British billion, though you probably would have assumed as much).

<http://www.apple.com/pr/library/2006/feb/ 23itms.html>

<http://www.askoxford.com/asktheexperts/faq/ aboutwords/billion>

That one-billionth song was "Speed of Sound" from Coldplay’s X&Y album, purchased by Alex Ostrovsky from West Bloomfield, Michigan. For clicking the Buy button in iTunes at just the right moment, Alex won a 20-inch iMac, 10 fifth-generation iPods, and a $10,000 gift card to the iTunes Music Store (I have this great mental image of the guy being presented with an iTunes Music Store gift card the size of a sheet of plywood). Apple also established a scholarship in Alex’s name to the Juilliard School of Music to commemorate the one-billionth sale.

Apple’s milestone press releases are doubly interesting because they usually contain additional information about the contents and sales of the iTunes Music Store at the time (Wikipedia appears to collect much of this information, though I’d be interested to see a graph of the sales as well). For instance, the iTunes Music Store has sold more than 15 million videos and currently contains roughly:

• 60 television shows
  
• 3,500 music videos and short films from Pixar and Disney
  
• 16,000 audiobooks
  
• 35,000 podcasts
  
• 2,000,000 songs
  

<http://en.wikipedia.org/wiki/ITunes_Music_Store>

As the Macintosh has matured over the years, some people moved on, and the Mac world was the poorer for it. But one familiar face from the days of yore has been popping up again lately: ex-Apple evangelist Guy Kawasaki. Guy is a managing director of the Garage Technology Ventures venture capital fund, and he was all over Macworld Expo in San Francisco showing off FilmLoop. It was great to see him back in the Macintosh community again, and thanks to the blog at the very end of 2005, I think he’ll once again be something of a public figure.

<http://blog.guykawasaki.com/>

In classic Guy fashion, this isn’t Just Another Blog (its tagline is "Blogger. n. Someone with nothing to say writing for someone with nothing to do." Ouch). Instead, Guy’s blog is filled with the kind of practical wisdom he’s been dispensing in his books since the days of "The Macintosh Way." His more recent books have, needless to say, taken a bit more of the venture capitalist point of view (hence the titles: "The Art of the Start," "Rules for Revolutionaries," "Selling the Dream," and "How to Drive Your Competition Crazy.") but they’re amusing, insightful, and useful for almost anyone starting a new project, giving a presentation, or trying to figure out how to stand out from the crowd. Guy’s blog postings have exactly the same qualities, and the blog format may actually be a more effective presentation method for some of his ideas, since they come in small, periodic chunks. Much as I like Guy’s books, I find that I read them, get all fired about implementing some of his ideas, find myself snowed under by some project, and never get around to doing what I’d planned. Perhaps the constant nudges from Guy’s blog will actually cause me to think and act.

(And if you’re new to the Macintosh world and haven’t the foggiest idea who Guy Kawasaki is, pick up a copy of "The Macintosh Way" and read it – used copies are about $5 on Amazon and the blog has links to all of his books.)

One area in which Guy has long excelled is in community building. He was always a huge supporter of user groups within Apple, and in fact, I chatted with him in-between our talks at the User Group University (the attendees were all user group leaders) the day before Macworld Expo in San Francisco. I’d just finished speaking to the group – along with Chris Breen and Bob LeVitus – on how user groups can revitalize themselves and stay relevant in today’s age, so it was particularly interesting to see Guy’s recent post on community building. Excellent points, and the comments are also equally as worthwhile for anyone interested in user groups or just bringing people together. [ACE]

<http://blog.guykawasaki.com/2006/02/the_art_of_ crea.html>

A potentially critical security flaw has been uncovered in Apple’s Safari Web browser, which may enable attackers to execute arbitrary Unix shell scripts on a user’s machine simply by following a link on a Web site. Apple has yet to comment or release a patch, but in the meantime, we’d urge Safari users to disable the "Open ‘safe’ files after downloading" option in General pane of Safari’s preferences. (In fact, we’ve recommended disabling this option since May 2005, when a weakness involving Dashboard widgets was discovered).

<https://tidbits.com/getbits.acgi?tbart=08119>

The root of the exploit involves the way Mac OS X determines which program should launch files of a particular type. Under Mac OS 9, applications were associated with files using four-letter creator codes stored in a file’s resource fork; under Mac OS X, applications are associated with file via a more arcane system involving metadata and a file’s extension. By renaming a Unix shell script to a "safe" extension (like .pdf, .jpg, etc.), setting the script file’s executable bit, and compressing the script with the Zip archiving utility, Safari will happily download the script, decompress it, assume the script is "safe," then blithely pass it off to the Mac OS X Terminal application for execution. An attacker could easily use such a script to delete a user’s home directory, damage the computer’s configuration, or obtain personal data. (For more information, see Matt Neuburg’s "Of Files, Forks, and FUD" elsewhere in this issue.)

Safari is the only Web browser known to be affected, although it is possible other programs could be vulnerable to similar attacks. The Camino and Firefox Web browsers are not vulnerable to this particular exploit.

Danish security firm Secunia has listed the flaw as "extremely critical," and has posted a harmless sample exploit of the flaw so users can test if their systems are vulnerable. Heise Online has another demonstration of the exploit.

<http://secunia.com/advisories/18963>

<http://secunia.com/mac_os_x_command_execution_ vulnerability_test/>

<http://www.heise.de/security/dienste/ browsercheck/demos/safari/Heise.jpg.zip>

Users may also be able to protect themselves from the exploit by removing the Terminal application from its default location in Applications > Utilities. (However, doing so may confuse future system updaters, so users would probably have to remember to put it back before installing new software.)

By default, Safari’s "Open ‘safe’ files after downloading" option is disabled on new Mac OS X 10.4.5 installations, so many users may be safe from this exploit by default. However, merely running Mac OS X 10.4.5 is no guarantee of safety: we’ve confirmed systems updated to Mac OS 10.4.5 from earlier versions may well leave Safari’s "Open ‘safe’ files after downloading" option enabled. So, to be safe, check that the option is disabled on your system regardless of the version of Mac OS X you’re using.

As a level-headed, rational reader of TidBITS, you have, I trust, resisted being swept away on the wave of fear, uncertainty, and doubt spread this past week with regard to the latest variety of Mac OS X security holes to gain wide attention (see Geoff Duncan’s "Significant Safari Exploit Discovered," elsewhere in this issue, for more details). The mass media, not unexpectedly, have eliminated from their "reporting" all historical perspective and technical details in favor of block-busting headlines whose actual semantic content ("Mac OS X has viruses!") is on a par with an inarticulate scream. And then there are the usual fear-mongering press releases from self-interested companies. Let us, however, ignore the hype and consider the facts.

Open Sesame — Those facts mostly involve how documents and applications are associated in Mac OS X. When you look at a document in the Finder, it has an icon supplied by the application that opens it. When you double-click the document, that application is launched and opens the document. How is this association maintained?

Back in the days of Mac OS 9 and before, the answer involved metadata invisibly stored in the file system and looked up through an invisible database. When Mac OS X emerged, though, Apple set out to supersede this architecture with those obnoxious little file extensions that appear, visibly or otherwise, after a period in the name of the file, along with a complicated series of strategies for locating the associated application.

<https://tidbits.com/getbits.acgi?tbart=05415>

<https://tidbits.com/getbits.acgi?tbart=06584>

<http://arstechnica.com/reviews/os/metadata.ars/ 8>

Apple thus suppressed an elegant method of performing document-application associations, one that worked reliably (barring the occasional need to "rebuild the desktop" when the association broke down) and was invisible to the user, in favor of an ugly and often unpredictable system of incorporating a file’s type into its name merely because that’s how other operating systems do things. Except that they didn’t completely suppress the earlier method; instead, they incorporated it into an uneasy Jekyll-and-Hyde alliance. For one thing, a file left over from the pre-Mac OS X days might well have no filename extension. So a file might have type/creator metadata, or a filename extension – or both.

But there’s more. Consider the problem of a generic file type, such as .pdf. Both Preview and Adobe Reader can open a .pdf, so which of them should open this particular .pdf file? You, the user, might answer that question on a one-time basis by dragging the file onto the desired application’s icon in the Dock or the Finder. But what if you wanted to assign the file to one application or the other, so that it would always open with that application when double-clicked in the Finder?

For reasons that aren’t entirely clear to me, Mac OS X does not use the type/creator metadata to handle this situation. Instead, Apple instituted a slot in the resource fork – the ‘usro’ resource – where the user’s custom file association is stored. Thus, when you use the Open With pop-up menu in the Finder’s Get Info dialog, you’re actually setting the file’s ‘usro’ resource. It’s possible for a file to end up with all three – a ‘usro’ resource and a metadata creator code and a filename extension.

<https://tidbits.com/getbits.acgi?tbart=07516>

Exploring the Exploitation — The trouble, it turns out, is that it is possible to misuse these pieces of information to generate a conflict. Such a conflict lies at the heart of the current set of security exploits. When you download and expand the demonstration file created by Heise, what you end up with is a text file containing shell script commands; but the file has a .jpg extension and a bad ‘usro’ resource. The extension determines the document icon (on my machine, it is a JPEG icon that comes from Preview), but the ‘usro’ resource associates the file with a different application, namely the Terminal. You can tell that in fact this is a Terminal document by examining the file’s Get Info dialog in the Finder.

<http://www.heise.de/security/dienste/ browsercheck/demos/safari/Heise.jpg.zip>

The fact that this inconsistency is possible is probably a bug in the system. Theoretically, the system ought to be able to detect that the ‘usro’ resource is invalid. When I test the user creator-assignment mechanism, I observe that the file, along with a ‘usro’ resource, gets an ‘icns’ resource which is labelled "Binding Override" and presumably is intended to be the document icon from the newly assigned creator. For example, GraphicConverter’s JPEG icon is different from Preview’s JPEG icon. But Terminal has no JPEG icon, because it doesn’t open JPEG files; and besides, the exploit needs Terminal to treat the file as text, not as JPEG. So the Heise file has no ‘icns’ resource, and this should alert the system that something’s wrong.

Stuff and Nonsense — The fact that the exploit involves a .zip file, which is expanded on your computer in order to generate the invalid document, is irrelevant. True, the document is expanded by either StuffIt Expander or Apple’s own application, BOMArchiveHelper; but these applications play no important part in the story, as they are merely reproducing, correctly, the bad file that was handed to them in the first place. It is also true that the .zip file, internally, is in a special format; but the same thing would apply to any file with a resource fork.

The role of Safari in the story should also not be stressed unduly. It is true that if Safari’s "Open ‘safe’ files after downloading" preference is turned on (which, for many reasons, it should not be), Safari will effectively open the downloaded file twice – once to unzip it, and once to open what it wrongly thinks is a nice safe .jpg file. But this is no different, really, from what you would do with the file in the Finder by double-clicking the .zip file and then the .jpg file.

It has also been observed that Apple’s Mail suffers from the same behavior as the Finder – that is, when this file is sent to you as an email attachment, Mail shows you a JPEG icon (as well as the .jpg extension), but opens the file in the Terminal if you double-click it. However, I’m fairly sure that this is the same behavior as the Finder’s, merely being displayed in another context.

Finally, there has been some misleading talk with regard to the fact that the file in question is an executable – it is a shell script, and its executable permissions are set so that when it is opened by the Terminal the script runs. That there is such a thing as a double-clickable executable shell script is nothing new; any text file with a .command extension and executable permissions will run in the Terminal when double-clicked, and this has always been true. (You might reasonably argue that it shouldn’t be true, and you might also not have been aware of the fact that it is true; that’s a different issue, which I’ll come back to in a moment.) And the fact that an executable can be communicated as a compressed file is nothing new either; were this not so, it would be impossible to send someone else a compressed application. Some reports have stressed the fact that the file has no "shebang" line, but that is a red herring; the exploit works equally well whether or not the shebang line is present.

Conclusions — My conclusion has two parts, and they both amount to an assertion that computer files, as Iago says of men, "should be what they seem, or being not, would that they might seem none."

In the first place, Mac OS X has never fully rationalized its complex scheme of document-application association, and now we see that there is in fact a bug in that scheme. Apple needs to get this straightened out, on the double, so that a file always looks like what it is.

Secondly, an executable, of whatever sort – from a Cocoa application bundle to a lowly executable shell script – is a very special kind of file, and it needs to be marked as such. Data that you read and code that you run are both files, but they are crucially different kinds of file; so executables should look and behave specially. Any file which, if merely opened, will itself run as code, should be "badged" in some prominent and suggestive manner. It might also help if the first opening of every executable were preceded by an alert. Apple did institute something like this after the URL scheme debacle, but they didn’t go far enough – an alert appears the first time you launch an application by double-clicking one of its documents, but not the first time you open the executable itself – whereas the entire problem, as we now see, is that you might not even know that this is an executable. This, when Apple fixes things so that executables can’t be disguised as JPEGs, will make the world a safer place.

There are few programs whose capabilities I’m more familiar with than iPhoto, thanks to the feature-by-feature investigations I run through every year when writing my "iPhoto for Mac OS X: Visual QuickStart Guide" book. As a result, it’s always fascinating to see what Steve Jobs demos when he unveils a new version of the program, as he did with iPhoto 6 during his most recent Macworld Expo San Francisco keynote. But as much as I’m usually dying to try the new features, I’m also desperately curious to see if Apple has changed any of the age-old annoyances in iPhoto. The last few releases haven’t helped much on the annoyance front, but I’m pleased to say that iPhoto 6 tackles four of them, while unfortunately ignoring two others and introducing new ones. But first, let’s look at some of the slick new features in iPhoto 6, which fall into two main categories: editing and sharing capabilities.

<http://www.apple.com/ilife/iphoto/>

Editing Enhancements — iPhoto has long had three modes in which you could edit photos: within the display pane, in a separate window, and in an external editor such as Photoshop Elements. To that collection Apple has added full screen editing, in which iPhoto’s interface disappears entirely, and the photo being edited appears at the largest possible size on the screen; a thumbnail pane appears at the top and a toolbar pane is at the bottom, both of which automatically appear and disappear like the Dock when you have Dock Hiding turned on. Full-screen editing, which you can set as your default action upon double-clicking an image, is extremely welcome, since iPhoto’s other interface elements often took up a lot of space that would have been better used for the image, and iPhoto’s separate editing window never remembered its size or position.

The full-screen mode does require a few changes to familiar interface elements. For instance, if you click the Info button, a transparent Info panel appears (since there’s nowhere for the normal Info pane to display). And if you zoom in, a transparent Navigation panel appears to help you scroll around in the image, since there aren’t any scroll bars (but a scroll wheel can still scroll the image up or down; press Shift to scroll left or right with the scroll wheel). My main complaint about full-screen editing is that taking over the entire screen takes additional time; on my dual 1 GHz Power Mac G4, I have to wait roughly 4 seconds before I can edit a photo in full-screen mode as opposed to 2 seconds in the main display pane. Plus, if you have two monitors and accidentally click outside of the full-screen view, iPhoto immediately returns you to organize mode, without saving any changes.

Although the Adjust panel remains the same from iPhoto 5, a new Effects panel with a 3 by 3 grid of buttons assimilates the B & W (black-and white) and Sepia buttons, offering six additional effects that you can apply to the current photo, along with a ninth button that lets you revert to the original look. The Antique effect looks much like the Sepia effect, but is a little less saturated and more elegant. The Fade Color and Boost Color buttons seem to work roughly the same as the Saturation slider in the Adjust panel, removing and adding color intensity. And then the three buttons in the bottom row of the grid all apply an oval mask to the image, letting the photo show through in the middle. Matte creates a white mask, Vignette uses a black mask, and Edge Blur blurs the photo underneath the mask. Apart from B & W, Sepia, and Original, you can click each of the buttons in the Effects panel multiple times to apply it in increasing amounts. You can also click different buttons to apply their effects additively; for instance, making a photo sepia, fading the color, and applying a vignette mask. I can’t yet tell if I’ll end up using the new effects, but it’s a little surprising that Apple didn’t include all of the effects in Photo Booth. And I’d really like to see someone figure out how make all of the Mac OS X Core Image effects available within iPhoto – BeLight Software’s free ImageTricks provides them as a standalone application.

<http://www.belightsoft.com/products/imagetricks /overview.php>

The addition of all these transparent panels creates one new annoyance. Although you can see through them, they still get in the way, making a second monitor especially welcome for storage. Once they’re placed on a second screen, iPhoto remembers their positions for the session, but unfortunately fails at that task between launches for the Effects and Adjust panels.

There’s one more significant aspect to full-screen mode that’s truly welcome: the capability to compare up to eight photos at once. Clicking the Compare button while already in full-screen mode displays the current photo and the next one side-by-side at their largest possible sizes. But if you select up to eight photos in organize mode and click the full screen button, iPhoto displays them all as large as possible in full-screen mode. You can click on one and use the arrow keys to display the next or previous image that’s not currently showing; more interestingly, you can use all the edit tools on each image or even delete the current one by pressing the Delete key. Comparing images thus becomes a great way to scan through your photos after import to see which ones are worth keeping; that’s especially true if you use your camera’s burst mode to capture fast action shots.

Because It’s Nice to Share — The other place Apple significantly enhanced iPhoto is in the sharing tools. The photo books that were iPhoto’s marquee feature from the beginning have been improved, with new themes, higher quality printing, and lower prices. You can also click a Play button when creating a book to display it as a slideshow. But what’s really neat is that books have spawned two new forms of print output: cards and calendars, both of which are laid out in very much the same way as a book.

Cards come in two formats: folded greeting cards and postcards. Greeting cards hold a single image on the cover, with text on one of the inside panels. Postcards can have one image on the front, with the back holding either a normal text block or the standard outline for an address and stamp. They’re as simple to create as you would expect, since the only options are the image to use, the text you enter, and the typefaces you choose (assuming you want to override the defaults). Multiple designs and backgrounds are available for each them. Pricing ranges between $1 and $2 per card, depending on card type and number ordered.

Calendars are more flexible. Along with the usual slew of themes and page designs within each theme, each changing depending on the number of photos showing, you can also drag photos to any day, making it simple to, for instance, put a portrait of family members on their birthdays. You can even add the photo title as a caption, but you must choose an adjacent box for the caption; it can’t overlay the photo itself. You can also add any text you want to a particular day. iPhoto can create calendars of between 12 and 24 months, add national holidays from more than 30 countries (exclusively, unfortunately, so you can’t have both U.S. and Australian holidays both showing), import calendars from iCal (a workaround for the national holiday exclusivity, perhaps), and show birthdays imported from Address Book. The calendars are gorgeous and are priced at $20 for 12 months, with each additional month at $1.50.

Steve Jobs made much of iPhoto’s new photocasting feature in his Macworld Expo keynote, and it’s an interesting feature. The basic goal is to enable iPhoto users to share photos – via a .Mac account – with people using either iPhoto 6 or a photo-capable RSS reader (like Safari). Photocasts must start from normal albums, not smart albums, but you can have them automatically update when the album changes. Photocasts can be accessible either to anyone or to just those to whom you provide the necessary username and password, but it doesn’t seem as though Apple is publishing public photocasts in any sort of a directory, so realistically, it’s unlikely that anyone would learn the URL to a photocast unless they were told by someone else.

Although I’m not a particular devotee of the popular photo-sharing site Flickr (where do people find the time to look at photos from random netizens?), others have put some effort into making Flickr RSS feeds appear in iPhoto (choose File > Subscribe to Photocast and paste in a URL). Frankly, the connection between the two still seems tenuous, but check out the sites linked below for proxy services that provide iPhoto with more than 10 images at once and the largest possible photos from Flickr based on usernames, sets, and tags (Photocastr worked the best in my testing).

<http://photocastr.com/>

<http://snosrap.com/photocast/>

<http://phlikr.3xi.org/>

Photocast albums are just plain weird. You can’t search in them or edit photos in them, and even more oddly, you can’t move a photo from a photocast album to your Library. However, you can move the photo to a normal album or use it in a calendar or book, and having done that, you can edit it. But it still doesn’t appear in your Library. The only way to have photocast photos appear in your Library is to delete the photocast album; iPhoto saves all the photos you’ve "used" and prompts you to save the rest by importing them into your Library at that point (and deleting photocast albums crashes iPhoto 6.0.1 about half the time for me). It remains to be seen just how popular photocasting within iPhoto 6 will become.

Other changes in the ways you share photos using iPhoto include the replacement of the .Mac HomePage integration with a connection to iWeb and a Zoom and Crop option when printing standard sized or full page prints (it essentially does the necessary cropping to get a photo into the right aspect ratio).

Annoyances, Real and Imagined, Fixed and Extant — At this point in time, Apple’s inability to fix what seem to be blatant problems with iPhoto has me almost questioning my judgment: am I the only one who thinks these irritations are worth fixing? Apparently the clamor hasn’t been loud enough to jog Apple into action, especially since I wouldn’t think any of these problems are at all subtle or difficult to resolve.

Most shockingly, iPhoto 6 still forces you to title photos and film rolls by typing in the Title field of the Info pane or panel. I’ve been incredulous for years that the iPhoto team seems incapable of learning from the Finder that it would be far more obvious and easier if you could double-click the title of the photo or film roll as showing, and rename it in place, just like in the Finder and everywhere else in the Macintosh interface.

I also remain surprised that no one within Apple has seen fit to make iPhoto more powerful than the Image Capture utility that ships with Mac OS X, at least when it comes to importing only a select set of photos from a camera, rather than all of them at once. Image Capture has had selective import since the early days of Mac OS X, so why is it that iPhoto, after five years, has been incapable of mimicking this obvious feature? (And while we’re on the topic of Image Capture, wouldn’t it make sense to enable iPhoto to control the "hot plug action" preference that launches a particular program when a camera is plugged in, rather than forcing people to hunt around for Image Capture to change it?)

On the positive side, Apple has done away with some truly unnecessary annoyances. Most notable among these is a preference in the Advanced pane of iPhoto’s Preferences window that enables you to import photos into iPhoto from a folder on your hard disk without copying the originals of those photos into the iPhoto Library folder. People have been whinging about the way iPhoto takes over imported photos since iPhoto 1.0, and now, five years later, Apple has finally ceded the point. Arguably, relatively few serious iPhoto users have managed to hold out and maintain a separate folder hierarchy in the Finder for original photos, making the feature a half-hearted concession, but I’m sure some will still appreciate it immensely. One note; although original photos remain in their original folders, modified photos are stored within the iPhoto Library folder’s hierarchy.

Speaking of the way iPhoto stores files on disk, that too has changed. Many people were thrown by the year-month-day folder approach taken by previous versions of iPhoto, so with iPhoto 6, Apple flattened the structure. Now there are three top-level folders in the iPhoto Library folder: Originals (for original photos), Modified (for edited photos), and Data (for thumbnails). Within each one are folders for each year, and within each year folder are folders for each film roll, named for that film roll (photos inside the film roll folders retain their original names; titles applied within iPhoto still exist only inside iPhoto). iPhoto 6 deletes the old hierarchy after upgrading your iPhoto Library to the new technique; however in the various upgrades I’ve performed, it has missed a number of photos and offered to "recover" them after the rest of the upgrade process is done. Take it up on that offer, since in my 10,000-image library, there were about 50 photos that needed recovery, and about 35 of them were not duplicates (search manually on the filename, using iPhoto’s Search field).

Another common complaint was that iPhoto could print contact sheets of photos, but had no option for including the photo titles, making the contact sheets almost entirely useless for the traditional functions of contact sheets. That’s now fixed; a checkbox toggles titles on and off, and you can choose the font used.

Last, but by no means least, Apple fixed another glaring mistake related to entering text in books. Although iPhoto has been a Cocoa application from day one, and has always supported Mac OS X’s built-in spelling checker, the Check Spelling As You Type option has always been off, and, if you turned it on while entering text in a book, it has maddeningly always turned itself off again once you switch pages or leave book mode. No longer; Check Spelling As You Type is now on by default, as it should be, and works wherever you enter text in books, cards, and calendars.

Should You Upgrade? Whenever I look at a new version of iPhoto, I’m considering the question of whether or not the improvements make it worth upgrading to the latest version of iLife. iPhoto 6 provides enough improvements and new features that anyone who uses iPhoto at all seriously will find them worthwhile, particularly if any of the other iLife ’06 applications are of interest. That said, if you don’t edit photos within iPhoto, and you don’t plan to order books, cards, or calendars, the new features in iPhoto 6 may not be worth $80 on their own; iPhoto 6 simply isn’t all that different from iPhoto 5 in truly important ways.

"Take Control of Podcasting on the Mac" Covers GarageBand 3 — Podcasting took 2005 by storm, but as many people quickly realized, it’s harder than it sounds. That’s why we released "Take Control of Podcasting on the Mac" last year and why Apple, in a move that wasn’t surprising, added a slew of podcasting-related features to GarageBand 3. But as anyone who has used Apple’s iLife applications knows, their documentation is sparse, which makes us particularly pleased that Andy Affleck has updated "Take Control of Podcasting on the Mac" to cover using GarageBand 2 or 3 to make a podcast. The ebook still covers Rogue Amoeba’s Audio Hijack Pro, of course (and comes with a coupon worth $3 off the program), and adds coverage of SoundStudio 3. Also new in this update is information about adding chapters to a podcast. The update is free to those who purchased the 1.0 version; just click the Check for Updates button on the first page of your copy of the ebook to download the update. For anyone who hasn’t yet scratched the podcasting itch, "Take Control of Podcasting on the Mac" costs only $10 and will help you make the most of that shiny new copy of GarageBand 3.

<http://www.takecontrolbooks.com/podcasting- mac.html?14@@!pt=TRK-0029-TB818-TCNEWS>

The first link for each thread description points to the traditional TidBITS Talk interface; the second link points to the same discussion on our Web Crossing server, which provides a different look and which may be faster.

DVD audio into iTunes? How do you record a snippet of audio directly from a DVD? Read on to learn several different methods. (6 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2902>

<http://emperor.tidbits.com/TidBITS/Talk/739/>

SMS Text Messaging Costs — Some folks in the United States pay more to send a text message from their cell phones that it would costs to make a call. How does this compare in other markets around the world? (8 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2903>

<http://emperor.tidbits.com/TidBITS/Talk/740/>

iPod nano as external storage device for beige G3 Macs running OS 9.2.2? Is it possible to use an iPod nano as a USB storage device for two Macs that aren’t running Mac OS X? (2 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2904>

<http://emperor.tidbits.com/TidBITS/Talk/741/>

Mac OS X 10.4.5 Fixes PowerBook Stuttering — Lost in the details of the most recent Mac OS X Tiger update is a fix for an annoying problem where audio input would go into a feedback loop. (2 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2906>

<http://emperor.tidbits.com/TidBITS/Talk/742/>

Are Input Managers the Work of the Devil? Matt Neuburg’s article last week detailing the exploit used by the Leap-A malware prompts discussion of the scope of the problem. (6 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2907>

<http://emperor.tidbits.com/TidBITS/Talk/743/>

Shell script exploit — TidBITS readers look at the latest security threat and whether Web browsers other than Safari are vulnerable. (16 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2908>

<http://emperor.tidbits.com/TidBITS/Talk/744/>