Maybe what gave some people a new injection of Internet ID-induced fear was the fact that the truly horrid SOPA and PIPA Internet censorship laws were in the news this week thanks to the #SOPAStrike Internet blackout (which I enjoyed participating in). Or maybe it was because the latest versions of the Internet ID specifications are nearing their release date, so everyone’s a little on edge.

Whatever it was, though, I think that fear is misplaced. Most of this fear seems to stem from a real misunderstanding of the way Internet identities (not just Internet ID itself) work. Like so many things involving computer network security, something like Internet ID can sound scary when you’re not up on the nitty gritty details—that’s nothing to be ashamed of. Knowledge is power, and lack of knowledge breeds fear.

But Internet ID, or more formally known as National Strategy for Trusted Identities in Cyberspace (NSTIC) is actually not something to be fearful of. In fact, it could be a really good step forward, one that many Internet security, privacy, and free speech experts seem pretty excited about. And, what’s more, they have been for quite some time.

For example, Kaliya Hamlin is founder of the Internet Identity Workshop and an Internet identity expert who’s formally weighed in on NSTIC. She’s also a personal friend and someone I greatly trust to handle these matters with a lot of care, specifically to people who express an alternative sexuality. She’s done so time and again.

But don’t take my word for it! Listen to her thoughtful inclusion of how Facebook’s privacy-degrading actions late in 2009 would affect closeted users on Kink On Tap Episode 21: Welcome to the Privacy Wars. Her fantastic year-old piece, National! Identity! Cyberspace! Why We Shouldn’t Freak Out About NSTIC is still highly relevant today:

Our main conference Internet Identity Workshop held every 6 months since the fall of 2005 has for a logo the identity dog: an allusion to the famous New Yorker cartoon On the Internet, nobody knows you are a dog. To me, this symbolizes the two big threads of our work: 1) maintaining the freedom to be who you want to be on the Internet AND 2) having the freedom and ability to share verified information about yourself when you do want to. I believe the intentions of NSTIC align with both of these[…].

As another high-profile example, computer and Internet security expert Steve Gibson also recorded a netcast that dealt directly with NSTIC and explained it in remarkably clear detail. He dissected the way it functions, why it’s useful, where it can be improved, and what the big fears about it were.

Gibson rightfully concluded the fear is largely due to ignorance of the technology and a general mistrust of the government, but that the technical specification as it exists today is so good as to actually prevent the majority of the fears being espoused by people like those I spoke with who have not actually taken the time to grok the specifics. Here’s an excerpt from the transcription of the netcast:

LEO: I know some people, the idea of government doing this makes them nervous. To me it actually seems sensible because you need a centralized third party to certify it.

STEVE: Yes.

LEO: And I know people, a lot of people who listen to this show, don’t trust our government. And we probably shouldn’t trust government. But who better? I mean, you want Microsoft to do this? They have been, by the way, with little success. So I think it needs to be that. And then I think this is a nice – you liken it to certificates, and I think that’s a good – the web certificate system, I think that’s a good analogy. I think it makes sense to have third parties that are certified and that kind of thing. I’m excited. We needed this. I’ve been signing my email for years, to no avail. It’s all been the Web of Trust technique.

STEVE: Yes. And this document establishes the right principles. I mean, and I’ve read the whole thing. Everything about it, as I’m reading – and I’m skeptical of Big Brother, too. I don’t know how we’re going to do it. I mean, as a coder and technologist I think about all of the hurdles and the pitfalls and the challenges we face. But it’s clear that we need that. We need this in order to move forward and to really leverage cyberspace to the full extent possible, I mean, we have the technology.

LEO: Yes, yes. Identity is critical. We’ve learned that lesson. And anonymity, while you – I think this is nicely done because you can have anonymity.

STEVE: Yes.

LEO: But there’s also a way to certify you are who you say you are. And I think you need both. So I think this is good. This sounds – I’m excited.

STEVE: Yeah, me, too.

The nice thing about technology such as that being built by NSTIC is that, unlike the need to rely on flimsy promises of the government’s benevolence, we can actually audit the specifications and open-source implementations of these technologies ourselves. And many people do. Steve Gibson did, and I trust him.

None of this is to say there are not valid concerns—there are. For one, Trusted Identity Providers are still going to be privy to most everything you do with one of your Internet ID identities, but I don’t see how that’s any worse than what we have today: your ISP, your DNS provider, and countless third-party advertising companies can and are tracking everywhere you go on the Web today. NSTIC, on the other hand, could give users like you and me both the technical and legal ability to have more fine-grained control over what such third parties see about us as we use the Web.

Technology that puts users back in charge of their identity? Now that’s an Internet law I can be proud of.

So, as I said in the discussion over dinner earlier tonight, rather than spend our time wringing our hands over this Internet ID stuff, we’ll all be far better off saving our energy to fight foolhardy initiatives like SOPA, PIPA, and other forms of political, social, and technical censorship.

Internet ID/NSTIC is not an enemy. It is going to be an important and useful tool for users like you and me.

This should be really simple, as the correct command line is plain as day (where the string of colon-separated 00′s is your preferred MAC address):

sudo ifconfig en1 lladdr 00:00:00:00:00:00

There are numerous blog posts all over the ‘net that tell you this time and again, but each one seems to have comments from users complaining that it doesn’t work on their system. I ran into a similar problem not long ago when my MacBook Pro didn’t do what I expected. Just like others, whenever I tried to run the above command, nothing seemed to happen:

