It’s time, once again, for the annual love-fest that is WWDC and that starts next week. I’ve been to each one since the iPhone launch (I know, that makes me a relative newbie) but having spent a good chunk of the past two decades living in San Francisco, I figured I’d combine tech-tips for first-time attendees with social things to do for out-of-towners.

Tech Tips

• You can register and get your badge on Sunday, the day before WWDC starts. That saves you a bit of time doing it on Monday when everyone stands in line to get into the keynote speech. If you do go in on Sunday then you may want to pop into sfMacIndie at Jillian’s in the Metreon at 6pm. It’s across the street from Moscone West. Grab a drink and chat up fellow developers. You may want to pace yourself. The next day is the big event and you want to be able to get there early — at least by 8am if not sooner. They don’t start letting you in until 9:30am so wear comfy shoes. Make sure to say hi to fellow line-standers as you hop from foot-to-foot trying to stay warm.
• This is San Francisco. In June. This means chances of early morning sun are slim to none. Standing in line for the keynote means no moving for hours in the cold, blowing fog. Unless you’re seriously thick-skinned (like the poor, freezing iPorn girls of last year) bring layers and be prepared to discard them as the day wears on and temperatures rise.
• The on-screen keyboard on the iPad is nice, but don’t forget your laptop. You will want to take notes. Lots of notes. And fast. As Marco Arment says WWDC is one giant info-dump and there is no way to absorb everything. You’ll need a real keyboard to keep up. I like to create separate folders for each session and save note files in TextMate. Under each folder you can also save sample code for the sessions. Then I throw the whole top-level folder into TextMate as a project so I can quickly search and find what I’m looking for. I suggest you try to capture as much as you can while there and take time later to go over things. They were pretty quick about posting up the videos of each session last year, but there’s no replacement for one’s own notes.
• Head down to the lunch area on the ground floor around noon. The food’s nothing to write home about (yeah, I’m being polite) but it’s a good chance to meet people and find out common interests. Most of the other times you’ll be standing in line or in-session. This is your chance to have a decent conversation and who knows, learn a thing or two from fellow developers. I’ve always enjoyed these random encounters.
• If you have questions or want to get feedback from Apple engineers and designers, sign up for the labs and do it early. Spaces fill up fast, especially for the UI Design reviews. Drift down to the cafeteria area on the ground floor and find out what the sign-up protocol is. On the rare occasion there isn’t an interesting session, hover around the lab areas. You’ll pick up great info just by listening to Apple folks explain how things work.
• Try to bring a Verizon or Sprint MiFi. The Apple-supplied WiFi network is OK, but most of the time it gets overloaded. Forget AT&T’s 3G network. It’s a joke. With most people carrying a MacBook, an iPhone, and an iPad, your best bet is to bring your own network. The downside to this is you probably won’t be able to access the WWDC attendee-only content accessible to those on the network there. But once you’ve snagged all the goodies you can switch back to your own network and zip along. [Update: OK, maybe not such a good idea if everyone turns them on at once.]
• If you bring your own network, make sure you set a secure password for access to the wireless hub. And for crying out loud, don’t make it the 40-bit WEP. Go for the WPA2. Way too many people running Wireshark or Kismet out there. Also, while you’re at home set up all your network devices to log in, then set the hub to not broadcast its SSID. That way all those other people around you won’t have to scroll through a gajillion wireless hotspot names.
• Bring a comfortable backpack. The one they’ve been handing out to WWDC attendees the last few years is pretty minimalistic. If you need space for all your gear (and an extra sweater) then bring your own. Don’t worry about food, unless you need to snack often. They provide bagels and cookies and whatnot to keep you fueled up.
• Sync up your dev iPhone or iPad at home and back everything up. There’s a good chance there will be a new SDK drop there with a bunch of new goodies. Recommend you not try to download over the WiFi. Walk over to one of the round tables outside the session rooms and plug into the Ethernet firehose. Much, much faster.
• Please, oh please remember to turn down the volume on your phone/iPad/Mac during sessions. Yes, you know you’re on Twitter and now we do too. You can thank chirping bird man for that.
• If your backside is sore from all the sitting down or you feel like taking a quick nap, there are bean-bags on the top floor. First come-first serve.
• If you’re looking for a job or have a job to post there are white-boards in the bean-bag lounge area.
• Stash a power-strip in your pack — it’s a good way to make friends.  Among tech conferences WWDC is one of the better ones for providing power to attendees. Even so, they sometimes run out of plugs. I’m partial to the Monster Outlets to Go units. They’re small and you can charge up most of your devices in one sitting. Some models even come with built-in USB charging ports. While you’re at it remember to bring separate power-to-USB adapters for your iPhone and iPad. The iPhone is happy with the small 5W units but the iPad needs the beefier 10W adapters. If space is a premium you may want to grab a couple of retractable USB cables too.
• If you’re missing anything or forget to bring any hardware, your two nearby geek supply outlets are the Apple Store on Stockton Street and Central Computer on Folsom at 4th.

