Aaron Adams’s Blowhard Blog

This is CoRD.

It is free. The interface is better than your RDC client by leaps and bounds. How is it that a freeware developer understands the basics of how a remote control app should work, and the coders at Microsoft do not?

CoRD is a Mac OS X remote desktop client for Microsoft Windows servers using the rdp protocol. It is easy to use, fast, and free for anyone to use or modify.

You even have the CoRD code to start from. Improve it. There’s no excuse for the stupid RDC client you have now.

1. What is this?
2. Make it go away.

The Back to my Mac security semi-issue reminds me of something that happened at my last job. I don’t feel like writing out all the details, but you’ll understand the point.

A senior employee shared her password with another employee who was then released, and the released employee created a security incident. When this was brought to the attention of the network admin team (me and one Other Person), we had two ideas for preventing the problem in the future.

Long ago, I learned to differentiate between technical problems and personnel problems. This case definitely seemed like a personnel issue to me: If you share your password and we find out it causes a security incident, you’re fired. Don’t share your password.

The Other Person, however, had a different idea. This is where it gets hairy. Originally, there were two different checkpoints where the released employee would have been prompted for a password. The senior employee had used the same password for both checkpoints, so getting past them was easy. The Other Person decided that the senior employee’s password for checkpoint one should be reset to something else, and then her software set to automatically login to it. The password for checkpoint two should be changed, but without automatic login. Then, senior person was expected to forget the password for checkpoint one, thereby disabling her from sharing it, and all was secure.

Let me state that again in case you didn’t catch it: It was considered good security to set a password a user was supposed to forget so she couldn’t share it.

I resisted this idea. The real issue here was that someone shared a password when they shouldn’t have, and that was being completely ignored. We could layer a thousand passwords throughout the network, and if she shared every one of them, we’re right back to the beginning. Again, not an issue with technology, but an issue with personal behavior. The solution was to make it clear to this senior employee that sharing her password again would result in termination.

No. The Other Person wouldn’t hear of it. There must be a technical solution to this problem. I tired of arguing because I knew the people just above us would agree with him and order it done because of the buddy system that existed in that office. And I was right.

Some time later, the Other Person was promoted to management (surprise!) and I left the company for greener pastures.

What does this have to do with Back to My Mac? If I’m reading the descriptions correctly, only users that have entered their .Mac passwords into accounts other than their own are affected. If you’ve kept your .Mac password contained in machines and accounts that are under your direct control at all times, there’s no issue. I wanted to use this story to illustrate that the real security failure is not a lack of authentication layers (even ones you’re supposed to forget), but a lack of password-handling sense.

Back to My Mac will apparently, by design, let a user control or observe your machine if they know your .Mac password, with no local password needed for the machine being controlled.

This is security 101 people:

1. Always use a strong password.
2. Once you have a strong password, never share it.

Could Back to My Mac be more secure? Yes. Is security only Apple’s job? No, it’s yours too. Don’t be the low-hanging fruit. Choose a strong password and keep it secret, always.

Somewhere in the foggy back end of my mind, I seem to remember a demo of stacks where Steve(?) took files from a number of different folders and placed them onto a stack in the Dock, creating a collection of related files that can be located anywhere in the file system. Pictures related to an event, located in the Pictures folder, could be stacked with a PDF related to the event, located in the Documents folder. That seemed damn useful to me.

Now, at release +16 hours, I read this in Help:

Folders in the Dock are called “stacks.” A stack can be a handful of documents, a group of applications, or a set of folders—anything you need to use frequently. When you click a stack, it springs open in an arc or a grid, depending on the number of items.

The Dock comes with two stacks already in place: the Downloads folder, where items you download from the Internet are stored, and the Documents folder, the default location for new documents you create. You can add more stacks by dragging folders to the Dock. You can create as many stacks as you like.

And indeed, through my own experimentation of dragging files to the Dock, stacks don’t work the way I remember them. (And the help explicitly says, “dragging folders to the Dock”.) Reading the help, it seems like stacks are an improved way to view the folders we’ve always had.

1. Am I hallucinating a previous demo of Stacks that never happened?

2. If the demo I remember really did happen, when were stacks dumbed down, and why?