ifconfig | grep ether # Determine current MAC addresses
sudo ifconfig en1 lladdr 00:00:00:00:00:00 # Try changing MAC address for en1 (usually Airport)
ifconfig | grep ether # Confirm change; but uh-oh! Output is the same as before! Why?

Here’s how I fixed this problem.

The thing to know is that there seem to be a number of conditions that will prevent Mac OS X from successfully changing a NIC‘s MAC address. Some are obvious and some are not. As far as I can tell, these conditions are:

• having the interface “down” (i.e., if you’ve recently run ifconfig en0 down or an equivalent),
• being associated with (i.e., connected to) a Wi-Fi network with your Airport card,
• having the System Preferences application running,
• forgetting to “unstick” the current system configuration set.

It’s the last one that bit me. Mac OS X has a feature called “system configuration sets” or “locations,” as it’s termed in much of the GUI. These can be accessed via the Network pane in System Preferences, or via the scselect command from Terminal; it’s that scselect command which offers the key to changing a Mac’s MAC address.

On my MacBook Pro (which, for the record and if it matters, is running Mac OS X 10.6.7), I need to do all of the following before running ifconfig, as shown above:

• If I’m changing my Airport card’s MAC address, I need to disassociate from any network. (This can most easily be done by invoking airport -z from Terminal. If you don’t have this command, see my tips on where to find airport.)
• Quit System Preferences if it’s open.
• Tell the operating system to “delay changing the system’s ‘location’ until the next system boot” by running: scselect -n.

According to the man page for scselect:

scselect provides access to the system configuration sets, commonly referred to as “locations”. When invoked with no arguments, scselect displays the names and associated identifiers for each defined “location” and indicates which is currently active. scselect also allows the user to select or change the active “location” by specifying its name or identifier. Changing the “location” causes an immediate system re-configuration, unless the -n option is supplied.

[…]

-n Delay changing the system’s “location” until the next system boot (or the next time that the system configuration preferences are changed).

Once I perform the above rigmarole, I can then change my MAC address without issue. But I have to be ludicrously careful. As soon as I open the Network System Preferences pane or otherwise do something to change the system configuration preferences, I have to run through that rigmarole again before changing my MAC address will work as expected.

During testing, I discovered that the odd-ball task failed to run, and found the following error in the system log:

sudo: sorry, you must have a tty to run sudo

I traced this error to a line trying to invoke a perl command as a user called dynamic:

sudo -u dynamic /usr/bin/perl run-periodic-tasks --load 5 --randomly

A simple Google search turned up an obvious solution to the error: use visudo to disable sudo’s tty requirement, allowing sudo to be invoked from any shell lacking a tty (including cron). This would have solved my problem, but it just felt wrong, dirty, and most troublingly insecure.

One reason why sudo ships with the requiretty option enabled by default is, among other reasons, to prevent remote users from exposing the root password over SSH. Disabling this security precaution for a simple maintenance task already running as root seemed totally unnecessary, not to mention irresponsible. Moreover, client‘s script didn’t even need a tty.

Thankfully, there’s a better way: use su --session-command and send the whole job to the background.

su --session-command="/usr/bin/perl run-periodic-tasks --load 5 --randomly" dynamic &

This line launches a new, non-login shell (typically bash) as the other user in a separate, background process and runs the command you passed using the shell’s -c option. Sending the command to the background (using &) continues execution of the rest of the cron job.

A process listing would look like this:

root     28109     1  0 17:10 ?        00:00:00 su --session-command=/usr/bin/perl run-periodic-tasks --load 5 --randomly dynamic
dynamic  28110 28109  0 17:10 ?        00:00:00 bash -c /usr/bin/perl run-periodic-tasks --load 5 --randomly

Note the parent process (PID 28109) is owned by root but the actual perl process (PID 28110) is being run as dynamic.

This in-script solution that replaces sudo -u user cmd with su --session-command=cmd user seems much better than relying on a change in sudo‘s default (and more secure) configuration to me.

Clickjacking does not rely on bugs in any software. Instead, the technique is simply an abuse of the growing graphical capabilities that advanced web standards like CSS provide to web browsers. A good introduction to clickjacking is provided by Steve Gibson and Leo Laporte on their Security Now! podcast.

As far as I’m aware, only Firefox when combined with the NoScript add-on and Internet Explorer when combined with the GuardedID product provide any measure of protection against clickjacking attacks. To date no other browser can detect, alert, or otherwise help you to avoid or mitigate the risks of clickjacking attacks.

That said, there’s gotta be something users of other browsers can do. Well, it may not be as much as what NoScript can do, but there is something: use a user style sheet to help expose common clickjacking attack attempts.

clickjane.css helps detect clickjacking attacks for all browsers

Until browser manufacturers provide built-in protections against clickjacking attacks in their software (which is arguably the best place for such logic in the first place), I’ve started putting together a user style sheet I’m calling clickjane.css that attempts to instantly reveal common clickjacking attempts. Since it’s a CSS user style sheet, this approach should be cross-browser compatible so that users of any browser including Safari, Opera, and other browsers that don’t have other means of protecting against clickjacking attacks can use it.

I’ve only recently learned about this class of exploits and so I’m not supremely well-informed on the topic. As a result, the clickjane.css file is relatively sparse and currently only reveals what I’m sure is a small set of clickjacking attmpts. However, as I research the topic further and learn more about the actual underlying HTML and CSS that clickjacking uses, I’ll be updating the clickjane.css code to reveal those attempts as well.

Naturally, contributions and assistance in any form are most welcome! Learn more about clickjane.css as well as how to use it at the Clickjane CSS Github wiki.

Before and after clickjane.css

Here are two example screenshots of a benign clickjacking demo.