OK, so much for the conference itself. What about the social life?

Organized Events

Here’s a good reference for organized after-session gatherings: http://wwdcparties.com. On Tuesday between 7:30 and 10:30 pm, however, a lot of people will likely head over to the Apple Design Awards ceremony. A large number will stick around for the Stump the Chumps Experts session. On Thursday night Apple throws a bash in Yerba Buena Gardens. You’ll need your WWDC badge to get in. If you’re of drinking age you’ll need to get a wrist-band at Moscone before heading over. Pace yourself on the booze if you plan on hitting any other places afterward. You get all the food and beer you can consume plus a (surprise) live musical act. And there’s still Friday’s sessions left.

Quick Eats

If you get tired of eating pre-packaged sandwiches and are hankering for something slightly different, here are a few places within easy walking distance of Moscone. However, no guarantee they’ll get you in and out in time for the afternoon sessions:

• Food court at Metreon - Walk across the street, grab yourself something and go sit outside in Yerba Buena Gardens to decompress. Absolutely glorious if it’s sunny.
• Taqueria Cancun - Bit of a hike up on 6th and Market, but decent enough Mexican fare.
• Out the Door – (sorry, Flash site) is by the same people who run the outstanding Slanted Door in the Ferry Building. This one’s in Westfield (Nordstrom) shopping center on Market and 5th.
• Specialty’s – Great sandwiches. Best part is they have an iPhone-friendly ordering service. Closest one is on New Montgomery between Mission and Market.
• The Sentinel – I haven’t eaten there yet, but people keep recommending it and it’s top of my list for lunch places to try. Fancy-looking sandwiches.

Coffee

The swill they serve at WWDC may be fine for getting you over your previous night’s hangover, but you owe it to yourself to get some decent coffee while in town. Good places within walking distance:

• Blue Bottle - Just go. Get the Latte if you’re in a hurry or the drip coffee if you have time. Don’t worry, it’ll make sense once you get there.
• Peet’s - Closest one is on Mission between 3rd and New Montgomery. Strong coffee. Puts hair on your chest, whether you want it or not.
• Chatz - Bit of a hike on 2nd Street between Howard and Folsom, but good place to go if your feet need some stretching.

Local Watering Holes

For some reason after a day of technical brain-melding a lot of people are extra-primed to kick back and partake of adult beverages. Go figure. If that’s what you’re looking to do, here’s a number of local hangouts where you are sure to bump into fellow WWDC attendees:

• Jillian’s – It’s across the street, doubles as a sports bar, has a large selection of beers on tap, and has pool tables in the back.
• Thirsty Bear Brewing – Upscale brewpub. Decent beers and Tapas-style dishes, only a block away.
• Chieftain’s – Grungy Irish pub. First stop for a lot of die-hard old-timers before they inexplicably head all the way out to…
• Tommy’s Mexican Restaurant – A favorite of Apple folks, but it’s all the way out in outer Richmond. With places like Tres Agaves or dive bars like City Bar in the Mission you’d think someone would try to find something more accessible. It’s far away, in the fog zone, and the place is usually mobbed but if you do decide to head out to Tommy’s try to snag a ride with someone else–preferably a teetotaler. There’s a chance you’ll end up slamming tequila shots and trust me, you won’t want to be driving, flagging down a rare cab, or being at the mercy of Muni late at night.
• Harlot – Decent, but small. Odds are there will be a line to get in.
• XYZ bar at W Hotel – Upscale drink spot. Excellent place to hang out if you’re on a corporate expense account or your app just cracked the Top 10.

A little further out — but still worth it

Want to pretend you’re a local? Some are a bit of a walk, but if you get in with a group of fellow developers and want to get out of the Folsom/Howard zone, here are a few places to try (in no particular order):

