Aaron Adams’s Lame-ass Blog

Here’s what I’d like someone who knows how to use Photoshop to do for me:

Start with a Finder window. In the the side bar at the left, make a heading for CONNECTED and SERVERS, with disclosure triangles. Put a few machines under each heading.

In the content area of the window, where files and folders are shown, put a screen capture of a Windows desktop.

In the title bar and tool bar up top, add a button set like the CoRD picture two posts down.

Ta da! There’s the new Microsoft RDC interface. Not hard.

Your reward for creating this graphic will be my thanks, and I’ll post it on the page. Bonus points for a properties window (invoked by command-i, of course) showing the settings for each connection in the side bar.

By amazing coincidence, Microsoft released RDC beta 2 today with “multiple sessions redesigned and improved“. And they are so sooo close, but they still don’t quite have it right.

There is a File… New… option to open… a new copy of RDC! That’s better but it’s not right. I can’t think of any other app (at least the ones I use) that start another instance of the application to make another connection or open another file. Those apps simply open a new window as part of the already-running application. My Dock is crowded enough without half a dozen identical icons to the right side.

Why can’t Microsoft figure this out? I don’t understand the logic behind their approach, and as much as I hear from the Mac BU how much they love the Mac just like we do, I can’t fathom why they have this so wrong, because it’s obvious they don’t understand some basic things. In the upcoming Office 2008, will opening multiple Word documents or Excel spreadsheets cause a second instance of the respective application to open? I sure hope not. Will composing an e-mail in Entourage cause a second copy of Entourage to be launched? I doubt it. So why does RDC behave this way? Does their RDC development team actually use Mac OS X?

It would also behoove them to create a sidebar, like CoRD has, (It actually has a drawer, I know.) where saved connections can be selected quickly, you can see at a glance what connections are active, and you can manage settings for each individual connection. This business with having to save individual files for each RDC connection is dumb. They need to create a folder, ~/Library/Application Support/Mirosoft RDC, and write a plist file containing the settings for the connections to be shown in the side bar. I’m not a Mac developer, and even I understand how this is supposed to work.

There are some other improvements in this beta, but because I so often need multiple connections open, those improvements mean little to me because the basics of this app are so messed up.

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.