1. Before:
   

   Screenshot of Safari before clickjane.css is used to expose clickjacking attempts.

2. After:
   

   Screenshot of Safari after clickjane.css is used to expose clickjacking attempts.

Good habits you should get into to mitigate clickjacking risks

Here is a list of behaviors that you should make habitual while you browse the web. Engaging in these behaviors can dramatically reduce the likelihood that you will be victimized by a clickjacking attack.

• Explicitly log out of any service you have logged in to when you are done. That log-out button is there for a reason: use it!
• Avoid providing your browser with “Auto-Complete” information for critical sites, such as your bank.
• Make sure you are running Flash Player 10 or greater, which mitigates this vulnerability for Adobe Flash content.

More resources to learn about clickjacking

• Hackademix.net – More clickjacking links to the OWASP presentation, the white paper, and a blog post showing several CSS-based exploits.

Translations of this article:

• Belorussian (thanks, Bohdan Zograf)
• Ukrainian (thanks, Alyona Lompar)

The error, which is triggered on login regardless of whether or not the username and password you enter are correct (presumably because the issue occurs while trying to authenticate), displays the username and the password the user has entered in cleartext and then (as if that wasn’t bad enough) encourages the user to email this information to their support department!

Yes, we have made the company aware of the problem. No, they have not fixed it yet. Proof in the form of a screen capture from literally 10 minutes ago:

Workamajig.com login error echoes the entered password in cleartext and encourages the user to send this to their support via email.

No, these are not real credentials, but an uninformed user may very well enter access credentials that are valid. Since this issue is not triggered by invalid credentials, that means valid login information for god knows how many Workamajig user accounts is very likely sitting in the SMTP logs of countless mail servers. Since in many countries these logs are federally mandated to be saved for at least two years, if I were a user of Workamajig I would seriously consider changing my account password ASAP, as well as changing any other account that I used the same password for!

I can’t be sure from this screen shot, but I sincerely hope that user’s passwords are passed around in the application as well as stored on disk as salted cryptographic hashes. Of course, after seeing this, I wouldn’t be shocked if that wasn’t the case. The good news is that the login screen to their application is only accessible with an SSL/TLS connection, which does prevent someone from snooping on the wire. Nevertheless, there are still many attack vectors that SSL/TLS doesn’t protect against if the rest of the application is not secure or, say, if you’re encouraged to bypass those protections by sending emails with sensitive data in order to request technical support.

Anyway, hopefully this gets fixed sooner rather than later. At the very least, don’t encourage users to email cleartext passwords. That is pretty much always a Very Bad Thing.

Update: It took only a couple of days for Workamajig to notice this blog post, which is great because it means I woke up to a forwarded email in my inbox in which a Workamajig representative said:

On the issue of showing the user id and password in an error message, [we] will be changing the way that error message is displayed. […] Just to clarify the user id and password is just on the screen of the user that is logged in, and that message to copy and paste is a standard messages and it is just intended for you to copy and paste the error message; you are not required to send the user id and password.

I haven’t encountered the same issue again (but then again I only tried to login to my account twice in between then and now), so I can’t verify that the error message really has changed but I’d give Workamajig the benefit of the doubt. If you’re using Workamajig and notice a change in the way this login error is handled before I do, leave a comment to let me know it’s really been changed.

Everyone has sensitive files that they keep on their computer and, fortunately for Mac OS X Users, Apple has made it ridiculously easy to create a cryptographically secure containers for such files. You can think of a container like this, which is just a standard Mac OS X disk image (.dmg) file, like a vault that you open, put stuff you want to keep safe inside, and then close again.

Here’s how you go about making and using one.

Create the container, an encrypted disk image

1. First, open up your copy of Disk Utility.app, which is located in your computer’s /Applications/Utilities folder. (As an aside, this program is a bit like a swiss army knife for handling disk operations in Mac OS X. You should definitely find out what else it can do).
2. Next, select the File → New → Blank Disk Image… option. This will cause the New Blank Image window to appear.
3. Fill in the typical details such as the disk image file’s name and where you want to save it to. In addition, you’ll be presented with a number of options such as Volume Name, Volume Size, and Image Format. The defaults are usually adequate except for Volume Name, which you should customize so that when you mount the disk image the disk label is meaningful for you, and the Image Format, which I recommend you switch to “sparse disk image.”

   Sparse disk images can start small and grow automatically as you write more files into them. If what you want to keep secure in this manner are very large files, say gigantic high resolution PhotoShop documents, then you might consider the sparse bundle disk image format instead.

   Also, obviously, set the Encryption to a value other than “None.”

   Here’s an example screenshot from my Mac:

   

   Screenshot of the New Blank Image window showing meaningful values entered, Encryption field set to 128-bit, and Image Format field set to sparse disk image.

4. Press the “Create” button and you’ll be presented with a standard password selection dialogue. This is the password you’ll use to mount the disk image and is analogous to the idea of setting the combination on your vault’s lock. It’s critical that the password you choose is a good one. Ideally, your password is a totally random string that may include any printable character. Since that’s hard to remember, you can have the Mac OS X keychain manage your passwords for you.

Encrypt some files by writing them to the disk image

Now that you have an encrypted disk image, a secure container for your sensitive data, you can make use of it just as you might any other disk image on Mac OS X. For instance, say I have a top secret file called “My Killer Business Plan.pages” and I don’t want anyone to get at it. All I need to do is copy the file into my encrypted disk image, as the following screenshot shows:

