Archive for the ‘OS X’ Category

When a program has nothing surprising to say, it should say nothing.

Sunday, December 7th, 2008

Is there something about Windows that encourages developers to design shoddy user interfaces? I’m not sure if you can point to any one thing, but here’s a perfect example of what I mean. I don’t ever use Windows as a primary OS anymore (pure Mac and Linux for years now, never been happier), but I keep it around via Boot Camp for browser testing and gaming. When you plug a device in the audio jack while running Windows via Boot Camp, this is the message that pops up:

You just plugged a device into the audio jack!

Really?! Perhaps because I intended to use it?! Complete with the exclamation mark and all, as if it is some huge feat of ability. The message does nothing functionally, draws your attention and remains until you close it, and serves no useful or arguably informative purpose. Then, when you remove the headphones:

A jack has been unplugged.

I know, it’s painful and completely unnecessary. I can’t entirely blame Windows for this as the driver is a third party program by C-Media, but come on people. It’s time to sit down, get a nice cup of coffee and read two books before you design another user interface: Steve Krug’s Don’t Make Me Think and Donald Norman’s The Design of Everyday Things. If nothing else, just respect the Unix design philosophy, especially the Rule of Silence:

Rule of Silence: When a program has nothing surprising to say, it should say nothing.

Plug headphones (or a USB device, or monitor, or FireWire device, or external hard drive) into a Mac sometime. It Just Works!™ … no message, no gimmicky “device plugged in!” sound, it just does what you’d expect.

Apple Mail and Gmail IMAP: “Invalid Credentials” Fix

Sunday, June 1st, 2008

For anyone else out there trying to set up Apple Mail to check their Gmail account and getting an “Invalid credentials” error:

You may need to unlock CAPTCHA for your Gmail account:
https://www.google.com/accounts/UnlockCaptcha

Just go to that page, fill out your information and everything should work. I’m not sure if there are larger ramifications of doing this, but I suspect it’s not much of an issue. Any ideas on the security implications? Reading around on Google Groups and the Apple Forums it also seems like this issue may also affect the iPhone as well. I hope this helps if you’re having that issue.

Secure Screen Sharing in OS X Leopard Through SSH Tunneling

Wednesday, February 13th, 2008

Here’s a quick tutorial on how to secure the Screen Sharing application in Leopard by tunneling your connection through an encrypted SSH channel.

The new Screen Sharing application is basically just glorified VNC, but it does come with some nice features (dual-screen view, for example). However, just turning on the service will open up a couple of ports that may expose your system to exploitation.

WaterRoof MenuFirst, we’ll want to lock down your firewall. Leopard comes with two firewalls: ipfw (ipfirewall—the underlying Unix firewall) and an application layer firewall (the one that pops up sometimes and asks if you want to allow an application to accept incoming connections). You can manage the application layer firewall through System Preferences > Security > Firewall, but in order to block some ports we’ll need to set up some rules through ipfw. In order to do this, you can either learn the shell syntax (which isn’t terribly complicated) or use a GUI app to interface with it. I chose to use WaterRoof—a frontend open-source GUI for ipfw.

Once you have downloaded WaterRoof, run the application and click on Static Rules. Click the + icon to add a new rule, and use the following information:

Protocol: IP
Rule Action: Deny
Source: not me
Port or range: (leave blank)
Destination address, subnet, or network: me
Port or range: 5900
In, Out, or In/Out: Select the In radio button

This will block port 5900, the default VNC listening port that is opened when you start Screen Sharing. Also, you’ll want to block port 88 unless you are using Kerberos for authentication (I believe this is also opened by Screen Sharing and a couple of other apps). Add a new rule and use the same above parameters, but use incoming port 88 instead of 5900.

You should now have two new rules in your table:

deny ip from not me to me dst-port 5900 in
deny ip from not me to me dst-port 88 in

Click Tools > Rules Configuration > Save to startup configuration. Then, click Tools > Startup Script > Install Startup Script. This will make these new rules persist when you restart (otherwise, the system will reset to defaults on the next restart).

Open System Preferences > Sharing and enable the Screen Sharing and Remote Login services.

On your other Mac…

Now, from your client computer, open up Terminal and run the following (for reasoning, see the LifeHacker article Add More Functionality to Leopard’s Screen Sharing):

defaults write com.apple.ScreenSharing ShowBonjourBrowser_Debug 1

and (to enable quality control settings)…

defaults write com.apple.ScreenSharing \
'NSToolbar Configuration ControlToolbar' -dict-add 'TB Item Identifiers' \
'(Scale,Control,Share,Curtain,Capture,FullScreen,GetClipboard,SendClipboard,Quality)'

Finally…

Now, any time you want to securely connect to your Mac, all you have to do is type the following in Terminal:

ssh username@ip_address_or_hostname -L 5900:localhost:5900

Leopard Screen Sharing Application WindowThe -L flag is the key to all this—it enables local port forwarding and specifies that anything that happens on the specified local port will be forwarded to the given remote host and port (see the man page for more info). The format of the -L option is port:host:hostport so the first 5900 is your local client port, the next option is the host to which to forward, and the third is the remote port. It’s slightly confusing at first, but this localhost isn’t the client you’re connecting from, it is the remote computer to which you are connecting—it means that when the remote host gets forwarded data, it won’t pass it on to some other host.

Now, leave that terminal window open and open up /System/Library/CoreServices/Screen Sharing.app (you can drag it to your dock).

In the connect field, type localhost:0 (don’t forget the :0). The last part is important because it means to connect to display zero, which translates to port 5900 in VNC land and, for some reason, Leopard will tell you that “You cannot share your own computer” if you type in just localhost (though, you actually can by enabling Screen Sharing and typing that same host, it just creates an pseudo-infinite loop of VNC windows).

Once you type in your username and password, you’re done! You can now control your computer remotely through Leopard’s Screen Sharing app over a tunneled SSH connection. Here’s an example of the Screen Sharing interface (notice the nice dual-monitor support):

Leopard Screen SharingAlso, because Screen Sharing uses VNC as its base protocol you can interface with your Mac from any Linux, Mac, or Windows VNC client by port forwarding in the same way (on Windows, you’ll have to use an SSH client like PuTTY) and connecting to localhost port 5900 with any standard VNC client.