• Johnny Foley’s - Irish Pub within walking distance. It can get a bit touristy, but there’s nightly live music and (natch) Guinness on tap.
• Zeitgeist - Sort of a cross-road of cultures and styles. No other way to describe it.
• Orbit Room Cafe - Best damn Bloody Marys in town.
• Hotel Utah - Grungy local spot, sometimes with good music.
• Bottom of the Hill - Great place for local live indy bands. Out in Potrero Hill (accessible via the Muni T-line) but the music’s usually worth the trip.
• AsiaSF - The waitresses double as transgender stage performers — and they’re awesome.
• 21st Amendment Brewery - Big with the local tech types floating around 2nd street. Decent brews.

Obviously I’m leaving a lot out, but this should give you a decent starting point. Feel free to post any corrections or favorites in the comments. Hope to see you all at WWDC. If anyone wants to look me up and say hi, I’m @raminf on Twitter.

Update: Added a few more places — for those in a hurry to get back to hacking and getting their mind blown.

I agree with most everything Karl Adam says about the limitations of the Apple Push Notification Service, especially the problem with its failure to stack notifications so they’re not missed.

I posted a bug report a while back (rdar://7054632) offering a simple solution to get around this particular problem: save each incoming push payload into Messages.app as a separate entry. That way if I get a push and don’t have time to get to it I can ignore it and come back to Messages later on and retrieve it and all received Push messages are kept until I choose to get rid of them.

The entry could be in the form of a special URL link that shows the alert message, but when clicked generates the same JSON payload format as a regular push event and invokes the app in the same manner so no extra coding would be needed (OK, maybe just a little bit of code on the server to check against processing duplicate requests). It would take care of a lot of problems with push usability.

An even more pressing issue I have with Push is if you are on a WiFi network behind a bunch of firewalls and more than one NAT server. This happens often in corporations or in homes with multiple routers acting as range-extenders. In these cases pushes fail to reach you — until you get back to a 3G network.

For some people Push is doubling as a remote event timer (since Apple won’t let us access the phone’s alarm database or submit local cron tasks). This makes it really hard to issue reliable time-based alerts.

If Apple would just open up true background tasks and/or timed alerts and let the user decide whether they trust an app to let it access those services (much like location-based or push services) a lot of these hassles would go away.

Also, a European friend brought up that whereas SMS is included in most phone plans, push incurs data usage charges. Could be a hassle if you’re traveling and continue getting pushes.

Over all, I’d say push on the iPhone is a work in progress. As much as I’m intrigued and excited by its potential, I’m frustrated by its current implementation and limitations.

Since Apple’s no longer going to be participating in MacWorld this is one of the few public conferences where Apple and its partners can make public product announcements. So now’s a good time to start floating outlandish rumors
predictions as to what’s going to be announced.

Since Apple already announced its intention to release iPhone 3.0 software around that time, a lot of products will be taking advantage of those features. One of them was access to the external USB port. The announcement demo featured a heart-monitor. My prediction is it will be totally upstaged by one of these:

One of the loudest complaints about the iPhone AppStore has been the lack of support for eval or demo applications. In the desktop world users can often download an application and use it for a period of time before deciding whether it’s worth paying for. But in the iPhone AppStore universe (where all transactions occur) there is no such support. Developers are then faced with the option of offering a lite version for free (or inexpensively) and a full version of their apps. The problem is that this still doesn’t allow the end-user to test out the full app and then choose to buy it if it fits their needs. And switching from a free to a full app involves installing an entirely independent application.

What we really need is a way to upgrade an eval app to the full version once the user decides the app is worth paying for.

Yesterday Apple publicly announced the developer release of iPhone 3.0 software (it won’t be publicly released until this Summer). To the dismay of many developers, there was — once again — no mention of support for eval applications among the 100 new features and “1000 new APIs.” So again, we are left without the option of letting users download an app, take it for a test run and then pay for it.

Or are we?

One of the features announced publicly was support for In App Purchases. This was presented as a way for users to obtain add-on levels or objects directly within games. The transaction (or more precisely, micro-transaction) still goes through the AppStore and gets charged to the same account. Despite public detractions I belive this is a Good Thing — especially since the feature can be used to legitimately support eval applications, even if the AppStore doesn’t officially support it yet.

Here’s how:

• Developer offers application for free on the app-store. This is a fully functional version (i.e. not lite or crippleware).
• User downloads and runs the application and is informed that the application is in eval mode and will stop working after a period of time.
• After the eval period (say, 1-4 weeks) the application puts up a notice indicating the eval period has expired. It can either stop working or drop into a degraded mode.
• At this point the user is given the option of performing an In App purchase of the full application.
• If user accepts, the application contacts the AppStore and purchases the add-on — which would be priced at what the full-price of the App would otherwise be. Once completed, the app downloads an add-on key indicating the app has been purchased.
• The presence of add-on indicates that the full app has been purchased and the timeout is taken out. All the application has to do each time it is launched is to look for the presence of this add-on.
• Everyone’s happy.

There’s a key assumption here — that the AppStore keeps track of already purchased In App purchases the same way it does with full applications today. In other words, if the user tries to re-download an In App purchase that they’ve already purchased with the same iTunes account, they shouldn’t be charged twice. If a user deletes the app or moves to a new phone, all they have to do is download the free version of the app, perform another In App purchase (for free this time) and off they go.

However, if this assumption is not true and In App purchases are tracked separately than full applications (or the application itself is responsible for keeping track of those transactions) then the developer will have to implement a way to track In App purchases that works across multiple app installs — most likely a simple web-server to keep track of eval vs. purchased apps. Let’s hope it doesn’t come to that (the documentation on the Store Kit is not out as of this writing and even if it was, developers under NDA won’t be able to talk about it publicly until the public release of the 3.0 software).

There are some other issues that need to be hashed out, mainly what happens if unscrupulous third-parties find out what this add-on looks like and make it available for free download? The iPhone application sandbox makes it a non-issue since only the application itself is allowed to write to its Documents directory or modify its user settings — unless the phone has been jailbroken, in which case the concerned developer may want to support more complex security (like cryptographic signing) for the add-on. Given that the AppStore DRM appears to be compromised using this technique does not significantly increase the risk of software piracy.

Another potential issue is the user who downloads the fully functional eval version, uses it for the full eval period, then deletes it, re-download and installs it so they can get another free eval period. If this is an area of concern, it can be handled through a simple web-service that keeps track of how many times the same user has installed an app. Personally, I don’t think it’s worth the hassle given that deleting an app also gets rid of all user-generated data. But that’s me.

Note also that when I’m talking about downlaoding something, I don’t mean literally downloading a chunk of code, but some sort of token that takes away the eval time limit. The whole operation can be performed very quickly once the In App transaction is completed.

I firmly believe having support for eval apps is critical for medium to high-priced applications to flourish on the AppStore. A user will hesitate to fork out a high price for a full-featured app without having the option to kick the tires beforehand. This method can easily solve the problem and let developers do eval apps as soon as the 3.0 software is officially released.

Update: Apple has since announced that free apps can not use StoreKit. This is to avoid a potential bait-and-switch situation where the consumer downloads what they think is a free app and then get hit with a fee. However, I think it’s a misguided policy. A developer who does that will quickly get down-reviewed (if they even make it out of the app-review chute). A more likely scenario would be to allow users to use an app for a limited period of time, but give them the option to unlock the app for continued use.

Another more fundamental issue, however, is whether app developers even want an eval feature. I’ve heard from several Android developers that the Android store return policy has severely impacted sales of their apps. Their argument is that returns should be based on faulty apps, not because someone found their game too hard. Presumably, enabling eval apps will cut down on a lot of impulse-then-discard purchases that go on today.

Certainly a topic worthy of further discussion.

I spent all yesterday at Apple’s first iPhone Tech Talk in San Francisco (technically, Paris was first because of time differences, but we won’t quibble). After seeing the schedule of events (and having attended WWDC) my expectations for getting new technical information were pretty low.

Boy, was I wrong.

The talk itself was under NDA so I won’t go into details. But I’ll point at a couple of items in current examples and documentation that everyone should be aware of:

• If your app is using audio in any way, you’ll want to make sure you’ve read and understood the “Audio Sessions: Cooperating with Core Audio” section of the “Core Audio Overview” document (it’s part of your help document set in the SDK).

  Of special importance is making sure you declare the proper AudioSessionCategory for your app. Not doing it means that if your app uses sound (input or output) and gets interrupted — by an incoming phone call, or even by the user plugging and unplugging headphones — your app’s sound may not continue playing properly. There’s some example code in the SpeakHere example to help point the way.

  Here, by the way is what the documentation says:
  

  Ignoring Audio Session Services will not prevent your application from running, but your app may not behave the way you want it to. Never ship an iPhone or iPod touch application that uses audio without using this interface.

  You’ve been warned.

• If you’re using the accelerometer, you’ve probably seen the low-pass filter code in the docs and examples. The point of the filter is to smooth the effect of motion ‘jitter.’
  
  The thing is, the basic low-pass filter formula is — to put it mildly — non-functional (aka brain-dead). Again, I can’t talk about the specifics, but the presenter had graphs that showed how bad that formula behaves.

  Actual color graphs, I tell you!!!

  If you manage to get your hands on a sample iPhone Apple application called Touch Fighter — you’ll want to use the smoothing function there (the app was handed out in WWDC and isn’t part of the standard SDK example set).

  If you can’t find it, I suggest looking around for source code that handles the Wii remote (they have to deal with similar issues). At some point, I might post a more detailed technical article on this.

• Gesture management is still something that Apple leaves to individual developers, instead of including it in the SDK. I have a ‘swipe’ detection library (but it’s only for one-finger swipes, not multi-touch). If there’s demand for it, I’ll post it up.

  But really, this should be something supported in the OS.

Most of the TechTalks are full now. If you happen to have gotten accepted, don’t skip them. If not, get on the waiting list. It’s worth it. The sessions on game development and performance tuning are massive info-dumps. Might want to take a lot of notes.

P.S. That mod-squad picture on the web site (excerpted above) features actual Apple evangelism group members strutting their stuff

Since I do most of my development work on my laptop and so much of it entails running various types of servers locally, I set out to find something that actually kept snoopers out. A quick search led me to Intego Software and their NetBarrier product (Symantec’s Norton products don’t run native on the Intel CPU). There are people out there who don’t like Intego and their offerings, especially with the ‘hidden’ annual subscription fees associated with the software (now this isn’t unusual in the Windows world, but it’s something the folks at Intego should mention right upfront.) But I haven’t had any bad experiences with them. Besides, choices were few and I found a deal for under $60.

To be clear, most people at home connect to the Internet through a router that offers them NAT services which effectively blocks incoming connections. For those situations, a software firewall is overkill. But if like me, you spend a lot of time at public WiFi hotspots like coffee shops or away from known, trusted routers, then you’ll want to run a firewall to keep the legions of port-scanners out there at-bay. If you think you’re unlikely to be a victim of port-scanning, think again. Last time I set up a web-server with a static IP directly connected to the net, it took less than 15 minutes from the time the ISP turned on the tap to when the first port-scans came in. By the time I turned the server off a month later, the web-server log-file was chock-a-block full of known exploits and bizarre attempts at trying to break through — most of them through overseas IP sources and zombies.

But I digress.

At the 2008 Macworld Conference in San Francisco last week, Intego had a booth and they were talking about their latest X5 version upgrade. It looked interesting, but NetBarrier was full of features I didn’t personally care about (Cookie management while doing web-service development. No thanks!) When I got home, I ran across this Macworld magazine article that claimed the Leopard 10.5.1 upgrade had fixed a lot of the problems with the built-in firewall. So I set out to do some tests of my own. My primary test was for the situation you are most likely to encounter when you’re away from the comfort of your home router — to see if any TCP port on my machine was accessible from the outside.

First of all, to get around the NAT router firewall issue, I tried two types of tests: the first was a live test at a neighborhood coffee-shop running a standard Linksys router with no wireless security enabled. The other was with my Intel MacBook Pro running Leopard 10.5.1 and directly connected to the net via Sprint’s EVDO network. To do the actual port-scanning, I needed an external service and Steve Gibson’s excellent Shields UP! service fit the bill nicely. This service opens each port sequentially and prints out a color-coded chart indicating whether the port is open (red), it’s responding but closed (blue), or it’s in stealth mode (green) — meaning that it won’t even acknowledge that there is someone at the other end. Ideally, you want to have the output of Shields UP! be a field of green (all stealth). Blue squares are OK too, but certain port-scanners deduce from a reply that there’s a live machine at the other end and will keep scanning. Red boxes are really bad news, unless you’re running externally accessible services and have intentionally kept those ports open.

In my case, I didn’t want ANYTHING open, so I was looking for all greens. As a baseline, I turned off all firewalls and ran Shields UP! against my unprotected machine. Here’s what I got:

Yikes! Most ports were responding as ‘closed’ which meant that my my system was waving a red flag, saying I dare you to hit me with your best shot. Here’s the same scan, this time with Intego’s NetBarrier X4 firewall enabled, using the preset Client, Local Server setting. (I should also point out that NetBarrier correctly warned me about each and every port scan attempt until I told it to put the GRC server’s IP address on the trusted list):

Looks good. Everything stealthy. Now let’s disable NetBarrier and try it with Leopard 10.5.1′s built-in firewall. You access the firewall settings from System Preferences -> Security and then by clicking on the Firewall tab. The default is set to Allow all incoming connections (which gives us the mostly blue diagram above). I can understand why Apple chose to take this route. Security is often a balance between convenience and safety. Most users would be using their Macs at home behind a router or at work or school behind a firewall. These people would be protected against port scans by their NAT service (which effectively hides them from the outside world). A relatively smaller percentage visit open WiFi hotspots and of those who do, a very small number will find themselves sitting next to someone directly scanning their machine (the NAT service on the coffee shop’s wireless router will keep third-party scanners out). The only other population that would be truly at-risk would be those who run open servers with static IP addresses, and hopefully they know enough to go and manually enable their firewall.
So setting the default to Allow all incoming connections allows the significant majority of Mac users to hop onto the network and do their thing without having to muck with firewalls — which is as it should be. But if you’ve read this far, you (and I) are in the small majority of people paranoid enough to need better security.
Anyway, this is the default…

So let’s try the Allow only essential services option and run the port-scan:

Hmm. Not much different than the Allow all incoming connections version.
Now let’s try the Set access for specific services and applications option. The problem with this option is that by clicking the ‘+’ button, you are presented with the contents of your Applications folder. WTF! What about background services already running or items registered to launch under the launchd daemon? Obviously, if you want that level of control over your system, the simplified System Preference UI isn’t for you and should graduate to manually tweaking the ipfw configuration settings.

Moving along, we see an Advanced… button on the bottom right:

Which brings up a dialog box to Enable Firewall Logging as well as Stealth Mode. Aha! Let’s give that one a try.

And give it a go:

Eureka! It’s all stealthy goodness. That’s what we want.
In conclusion: if you are doing network development work under Leopard or spend a lot of time at public WiFi hotspots and have enabled sharing options on your laptop, you’d better be running some sort of software firewall. You can go with a commercial one (like NetBarrier) or use Apple’s built-in firewall, but only if you tweak it so it’s set to Stealth mode and it disables all incoming connections. If you do decide to go with the Apple firewall, I strongly recommend you also augment it with an outbound scanner like Little Snitch (NetBarrier also provides this functionality) to make sure you know which applications on your machine are ‘phoning home.’
Now a few caveats:

• We’re only looking at TCP ports here. I’m going to try to find an external UDP scanner and I’ll post the results. The UDP model behaves a little differently than TCP in that a closed UDP port is supposed to return an ICMP port unreachable reply. So by staying quiet, scanners may assume that the port is open (!) and redouble their efforts. Let me repeat that. Staying quiet means your port is active. But then, if you have a firewall and it’s blocking UDP requests, wouldn’t it be mistaken for the service being available? The answer is… Yes. It’s a little strange and most UDP scanners sheepishly admit to that effect. But for the sake of completeness, it’s important to look for both kinds of scan, especially for well-known services.
• The GRC test only runs up to port number 1055 which covers the most commonly registered services (other than UPnP which usually runs at 5000). TCP ports technically go all the way up to 65535 but at those higher numbers there’s no guarantee any service is going to run on a given port number. I also ran all the above tests using GRC’s Common Ports setting (which included UPnP) and got similar results.
• Intego’s firewall also scans the incoming content for what they call spyware, trojans, and cookies. There’s a little bit of poetic license being taken here. The most common methods for installing spyware and trojans on a machine is 1) through email or IM attachments, 2) if someone takes advantage of a flaw in your networked client (i.e. browser buffer overflow), or 3) if you download and run an infected application. I can’t tell from Intego’s material if they are, in fact, scanning for these vectors. If they are, good for them. But my guess is that what they’re doing is blocking spyware and trojans from going out, once they’re installed on your machine. If that’s the case, you get the same effect by installing Little Snitch and monitoring outbound communications. I’ll keep digging on this.
• Again, I’m most concerned with access to my machine while I’m out in the open and away from the comfort of my home firewall. If your use falls under that category you can choose to go with NetBarrier or Leopard firewall in stealth mode.

Regardless of the firewall you run, if you spend a lot of time at public WiFi hotspots, you’ll also want to make sure you’re running some sort of VPN to keep the fellow with the mysterious smile, nursing a cold coffee, sitting across the room from you and sniffing your packets with KisMac or NetStumbler. Try running these programs yourself some time. You’ll be amazed how much critical stuff goes across the wire in the open. If you don’t have access to a VPN server at work or school, I suggest paying for a publicly accessible one like PublicVPN or HotSpotVPN.

And I’ll leave it at that.