It should go without saying that you want to delete the original, unencrypted copy of the file you’re copying into the encrypted disk image, but I’ll say that anyway. Don’t leave unprotected copies of your files lying around. Also, be certain to unmount (eject) the disk image when you’re done using it because the only thing the password protects is opening the disk image, not the files contained within it.

External references

Here are some additional places where this technique is discussed. Check out these additional articles about this topic elsewhere for more information and other perspectives:

• Mac OS X: How to create a password-protected (encrypted) disk image
• Mac OS X: About Encrypted Disk Images
• MacOSXHints.com: Create an encrypted disk image that grows as required

When you log in to just about any Web site or Internet-enabled service, say Basecamp for example, you traditionally simply type in a user name and matching password. This is known as one-factor authentication because all you need to do to log in successfully is use a matching pair of user names and their passwords. Since the user name is not hidden, the only piece of the puzzle that’s providing any security is your password.

Now, a password is something you have to remember, so this factor is called "something you know." Of course, if someone else also knows your password, this means that person can log in pretending to be you. Thus enters the need for a second factor for authentication.

The YubiKey is a physical USB fob device with a unique ID. That is, each YubiKey in the world has its own ID, meaning that no two are identical. This implies that if you have a YubiKey with you, no one else can have that same YubiKey anywhere else in the universe. Thus, this gives you a second factor with which to authenticate yourself, specifically it’s "something you have."

When you combine something you know (for instance, a password) with something you have (such as a YubiKey), you have two-factor authentication. Authenticating yourself with both of these factors is obviously more secure than relying solely on one factor because in order to compromise it an attacker needs to compromise both factors; the attacker would need to know what you know (figure out your password) and steal something you have (physically obtain your YubiKey).

If you’re familiar with one-time credit cards such as those that PayPal offers, you can think of the YubiKey like one of these cards, but instead of being used to make online purchases, it’s used for logging into stuff (and, of course, you don’t need more than one physical YubiKey). Of course, for authentication to work with the YubiKey the application or service you are logging into has to be able to understand that you’re using one of these authentication devices.

The good news here is that the entire process of using a YubiKey is a well-documented, open-source, and open-spec scheme so it’s easy for service providers to implement. And, because Yubico is also an OpenID identity provider, you can use your YubiKey to log into any site that supports the OpenID protocol right now, such as (you guessed it) Basecamp! There’s even a WordPress YubiKey plugin so you could theoretically use your YubiKey to secure your authentication to any of your WordPress blogs.

The YubiKey spec is, itself, completely independant of the OpenID spec and vice versa, which is what makes the combination so formidable. What’s so cool about this process is that the site you’re authenticating to, such as Basecamp or your WordPress blog, doesn’t have to know anything about how you’re authenticating because the OpenID provider (Yubico in this example) simply returns the answer—a perfect example of a well-constructed API at work. Either you have successfully authenticated to your OpenID provider or you haven’t, and the site can respond accordingly.

And if that’s not cool enough, want to know the coolest thing about the YubiKey? It’s environmentally friendly! The YubiKey web site states that the robust, ultra-thin and battery-free design increases lifetime and reduces environmental impact.

I’m more than seriously considering getting one of these myself, and even beyond that, getting one for all of my fellow site editors on some of the community web sites I help maintain. This is especially important for sites dealing in confidential or otherwise sensitive information, such as those which hold financial records or have other privacy concerns. Securing the authentication of privileged users such as the site administrators seems a natural step.

Even better yet, because the only cost to implementing this system is developer resources and the cost of the physical YubiKey device, I’m also seriously considering baking this right into any new sites I develop. At $35, a YubiKey is actually cheaper than an SSL certificate, and even though they don’t protect against all the same attack vectors, I think a device like the YubiKey is clearly a vastly superior solution in the majority of use cases.

I never really had a compelling reason to begin to propagate an OpenID identity before but now, at last, I do.

Apple has been on point, however, providing good security utilities built right into the operating system and easily available to end users. Of most common use is probably “Secure Empty Trash” which securely deletes files that you put into the trash. The counterpart to this function available in the Finder is, too few Mac users know, the srm or secure remove command-line utility.

srm can be thought of as simply a version of rm that overwrites file data before unlinking it from the file system. It comes with a few more options than rm comes with all geared towards tweaking just how it overwrites files. My favorite is -m, which the manual page says:

overwrite the file with 7 US DoD compliant passes (0xF6, 0×00, 0xFF, random, 0×00, 0xFF, random)

I had the perfect occasion to use srm today: I was transporting my SSH private key from one laptop to another via a temporary drive. I wanted to securely remove all traces of the private key file from the temporary drive after installing it in the new computer. (See this SSH public key tutorial if you don’t know why this might be important.)

After copying the private key file over, removing it securely looks like this:

srm -m private_key_file

It’s that easy.

To be confident that your file is truly overwritten with garbage, you can use the -n option. This is one way to retain a file, but completely corrupt it. Observe:

Meitar:~ meitar$ cat testfile
Hello world.
Meitar:~ meitar$ srm -mn testfile
Meitar:~ meitar$ cat testfile
?
 ?)c?I
      P?Meitar:~ meitar$

That garbage you see after the second invocation of cat shows that the file really was trashed, that is, overwritten with garbage data. Now, a simple rm testfile can do the rest of the work.

As always, man srm will give you all the other juicy details.

Whenever you tell an application to “Remember this password in my keychain,” what you’re doing is writing a new encrypted entry into your user account’s ~/Library/Keychains/login.keychain file. Then, the next time the application needs to access a restricted resource, it just asks Mac OS X to get the password for it. Of course, all of this happens automatically, so except for that single checkbox most users probably don’t know that the keychain even exists.

