If your iPhone was connected to an Exchange server for email, contact or calendar synchronization prior to your upgrade to the 3.0 software, you may have run into the same problem that was bugging me for a day or so: the timeout on the passcode lock gets set to "Immediate," forcing you to enter the code almost every time you pick up the phone. Secure, sure, but very annoying. Going to the usual settings location to adjust the timeout shows no choices other than the insta-lock; what to do?

A thread on the Apple discussions boards points to the answer. Since the ActiveSync link to the Exchange server controls some security policies on the phone, you need to refresh those controls; the easiest way to do that, short of deleting and recreating the Exchange account, is to turn off all three sync modes and the Push setting. Once that's done, you can go back to the passcode lock screen and disable the lock or adjust the timeout. Put your sync settings back the way they were and your changes to the passcode config should remain in place.

While this is an annoying quirk, it's not all gripes and grimaces in the Exchange support department. At long last, users of Exchange calendars can send meeting invitations (hallelujah!); Exchange 2007 users can even view the reply status of attendees. Users can specify additional mail folders for sync, and Exchange 2007 users can search server-side mail from their devices.

For a full rundown on the enterprise-friendly features of iPhone OS 3.0, check out the Enterprise Integration guide via Apple's enterprise features page.

Thanks to everyone who sent this in.

This vulnerability is patched in the 2009-001 security updates.

When reports of security issues in Apple's Safari browser come over the transom, they get our attention. When they're exploitable in both the Mac and Windows versions of Safari, they get our full and undivided attention. When the person reporting them is Brian Mastenbrook (credited with discovering multiple previous vulnerabilities in Mac OS X)... well, someone shut off that damn klaxon and let us get back to work. In this case, the issue is that a hole in Safari's handling of RSS feeds could allow an attacker (via a malicious web page) to capture a user's personal information, cookies or even passwords.

While Brian has not posted more details of the vulnerability publicly, he has acknowledgment from Apple that the issue exists; hopefully we will see an update soon that closes this hole. In the meantime, although Windows Safari users are advised to use a different browser to avoid the vulnerability, Mac users can simply set an alternative RSS feed handler to work around the issue.

Update 1/14: Per Brian's further research, the workaround below is not adequate to protect against the vulnerability, as Safari also handles URL types of 'feeds' and 'feedsearch,' which cannot be set to alternative handlers within Safari itself. The revised workaround calls for the RCDefaultApp preference pane, which does let you redirect the other URL types.

To change your feed handler, go to Safari's Preferences and click the RSS button. If you have any other capable feed reader on your machine, you can select it from the list (if your menu looks like mine does in the screenshot, you have a serious problem with RSS reader addiction and you need immediate help). Don't have another feed reader available? NetNewsWire and NewsFire (and the open-source Vienna, cited repeatedly by our commenters) are free for the downloading, as is the Reader Notifier helper app that interacts with Google Reader -- for the purposes of getting around the vulnerability, it doesn't matter which application you choose as long as you don't leave it set to the default of having Safari do its own RSS chores. Note that the vulnerability apparently does not require you to open a feed in Safari to be affected -- a specially-constructed webpage is capable of triggering it.


RCDefaultApp settings for "feeds" and "feedsearch" also need to be modified.

Thanks to Brian for the heads up & everyone who sent this in.