What’s even more awesome than all of this automagic password storing action, though, is the fact that Apple has also provided an easy-to-use application to manipulate the keychain yourself. What good does this do us? Plenty! Observe.

Say you’ve just signed up with a new ISP. They send you a username and a password to log on to their ADSL network with. Of course, they send this password to you on paper—how insecure! Instead, after changing the password to something else first (something other than mypassword, which is the example password I’ll use here), we can use Mac OS X Keychain to securely store the password and retrieve it later.

1. First, launch the Keychain Access application located in the /Applications/Utilities folder of your startup drive.
2. Next, click the “Create a new Keychain item” button (the +) button near the lower left-hand corner of the window. The Add Keychain Item sheet appears.
3. Enter a meaningful name, such as “ADSL ISP Account” in my example, in the Keychain Item Name field.
4. Enter the username or account name associated with this password in the Account Name field.
5. Enter the password into the Password field.
6. Click the Add button.

That’s all there is to it. To later retrieve your password if, say, you ever forget it:

1. Launch the Keychain Access application.
2. Locate and double-click the keychain item that stores the account and password information you want to retrieve.
3. Tick the “Show password” checkbox. You’ll be presented with a dialogue box that asks for your keychain’s master password. Unless you’ve already set it to something else, this is the same password you use to log in to your Mac OS X user account.
4. Enter your keychain password and click “Allow.” If you click “Always Allow” instead, Keychain Access will not prompt you for your login keychain’s password the next time you ask to see this particular password. I never press that button.
5. Your password’s plaintext is now visible.

This effectively obviates the need for third-party applications such as Password Gorilla, PasswordWallet or KeePassX which are great programs, but all suffer from a lack of a good user interface. Furthermore, there’s no reason why we can’t store short arbitrary strings of sensitive information in the keychain temporarily. Sure, it might clutter up your keychain, but you can always search the entries using the standard Mac OS X filter search bar at the top right of the window.

In fact, Apple’s been kind enough to offer an interface to do just that in an even more effective way, called Secure Notes. These are simply plain text strings of arbitrary length that can be stored securely inside your keychain, and that use the same interface to access (requiring your password to view). The only real difference is that instead of a single line, you’re given a fully scrollable text area in which to type your secure note.

Moreover, because keychains can be synced to multiple Macs with .Mac Sync (or a third-party synchronization solution), you can always have access to all your passwords regardless of which physical Mac you’re using. Best of all, since you never have to remember another password ever again, you can quit using the same password for multiple accounts, and you can always use really hard-to-crack passwords.

But then today I was glossing over Apple’s featured features list and I got even more excited. There are the usual, largely meaningless, fluff updates that are nice for Joe Schmo or his mother, but that power users simply don’t care about, like the new iChat support for animated buddy icons, but the list is also chock-full of really cool, really useful features.

What’s interesting is that a good deal of these features aren’t really new features at all. For instance, if you knew how to manipulate the NetInfo database on your Mac, you could already share any folder via Apple’s “Personal File Sharing” feature. (Here’s a Mac OS X Hints hint explaining how to do it.) In Leopard, however, Apple claims that this functionality is now integrated straight into a folder’s Get Info… window. If it works as smoothly as Apple claims, this is finally going to bring Mac OS X (client) into decent competition with Windows XP Professional in terms of GUI-level power-user features.

However, while all of these features are really cool, here’s a list of the ten geekiest features I will probably absolutely love, for one reason or another.

• Ruby on Rails, out of the box — The hot thing in web development right now is Ruby on Rails. Macs have already been the best personal desktop and web development platform because they have built-in support for the Apache web server and a host of other features, but now they will come with a ready-to-roll installation of Ruby on Rails, sporting Mongrel and (better yet) Capistrano! Specifically with the addition of Capistrano, which is terribly undersold as simply a Ruby on Rails deployment platform, these UNIX-y “toolbox” items are bound to make Macs that much more useful right out of the box.
• Safari’s full history search — As their recent public partnerships with Google have shown, Apple is very clearly invested in search technologies. Spotlight gets a huge number of improvements in Leopard, but none which I think are going to be more useful to more people than this one: spotlight searches on the full text of each web page in your visited history list. That’s just awesome. Also awesome: using spotlight as a calculator and as a dictionary, which also shows just how Google-like Apple is trying to be. (Google also lets you ask it arithmetic questions and a dictionary.)
• Wikipedia articles in Dictionary.app — I love Wikipedia because it’s one of the fastest ways to get (relatively) reliable information quickly. Now that Dictionary.app has built-in integration with Wikipedia, imagine the possibilities for getting that knowledge instant-gratification craving fixed. Apple has not yet announced this capability, but I can easily envision a scenario where all Cocoa text fields are instantly “wikified” (with text that matches Wikipedia articles highlighted) much in the same way that current Cocoa text fields allow you to right-click on a misspelled word and have it corrected by Dictionary.app.
• Application-based firewall — In classic Apple fashion, functionality that was previously available via third-party additions is now available from Apple itself. In this case, I have to wonder how well Apple’s updates to its firewall will obviate the need for Little Snitch, which is basically an application-based firewall, too, and a good one at that.
• Built-in guest log-in account — If you’re as paranoid about security as I am, you’ve already created a special, limited-access user on your system (called Guest or Visitor or whatever) and whenever friends are over, you tell them to use that account instead of your own. Now in Leopard, Apple has gone through the trouble of setting this up for us already. A small change that is going to have a big impact.
• Scriptable System Preferences & applications — With AppleScript, you can automate the things your computer does with scripts, as long as those things are “scriptable.” In previous versions of Mac OS X, huge gaping holes of what things shipped by Apple were scriptable existed, causing me (personally) some really annoying headaches. AppleScript GUI scripting helped me get around many of those roadblocks, but now it seems Apple is finally filling in some of the most notorious gaps in this functionality with scriptable System Preferences. Yay!
• Automator workflow variables — Automator brings the power of AppleScript I just mentioned to more people with a completely graphic programming environment. There is no need to open up a text document and write AppleScript code because Automator lets you create a script (called a Workflow in Automator jargon) using your mouse by dragging and dropping actions into the order you want them to be performed. It’s very slick, but until now it’s been very limited. With Leopard, Apple is beefing up Automator so that it includes things like variables, basic programmatic capability that was sorely lacking before. (Also majorly cool: a command-line utility to access Automator!)
• Finder.app’s path bar — Every serious Mac user knows that the Finder needs a lot of help. Now, it’s getting some. Something the Windows Explorer has had forever (as had every desktop environment for Linux, of course) is a visual cue to show you where in your filesystem tree a given folder is located when you are viewing said folder. Now the Finder gains this capability (though Apple’s description implies that it’s going to be off by default) with what Apple is calling a “Path Bar”. Finally!
• Cocoa and scripting bridges — Even though no one really seems to know about it, it has long been possible for languages other than AppleScript to do things like send Apple Events to Mac OS X applications. Specifically, Ruby and JavaScript, two of the most well-known web development languages in existence, can already do this with a single ScriptingAddition (OSAX). But now Apple is making this functionality a central feature and fully extending it to their Objective-C (and Cocoa) language and applications such as Xcode and Interface Builder. This means people like me will have a shallower learning curve before we’re able to create full-fledged, native Mac OS X applications. Now that’s exciting!
• Xcode 3 refactoring — This is something you kind of have to see to believe. I got the opportunity to see it demoed at Apple’s Leopard Tech Talks last year and I was really excited by it. With the new Xcode, Apple’s development IDE, you can do away with find-and-replace searches for things like renaming functions because Xcode understands what parts of your code are what structures and, when you tell it to “change the function named myFunction to myNewFunction,” it’ll only find-and-replace function names instead of every instance of the string “myFunction.” That’s pretty big, and if it were available for more languages, it’s almost enough to make me ditch vim.

So there you have it. Ten features you might not have already known about that are some of the most promising features I can see in Leopard. And I didn’t even get into Wide-Area Bonjour, which could make services like DynDNS or No-IP a thing of the past (and which I still want to learn more about), or the new Terminal application (finally with tabs!), or even the multiple user certificates for S/MIME encrypted email.

Note: One of the least known security features available on Mac OS X is also possibly one of the best, and the simplest. Evidently, all Intel-based Macs are shipped with the XD (aka. NX, aka. DEP) bit turned on—and thankfully there doesn’t seem to be any way for users to turn it off. However, this isn’t a silver bullet and if you want to learn why you should check out this excellent Anandtech article: A Bit About the NX Bit.

Voila. This system is flawless. You will never be able to send me loads of spam that go anywhere but my spam box, and I hardly ever look in there.

Naturally, there is a caveat to using this technique, but I actually consider it to be an advantage. By necessity, this technique, keeps me pro-active about getting people’s contact information when I meet them (and want to talk again). If I don’t get that person’s email address, I’ll probably never see that person’s email unless I’m looking out for it. Nine times out of ten, however, that’s what I want to have happen anyway.

So this solves the problem of unwanted mail. However, what if I want to let people contact me that I don’t know ahead of time or have previous whitelisted? Well, in that case I rely on an out-of-band communication, such as an introduction from a friend, leaving a comment on my blog(s), or some other method such as an instant message to let me know that there is someone who wants to talk to me.

My contact information is so available (in so many places), and many IM services are now equipped with store-and-forward messaging that there really is no reason for email to be the first time I hear from someone. Even better, if I’m contacted over Google Talk (as an example), I automatically have an email address for that person.

Voila. Simplest. Spam. Filter. Ever.

Microsoft has yet to provide a fix for the vulnerability, but is working on a patch, according to the security advisory. Security-monitoring company Secunia deems the problem “extremely critical,” its rarely given highest rating.

The vulnerability puts computers running Windows 98, Windows Millennium Edition, Windows 2000 and Windows XP at risk. An attacker could gain complete control of vulnerable systems by hosting malicious code on a Web site. Once an IE user visits the site, the malicious program would run without any user interaction.

[via ZDNet]

The second is a design flaw in the way Internet Explorer handles CSS import commands and allows an attacker to retrieve private user data or execute operations on the users behalf on remote domains, Matan Gillon, who discovered the vulnerability, wrote in his article. The reason this is so troubling is because, by exploiting this vulnerablity, attackers can actually bypass extremely strict security limitations and create JavaScripts that have inter-domain communications ability (XSS attacks). If that sounds scary it’s because it should.

[Unlike] classic XSS holes […] in this case the target site doesn’t have to be vulnerable to script injection. All an attacker has to do is lure a user to a malicious web page. Thousands of web sites can be exploited and there isn’t a simple solution against this attack at least until IE is fixed. That means millions of IE users are affected by this design flaw.

This vulnerability has been tested to work on a fully patched Microsoft Internet Explorer 6 browser and earlier versions are possibly vulnerable as well. Mozilla Firefox seems to adequately keep domain restrictions in CSS imports and doesn’t seem to be vulnerable to this type of attack. Opera isn’t vulnerable because it doesn’t support the styleSheets collection. Possible solutions for users to mitigate this attack would be to disable Javascript in IE or use a different browser.

If you haven’t yet, now it’s really time to switch.

The reason this is interesting is because they are clearly spam messages. I have to wonder, then, why spammers would want to leave comments raving about how secure Outlook is. The thing is, Outlook (and especially Outlook Express) is one of the most unsafe pieces of software you can have on your computer. In my experience cleaning and repairing other people’s computers, more viruses and other computer nasties arrive on a machine via Microsoft Outlook than any other program.

So why are spammers hailing the security of this program? Are they trying to get people to use it? Do they think people will switch their email program because they saw some comment on a blog somewhere?

Strangest. Spam. Ever.

Anyway, he quickly set me up, left me extra cable wires at my request, and I started to set up my computer corner. Got my router hooked up after spoofing its MAC address, and started a cursory test of the Wi-Fi router’s signal around my apartment. Everything looked good for a while, so I moved on to more pressing matters, but later on in the day I began experiencing inexplicable network slow-downs and disconnects. I couldn’t make heads or tails of it until I launched NetStumbler and began exploring a little more in-depth.

(I had to do some quick research to gain any valuable information from NetStumbler’s findings, but luckily Wikipedia is perfect for this sort of thing.)

NetStumbler was able to locate 3 other wireless networks in addition to my own which were broadcasting through my apartment. The interference was remarkable. Each of them were transmitting in the mid-channel range from 3 through 6, and I was caught right in the middle. My network’s SNR decreased considerably the more I travelled away from the AP.

The thing about Wi-Fi is that the signals aren’t typically very strong to begin with becuase the coverage is intended to remain confined. This means that competing signals transmitted in close frequencies (termed channels) cancel each other out, causing the headaches my network was giving me.

Thanks to NetStumbler I knew what channels the other guys were using, so I started broadcasting at the other end of the spectrum and suddenly my reception was loud and clear all over the apartment, and I would guess wherever they are broadcasting from too. The lesson in radio technology and Wi-Fi in general was extremely interesting and informative, but on a more practical note this is about being a good Wi-Fi neighbor and not competing for signal strength on the same channels.

It also brings up some very critical concerns involving security and privacy issues. One of the networks NetStumbler found was an unsecured Linksys-based AP. The owner probably doesn’t realize that his home computer network is wide open to anyone with a wireless networking card and a computer, but it is. Since Wi-Fi works on radio technology, and radio can pass through solid objects like walls, the area covered by his transmitter pokes out of the confines of his apartment.

If I were the bad neighbor, I could use his Internet connection, or even browse his iTunes music collection and he would probably be none the wiser. If he had a wireless web cam hooked up to the network, I could see whatever images it broadcasted too. And I wouldn’t even have to start hacking. That’s why it’s so important that you take the steps to protect your wireless network with something like WPA or WEP.

WEP is not very strong, and the new generation of WEP-cracking tools can break it in a matter of minutes, so it should never be considered a preventative measure to keep crackers out of your network. Rather, it is a detterant that should be used to dissuade crackers from trying. My old router only supports WEP encryption on its WLAN so that’s what I’m stuck with, but the fact that this other guy keeps his network wide open means I feel pretty safe here.

Afterall, which house do you think a burglar would break in to? The one with the big security-company sticker on all the windows and doors and the lights on, or the one in the dark with the open window and unlocked door?

It is similarly annoying that Hotmail (afaik) has never used it when checking email from a client such as Outlook, Outlook Express, or Entourage. Yahoo! Mail doesn’t even have POP, or POP-like, access to its mail accounts (again, only afaik), but by default their log-in forms are not secure.

So when Gmail announced its free POP service for its users, I was skeptical. “Great,” I thought. “I’ll never use it.” But today I clicked on the “New Features!” link, found the instructions for enabling their POP service and—low and behold—imagine my surprise when I read that they actually require the use of a secure connection!

What an incredibly sensible choice! And yet another reason to switch to Gmail if you can. I don’t see either Yahoo! Mail or Hotmail doing anything on the security front. In my eyes, Google should be advertising this fact more than they have. But I guess it only really matters to geeks like me.

P.S.: If you want a Gmail account and don’t have one yet, then I’m willing to give you one. (I’ve got more invites than I know what to do with.) Leave a comment or email me at meitarm (at-sign) gmail (dot) com, and give me a suggestion for how to improve this site. I’m most interested in design ideas, and if you’re handy with Photoshop, an image of one would be nice too.

This has a number of advantages:

1. The message’s security is on-par with some of the best privacy encryption around. The telephone is a surprisingly easy communication channel to compromise. At least sending an encrypted email (assuming keyloggers aren’t present on a compromised system and assuming the private keys are kept safe) will take some more intense computational power to crack.
2. I’m basically guaranteed to recieve the communiqué; my cell phone provider has the worst reception and delays imagineable. I’m always available by email, however, because I check it as if I’m paranoid.
3. Best of all, my mother need not call me as often as she once has. (No offense, I love you Mom.)

Anyway, the point is that I had wanted to now integrate GPG with Apple’s Mail.app, had heard about GPGMail, but was worried that it wouldn’t work because it says it needs MacGPG, and I have Fink’s GPG port.

Being the blatantly insubordinate individual and anti-authoritarian that I am, I decided to try to work with it anyway and see what would break. So I installed GPGMail and launched Mail.app. I was presented with the error, “Invalid crypto engine! GPGMail cannot work. It didn’t find GnuPG (/usr/local/bin/gpg) with at least version 1.2.2. Please quit Mail, blah blah blah blah!”

So, thinking that maybe that path was just hardcoded into GPGMail, I created a symbolic link from /usr/local/bin/gpg which pointed to my Fink gpg installation at /sw/bin/gpg.

sudo ln -s /sw/bin/gpg /usr/local/bin/gpg

Much to my delight, it worked wonderfully. Luckily, it turns out that GPGMail can work just fine with GPG ports other than MacGPG. You just have to tell it where your gpg executable is.

His home computer was essentially the family computer. It has games, pictures, a music library, and lots of old homework. But it also has financial records, private email, and the like. Every family computer is a treasure trove of vital information for thieves and crackers. Its information would be far more valuable than a bunch of jewelry or the children’s stash of allownace, so you can clearly see why making a connection from the Internet to the family computer requires some security considerations.

This whole situation got me thinking of the state of information security as a whole. When it comes right down to it, my family’s home system is relatively more secure than most home or small business networks. Keeping the computer behind a firewall helps somewhat right off the bat because it separates us from the rest of our ISP‘s subnet. That’s probably the most important security step anyone can take, and its so utterly easy. I’ve walked into offices countless times where a single computer was plugged right into the cable or DSL line. That’s just inviting trouble!

The situation with dialup Internet access is much worse. Consider AOL, for example. For years, customers have been logging into their AOL accounts using no security precautions at all. Username and password sent in the clear, which is about as secure as writing your bank account and PIN numbers on the back of a postcard. To add insult to injury, AOL is now charging users extra for a secure log-in procedure, which is nothing more than pure greed. Two questions come to mind:

1. Why did it take more than a decade to implement a secure log-in procedure?
2. Why, when it finally comes, is it being offered only as a premium service?

This is sending absolutely the wrong message to computer users everywhere.

The issue I take with it, of course, is that while iron-clad protection is indeed difficult if not impossible to achieve, an enormous difference can be made with just a little bit effort. In AOL‘s case, simple security such as end-to-end encryption during a log-in procedure should not be an incredibly difficult task to achieve. While their rotational password scheme does offer an added layer of security, and makes encryption a little less important as far as log-ins go, does this mean that regular users will just have to suck it up and be content with their lack of security?

I sure as hell wouldn’t be.

Enabling this kind of connection for my own server was no problem at all. Actually, my web hosting provider is smart enough to offer these services right off the bat, so it was merely a matter of confirming their existence.

telnet my-domain.com pop3s

However, I also have a Road Runner account because those folks are my home ISP. Unsure whether or not they offered these services, I scoured their online help pages but no avail. There was only scant information on security, and most of it had to do with how to block pop up windows in Internet Explorer (a futile excersize anyway).

So I turned next to their online chat support. In order to connect, they required that I fill out my full name and email address in a form (which was not itself secured with HTTPS by the way). Here’s a transcript of my conversation with their representative.

Mike S.: Thank you for choosing Road Runner Technical Chat. My name is Mike S.. May we have the first and last name, and the phone number with the area code of the master account holder?

Meitar: Believe I just gave that to you, but sure: Meitar Mxxxxxx (xxx) xxx-xxxx

Mike S.: Thank you, and with whom am I speaking currently?

Meitar: That’s me. Meitar.

Mike S.: Thank you, what technical issue may we assist you with?

Meitar: I’m wondering if you support pop3s (or POPs) for email?

Mike S.: What is it that you are attempting to do?

Meitar: Use it. If it’s available, I’d much rather retrieve my email via an SSL-secured connection than a plaintext one.

Mike S.: If you are trying to connect to a POP3, then that is fine. If you are attempting to setup a POP3 server on your home connection, this would not be supported, and in fact against the Road Runner Terms of Service Agreement.

Meitar: Nonono, I’m not trying to set up a server, I just want to know if *you* support the protocol.

Meitar: That way I can hit that “Use SSL” checkbox in my Mail program.

Mike S.: If you are connecting to the Road Runner POP3 e-mail server to receive your e-mail messages, you will not be able to set it to SSL. If you are using another POP3 server to receive e-mail from another account, you will have to contact the provider of that POP3 server.

Meitar: So you *don’t* use it, right? I’m connecting to the pop-server.nyc.rr.com machine, whichever that is, for my Road Runner email, in case that helps any.

Mike S.: I am sorry, but I do not understand what it is that you are asking of me. That is the correct POP3 server for the Road Runner e-mail accounts.

Meitar: I’d like to know if my computer can still talk to yours if I tell it to speak POP3S rather than plain-old POP3. I want to know this so that I can set up my mail programs to “use SSL” if your server supports it. As I said before, I’d much rather use an SSL connection than not because I frequently check my mail from hotspots around the city.

Mike S.: As I mentioned, you are not able to “use SSL” for the Road Runner e-mail server.

Meitar: Okay. That’s what I wanted to know. :) As an alternative, do I have access to an SSH account along with my subscription to Road Runner?

Mike S.: Unforunately we do not offer such a service at this time.

Meitar: Hm. Drat…. Well, thanks anyway Mike. Hopefully Road Runner will soon offer secure email alternatives for their customers. :) Have a great rest-of-the-day.

Mike S.: You are very welcome! Have a great day!

Mike S.: If you have no further issues that we can assist you with, you may end the chat session by clicking on the Hang Up button and a chat transcript will be displayed for you. Once again thank you for choosing Road Runner!

In an ongoing effort to continue improving our quality of service, we are conducting a customer survey. If you would like to participate, please copy and paste the following link into your browser: http://help.rr.com/html/chatsurvey.html .

Mike S. Has Disconnected

I couldn’t help but be so nice because he really made me laugh.