In this ongoing series of articles, Joe Kissell examines common misconceptions about the way technology works and tries to set the record straight.
Article 1 of 8 in series
by Joe Kissell
Joe’s new ongoing column, FlippedBITS, promises to set readers straight on a wide variety of confusing technical topics.Show full article
Today I’d like to introduce a new series of articles we’re calling FlippedBITS. Our premise is that technology breeds misconceptions, and far too often, due to a lack of information, we develop mental models of the way things work that are plausible — but wrong. Those mistaken ideas, in turn, make it more difficult to solve everyday problems and can lead us to waste time, effort, and money. In each installment of FlippedBITS, I’ll examine one or more of these misconceptions and do my best to set the record straight.
My 2-year-old son is still learning the basics of how the world works, and it’s fascinating to watch his understanding of technology evolve. Just a few months ago, he’d pick up a remote control and try to talk on it like a telephone. In his mind, any oblong plastic box with buttons on one side must be a telephone — it’s easy to see how he might make that mistake. (And, in all fairness, we had a telephone and a remote control that looked mighty similar to each other.) Now he understands that a remote control is different — it’s the thing we point at the TV to make it play his favorite shows. But then he became confused and frustrated when we handed him a toy remote control that only made noise when he pressed the buttons; he couldn’t understand why the TV wouldn’t respond.
We expect kids to make these kinds of errors, and we laugh knowingly as we watch how they try to put something into one logical category, notice that it doesn’t quite fit, and then try another. This is all part of growing up. But in fact, we never stop trying to make sense of the world. We encounter a new thing we don’t entirely understand, and we automatically — perhaps unconsciously — start trying to construct a mental model of what must be happening behind the scenes. These models not only help us explain what we’re seeing, they help us predict how things will work in the future. It’s just that sometimes, through no fault of our own, we guess wrong.
For example, I remember the first time I heard of this newfangled device called a “laser printer.” I was a freshman in college. I got that paper went in blank and that, due to something involving a laser, it came out with crisp black text. But the initial idea I had about how this worked was that the laser was somehow burning the letters directly on the paper, because after all, burning is what lasers do. Later, when I found out that laser printers used a black powder called toner, I had to revise my theory. Maybe the paper was covered with toner before the laser zapped it, and the heat from the laser caused the toner to melt in spots and stick to the paper. That turned out to be wildly wrong too, of course. I had no idea at the time that a laser beam could reverse an electrostatic charge that otherwise causes toner to stick to a drum, that when paper rolled along that drum, it picked up the remaining toner (again, due to electrostatic attraction), and that a combination of heat and pressure then fused the toner to the paper. My theories had seemed reasonable based on the available information; they even correctly predicted that the paper would come out of the printer warm. But my mental model didn’t happen to reflect reality.
Misconstruing how a laser printer worked had no negative consequences for me. But sometimes erroneous mental models lead to serious problems. If your mental model of how a car’s air bags work is that they offer complete protection in any sort of crash, that could lead you not to bother wearing a seatbelt, which might prove deadly if, for example, your car flipped over.
I get lots of technical questions from people who have read my books and articles or heard me speak somewhere. A fair percentage of the time, the questions are phrased in a way that shows they come from a mistaken mental model. For example, in the last several weeks at least three different people have asked approximately the same question: “Since FileVault encrypts all the files on my disk, doesn’t that mean when I copy a file to another disk, it’s still encrypted?” No! It absolutely does not mean that. (I’ll explain why in a future FlippedBITS article.) But I can easily see how someone might draw such a conclusion — and misunderstanding something like that could cause someone to make an unsafe decision about how to handle sensitive files.
I’ll admit it: When I hear questions like this, I sometimes have to fight the temptation to roll my eyes and say, “What an idiotic idea!” But I’ve had (and probably still have) plenty of idiotic misconceptions myself. Not understanding something, or having a faulty conception of how it works, doesn’t make you stupid. It only means you haven’t yet acquired enough information about something. I’ll do my best to supply those missing facts and put us all on the right path. I already have a healthy list of prospective FlippedBITS topics, but if there’s a topic you think might be an appropriate fit, please feel free to suggest it.
So, whence the name “FlippedBITS”? Apart from the fact that we at TidBITS like to append “BITS” to everything, we thought that flipped bits would be an apt description of the kind of error we’re trying to correct. Computers, as you know, store information as a series of ones and zeroes. Every “slot” that can hold either a one or a zero is a bit. If the bit’s value is zero and you flip it, it becomes a one. Flip it again, it’s back to zero. Sometimes bits get flipped inadvertently due to programming errors, mechanical failures, media degradation, cosmic rays — really! — or other random occurrences. And unfortunately, a single flipped bit — a one where a zero should be, or vice-versa — can mean the difference between a program succeeding and failing. After all, 01110111 is “w” in binary, but 01110011 — almost the same, but with one bit flipped — is “s.” Sometimes a change as small as a single flipped bit can spell the difference between a “win” and a “sin”!
With that, allow me to direct you to the first article in what I hope will be a long and helpful series: “FlippedBITS: Booting Your Mac from a Duplicate” (13 March 2013)
Article 2 of 8 in series
by Joe Kissell
Bootable duplicates are an important part of a complete backup strategy. But when you have to boot a Mac from such a disk — even if only temporarily — things may not always behave as you expect. Joe Kissell sheds light on some of the common points of pain and confusion when starting a Mac from a duplicate.Show full article
In this first installment of FlippedBITS, I want to look at what happens when you boot your Mac from a duplicate (or “clone”) of your startup disk. In doing so, I hope to clear up several common points of confusion, particularly regarding ongoing backups and syncing other types of data.
For years I’ve recommended a three-pronged backup strategy consisting of versioned backups (such as those produced by Time Machine or CrashPlan), bootable duplicates (complete copies of everything on your startup disk, stored on an external drive), and offsite data storage (either in the cloud or by rotating physical media to other locations). Together, this combination can protect your data against almost any disaster, while making recovery as painless as possible. (For complete details about my suggested strategy, including the steps to create a bootable duplicate, see “Take Control of Backing Up Your Mac.”)
It’s simple enough to make a duplicate using a tool such as Carbon Copy Cloner or SuperDuper; having done that, you can use the duplicate to boot your Mac either by selecting it in the Startup Disk pane of System Preferences or by holding down Option while restarting and selecting the volume containing the duplicate. Doing so enables you to get back to work immediately if anything goes wrong with your startup disk; running from the duplicate makes your Mac behave as though nothing had happened. So far, so good.
But, based on numerous email exchanges I’ve had with people who have read my various books and articles about backups, what happens once you’ve booted from the duplicate is sometimes unclear. Some people expect a duplicate to behave entirely like the original in every situation, which turns out not to be quite true. Others worry that the duplicate will cause all sorts of problems because it’s not enough like the original, resulting in extra, unnecessary steps. To untangle things, let’s start with the least ambiguous situation.
Swapping Your Startup Drive -- Suppose your Mac’s internal hard drive dies completely, so you remove it from your Mac and replace it with the drive on which you’d previously stored your bootable duplicate. Your Mac doesn’t care about the fact that the new hard drive may have a different brand, capacity, or speed. All it knows is: here’s a disk with exactly the same data in exactly the same place. It is, for all practical purposes, the same disk. You can carry on as if nothing happened; everything, including your backups, should simply pick up where they left off, which is almost certainly what you want.
Now, there is one little catch. What if there was a time lag between when you made the duplicate and when you started using it? And what if, during that lag, you created or edited data on your startup disk — and backed it up to a destination other than where your bootable duplicate is stored? Now you have a startup disk that’s somewhat out of date, and to make it current, you’ll have to go to that other backup to locate and restore any important files that were changed after you last updated the duplicate. This, I’m sorry to say, is often an entirely manual procedure. In many backup apps (and again, I’m thinking especially of Time Machine and CrashPlan), there’s no simple way to say, “Show me all and only the files that changed and were backed up after time x.” You may have to dig through folders one by one in your backup archive to find these files. You could ask the software to restore everything backed up after a certain time, overwriting any existing files, but that would take quite a while. It’s a pity that many otherwise highly competent backup apps don’t account for this usage case.
Booting from an External Drive -- Although the situation I just described is the least ambiguous, it’s also relatively infrequent. The most likely scenario, which gets more confusing, is when your regular startup disk is still present and functional but you hook up your duplicate and boot from it temporarily. Perhaps you’re doing this to verify that the duplicate works (in which case you may be running from the duplicate for only a few minutes), or perhaps your startup disk is having problems and you want to run a disk repair utility while carrying on with your regular work.
Either way, let me start by saying what isn’t a problem in this scenario. For one thing, it doesn’t matter if your startup disk is external. Apart from speed differences, your Mac should behave identically whether the startup disk is connected via an internal SATA port, USB, FireWire, Thunderbolt, or whatever. So, don’t let that trouble you in the least.
For another thing, it doesn’t matter if data happens to sync with the cloud while you’re booted from the duplicate. For example, if you use iCloud, your calendars, contacts, bookmarks, and so on will sync in the background. You need not worry that the outdated data already on your duplicate will somehow overwrite what’s in the cloud; on the contrary, the cloud has the “master” copy (sometimes called the “truth”), so it will bring the data on your duplicate disk up to date. Similarly, if you use Dropbox or another cloud-based file storage service, it will bring your disk up to date with the latest truth from the cloud, and it’s unnecessary for you to fret over that in the slightest.
(You do need to fret if you use POP for email, or if you have any rules or filters that file incoming email from IMAP or Exchange servers into local mailboxes. That could get messy, with the duplicate being changed in ways that can’t easily be applied back to the original, so if in doubt, refrain from checking your email at all while booted from the duplicate.)
You need not even worry about aliases — usually. When you create an alias to an item that’s on your current boot drive (that includes items in the Finder’s sidebar and in your Login Items list), Mac OS X creates relative links. That means if you make a duplicate, boot from the duplicate, and open an alias, the item that opens is the one on the duplicate, not on the original disk. (And that’s probably what you want.) That’s not to say your Mac might not have a script, a symbolic link you created in Terminal, or some other pointer that references a file or folder by disk name, and if it does, you could accidentally open the wrong copy of a file or application, or save data to the wrong disk. (If you’re concerned and want to be absolutely sure which item you’re opening, navigate manually from the top level of your disk when booted from a duplicate.)
However, at least one significant thing is most likely different, even though you may not notice it. If your duplicate had the same name as your startup disk (presumably the most common case), something slightly weird can occasionally happen. Mac OS X won’t let two mounted volumes have exactly the same name. In the Finder, they may look like they have the same name, but if you already have a volume called “Macintosh HD” mounted and then you mount a second one, behind the scenes, the second one gets a different working name (in this case, “Macintosh HD 1”). That’s because many things that happen on your Mac depend on being able to locate a disk by name, and if there were any ambiguity, a file might get put in the wrong place.
Ordinarily, this on-the-fly renaming just works, but it’s not foolproof. What if, during the time you have both “Macintosh HD” and “Macintosh HD 1” mounted, another user on your network connects to your Mac and copies a file to what is now “Macintosh HD” — your duplicate? You might not notice it, and when you switch back to your usual startup disk, the file would be missing. Similar things can happen with file-synchronization apps, software downloads, and other operations. Furthermore, sometimes Mac OS X gets confused and doesn’t correctly update its behind-the-scenes list of volume names, so you could, for example, encounter a situation in which “Macintosh HD” is a volume you mounted after “Macintosh HD 1.”
On the other hand, renaming your duplicate doesn’t necessarily solve these problems. If your normal startup disk is named “Cindy” but you’ve booted temporarily from “Kate,” you may avoid mismatched name issues right now — but later, if you have to start using “Kate” permanently, apps and users that were still trying to save data to “Cindy” could get confused. All in all, I think you’ll get the best results if your duplicate has the same name as the original disk, but you should follow a few steps (just ahead) to avoid problems while running from the duplicate.
Meanwhile, you may have to think about another subtle background process: backups! After all, your backup software is probably configured to run automatically — perhaps once an hour (like Time Machine) or continuously (like CrashPlan). Backups usually don’t begin immediately when you boot your Mac, but they could easily kick in within 10 or 15 minutes. What if you’re planning to run your Mac from the duplicate for longer than that, but not permanently? Should you let your backups proceed — meaning they’ll be backing up the duplicate — or should you turn them off?
In general, there’s no harm, and considerable benefit, in letting backups run. Your backup software should act as though your duplicate is your regular startup disk and keep copying files to its normal destination as though you had restarted normally. That’s probably what you want, because if you create or modify a file while running from the duplicate, it can then be backed up. The problem is, in fact, with the opposite case: what if you modify a file but it isn’t backed up (perhaps because the time for the next periodic backup run hasn’t rolled around yet)? When you switch back to your regular startup disk, the file won’t be there (or won’t be current), and it won’t be in your backups either. It will still be on your duplicate — but only if you think to check there before you update your duplicate the next time; doing so will probably delete the new file because it’s not on your startup disk.
Taking all this into account, here are my recommendations for what to do when you must boot from a duplicate for a short period of time:
If you can avoid creating, modifying, or downloading files, do. If you can’t, make sure they’re synced to the cloud, copied back to your regular startup disk, backed up, or otherwise made available to yourself when you return to your usual disk later.
Let regular, versioned backups (such as Time Machine and CrashPlan) run normally. But if (per the last point) you can’t avoid creating files, make sure your backup software has in fact backed them up before switching back to your customary disk.
Turn off any scheduled updates to your bootable duplicates. The last thing you want is for your duplicate disk to clone itself back onto your main startup disk while you’re testing it, or for the software to freak out in trying to clone the original over the now-booted duplicate.
Avoid letting other users connect to your Mac, especially to upload files.
Booting a Different Mac -- There’s one more scenario to consider: booting one Mac with a duplicate of another Mac’s startup disk. For example, imagine that you created a duplicate of your iMac’s startup disk and then you had to take your iMac to the shop for repairs. In the meantime, you hook up your duplicate to your MacBook Pro so it can “pretend” to be the iMac. As long as the MacBook Pro supports the same version of Mac OS X your iMac was running, this arrangement should work fine — with, as you might have guessed, a couple of qualifications.
First, although this situation is ostensibly similar to the last one — booting a Mac temporarily from another drive — the time frame involved could be longer (days or weeks instead of hours). So, it’s impractical to avoid modifying files, checking your email, and the like. Therefore, I recommend that you use the duplicate disk on your MacBook Pro as you normally would use the internal drive on your iMac, and then — once your regular iMac is back in service — hook up the external duplicate and reverse the cloning process (copy everything from the external drive back to the iMac’s internal drive it started on).
Second, while your MacBook Pro is running from the duplicate, it will by almost every measure appear to be the iMac. It’ll even use the iMac’s name for file sharing, screen sharing, and the like. However, every Mac has several unique identifiers, including a serial number, a UUID (universally unique identifier), and a MAC (media access control) address for each network interface. Some pieces of software check one or more of these unique identifiers to verify that they’re still running on the same Mac on which they were authorized or licensed.
The most common example is iTunes. If you authorize your iMac to use your iTunes account and then start up your MacBook Pro with a duplicate of the iMac’s disk, that doesn’t mean the MacBook Pro is automatically authorized. You must authorize it manually, if you haven’t done so previously (in iTunes, choose Store > Authorize This Computer). But, if you’ve already run out of authorizations — Apple limits you to five — you may be out of luck unless you can deauthorize one of your other computers or reset all your authorizations, the latter being something that Apple allows you to do only once per year. Other software may make you jump through similar (or worse) hoops.
Don’t Sweat It -- As convoluted as this all may sound, booting your Mac from a duplicate is usually a simple and problem-free operation. But it never hurts to have a better grip on what’s going on behind the scenes, just in case. In particular, think about whether you’re going to be using the duplicate long enough to add or modify files on it manually. If not, there’s no harm in simply switching back to the original. But if you are going to be working from the duplicate for any significant period of time, you’ll need to clone it back to the original when you’re done.
A final note: keep those duplicates up to date. It would be overkill to update them every hour, but once or twice a day is not a bad idea. Remember, the longer the gap between the last time you updated your duplicate and when you discovered you needed to boot from it, the greater the chance of missing or outdated files that you may have to laboriously restore.
Article 3 of 8 in series
by Joe Kissell
Are your passwords strong enough to resist an automated attack? If you believe any of several common password myths, they may not be. In this installment of FlippedBITS, Joe Kissell examines a few of the most dangerous myths about password security and explains smarter and safer practices.Show full article
In the course of writing “Take Control of Your Passwords,” I came across — and attempted to debunk — quite a few myths involving password security. Of course, I encourage you to buy the book to read about password problems and my recommended solutions in detail, but for this installment of FlippedBITS, I want to focus on four extremely common misconceptions about passwords, all of which can lead to dangerous behavior.
1: Nine Is Enough -- I want to begin with a myth I propagated myself in my now-obsolete 2006 book “Take Control of Passwords in Mac OS X.” Although what I said in that book was reasonable based on the available data at the time, I grossly underestimated the rate of technological progress. So, I hereby retract and apologize for a particular piece of advice I gave back then: I said that if you chose a random 9-character password consisting of upper- and lowercase letters, digits, and punctuation, you’d be effectively safe from any attack, because it would take centuries, on average, for even a supercomputer to crack such a password by brute force.
Well, it turns out that I was off by a few orders of magnitude. Today, with off-the-shelf hardware and freely available cracking software, a nine-character password can be broken in a maximum of five and a half hours (that’s maximum, not minimum!). If your password contains nine or fewer characters, regardless of how random it may be, it’s about as unsafe as a Wi-Fi connection protected with WEP (which is to say, safe against only the most casual snooping).
If nine characters are too few these days, how long should a password be? I wish I could give you a straight answer, but the truth is “it depends.” For example, I could claim, with some justification, that a random 14-character password is effectively safe from brute-force attacks given today’s technology. But I’d have to qualify that in a few different ways.
First, I have no idea what tomorrow’s technology will look like. Maybe a few years from now, someone will develop a quantum computer that can crack any 14-character password in the blink of an eye. I don’t expect that to happen so soon, but I’d be foolish to bet against it.
Second, not all encryption techniques are equally secure. A password that’s protected with a weak encryption algorithm might be crackable in seconds, whereas the same password, encrypted with a better method, could thwart a brute-force attack for years. Related to this is that some password security systems put additional barriers in place to slow down the rate at which passwords can be guessed. Although these aren’t foolproof (as I discuss in a moment), they can, in certain situations, give a simple password much higher effective strength.
Third, length isn’t the only factor that affects a password’s strength. As illustrated brilliantly in the xkcd comic Password Strength, even a password consisting entirely of lowercase English words (such as
correct horse battery staple) can be just as strong as a shorter but more random password with a mixed character set. That’s because a password’s entropy (a mathematical approximation of how hard the password is to guess) can come from length, character set complexity, randomness, or any combination of these. Higher-entropy passwords are more resistant to automated attacks, but there’s more than one path to entropy. (If you’d like
to test a given password’s entropy, there are many online tools that let you do so. I quite like the zxcvbn tool for this purpose.)
We can take some comfort in the fact that each additional character in a password increases its strength exponentially. So, if we were to restrict ourselves to just 26 lowercase letters, a 10-character password wouldn’t merely be 10 percent better than a 9-character password — it would be 26 times better! There are over 5 trillion possible passwords consisting of nine lowercase letters (26^9), but make it ten letters (26^10), and there are more than 141 trillion possibilities. That means a system that can crack a 9-character random password in 5.5 hours could take over 500 hours to crack a 10-character random password — a huge difference.
Even so, 500 hours is too little for my comfort. You could make that more than 500 years by choosing a 12-character password, which certainly seems safe enough for all practical purposes. But then, that’s what I thought about 9-character passwords seven years ago. So, when I suggest 14 as a safer number, I’m building in enough of a buffer to account for a few years of technological development, not in any way saying that such a password will in fact be uncrackable for the over 4,000 millennia it would take at today’s rate.
2: Old Tricks from Old Dogs -- I’ve encountered quite a few people — including some major names in the Mac world you’d recognize — who have developed mnemonic techniques for creating and remembering passwords that they imagine to be quite strong. Although specifics vary, there tends to be a consistent element or easily constructed pattern in each password, along with some site-specific portion. For example, maybe I use
zombieGooCats for Google and
zombieAppCats for Apple. (In reality, most people I know who do this sort of thing have far more sophisticated techniques, but you get the general
I myself once (cough) advocated such an approach, but I’ve since seen the light. The problem with all such tricks — and that also goes for “leet” or “1337” (replacing letters with similar-looking numbers), using patterns of keys on a keyboard, and so on — is that no matter how clever you think you are, hackers and their advanced cracking algorithms are smarter. These tools can test a vast number of subtle patterns that few humans would notice, which means even a fairly long, fairly random-looking password might in fact be quite easily guessable. Because remember, we’re not worried so much about humans guessing your password but about machines guessing it, and machines are likely to test lower-entropy passwords — especially those based on common mnemonic techniques — long before higher-entropy passwords. (And, if you use the same technique to construct all your passwords from patterns, an attacker who learns one or more of your passwords has an even bigger leg up in guessing the rest.)
More to the point, any technique that relies on your brain for creating and remembering all your passwords is, in my opinion, a waste of mental effort that could be put toward more useful pursuits, such as thinking up bad puns. We have computers and iPads and iPhones and other devices to do this sort of tedious work for us, and they’re much better at it than we are. Let a password manager such as 1Password or LastPass generate, remember, and enter passwords for you, and then you can make them as long and random as you like — it’s no more effort for an app to make a 32-character password than a 10-character one. Sure, you’ll still need to remember a few passwords, but if you’re doing it right, it’s only a few. (I have only 5 passwords memorized, out of more than 600.)
3: One Password to Rule Them All -- Speaking of password managers, these tools make it easy to create a unique random password for every single site and service that uses passwords, and I recommend doing so. I can’t emphasize strongly enough what a bad idea it is to use the same password in more than one place — even if it’s a great password. The fact that reusing passwords is entirely unnecessary if you rely on an automated tool makes it that much more egregious an offense.
Why is it so bad to reuse passwords? Well, it seems like every week or so, there’s another news report about some big company experiencing a security breach of some sort in which thousands or even millions of passwords are lost, stolen, leaked, or hacked. This happened recently to Evernote; before that, a long list of other companies had passwords compromised – Facebook, LinkedIn, Twitter, and more. You can bet this trend will continue.
Now, if someone hacks Amazon.com’s servers and gets your password, that’s bad news, no question about it. But if all your passwords are unique, at least the damage will be limited to that one account. On the other hand, if you use the same password for iCloud, PayPal, Twitter, Gmail, and so forth, you run the very real risk that the attacker may try your password at all those other sites, too, doing considerably more damage.
I’m saying: using unique passwords — even strong unique passwords — doesn’t guarantee security. But it does enable you to contain the damage if your password for any one site is compromised. The people most likely to be harmed by password breaches are those who are oblivious to the problem of password reuse. Don’t be one of them!
4: Online vs. Offline Attacks -- Earlier, I mentioned that some sites and services put barriers in place to slow down or derail automated attacks. For example, if you mistype your password once, you might get one or several additional chances to enter it — but with increasing time delays between guesses. And if you enter it incorrectly several times in a row, you might be locked out entirely for a period of time, or until you take some independent action to confirm your identity. The whole point of these barriers is to prevent an automated system from trying many passwords per second until it breaks into your account.
While it’s an excellent idea for developers to employ such barriers, they aren’t as strong as they might appear. That’s because most successful attacks don’t go through the front door, as it were. The real danger comes when, due to a leak or security breach of some kind, someone gets hold of an encrypted file or database that holds all the passwords for a site. With the file in hand, they can perform what’s known as an “offline” attack — they hammer on the raw file with automated tools that check billions of possible passwords per second. Because they’ve entirely circumvented the security measures that slow down guessing, they can potentially decrypt massive numbers of passwords in a short period of time. (I’m simplifying the story here. Smart developers can also use a combination of techniques — the key terms to look for are “salting” and “hashing” — to frustrate offline attacks, but all too often, a programming error or infelicitous security choice leaves gaping holes that hackers can exploit.)
So, don’t assume you can use a short, simple password because you can’t see any way an attacker could try billions of passwords a second. You’d be surprised what someone can do, particularly given physical access to the computer where the password is stored. Your best defense is to use high-entropy passwords (which take longer to guess) and make sure each one is unique.
Don’t Worry, Be Happy If I’ve increased your anxiety about passwords by telling you what’s wrong with techniques you depend on, I’m sorry. Well, only a little bit sorry, because I want you to have just enough discomfort that you take action to improve your password security and reduce the chance that bad things could happen to your digital life. For extensive details on passwords, including further threats and risks you might face — and my stress-free, three-point strategy for password security — please pick up a copy of “Take Control of Your Passwords.”
Article 4 of 8 in series
by Joe Kissell
One of the most popular methods for receiving email is also the source of numerous misunderstandings. Joe Kissell explains why IMAP may be a more effective and useful protocol than POP, and addresses common sources of confusion.Show full article
In today’s installment of FlippedBITS, I want to examine a handful of common misconceptions about IMAP, a familiar protocol for retrieving email from a server. IMAP stands for… well, thereby hangs the first tale. IMAP’s inventor, Mark Crispin (who, sadly, died in December 2012), called the first version of his creation Interim Mail Access Protocol. Versions 2, 3, and 2bis were referred to as Interactive Mail Access Protocol, and version 4 — what’s in use today — is officially Internet Message Access Protocol. Although many Web sites claim that the acronym once stood for Internet Mail Access Protocol, I have found no credible references to back up that claim.
By whatever name, IMAP has always been a means by which email clients can talk to email servers. That puts it in the company of POP (Post Office Protocol) and Microsoft’s MAPI (Message Application Programming Interface). Almost every modern email client — including Apple Mail, Thunderbird, Microsoft Outlook, and dozens of others — supports IMAP as a means of retrieving email. You may very well have been using it for years without even knowing it — iCloud and its predecessors MobileMe, .Mac, and iTools have always defaulted to IMAP for email access.
New Kid on the Block -- The first thing I want to clear up is the persistent notion that IMAP is some sort of newfangled email system, a regular Johnny-come-lately compared to the ancient and revered POP method. Yes, POP has been around quite a while — it was invented in 1984. IMAP came along in 1986. (For perspective, Apple’s Macintosh System Software 5 — the first one to include MultiFinder — was released in 1988.) Both protocols subsequently underwent numerous revisions, but in any case, it’s a bit silly to consider POP “traditional” and IMAP “new.”
Now, it’s true that in the early days, email clients and servers alike were more likely to support POP than IMAP (and even today, IMAP support isn’t universal). So, many of us who have been using the Internet for a long time became accustomed to POP — and a surprising number of people still use POP, often out of habit more than necessity. (I’ll return later to whether that’s a good idea.) But IMAP has been a viable option for decades.
Are You Being Served? -- The usual way people explain the difference between POP and IMAP is to say that with POP, all messages are downloaded from the server to your email client, whereas with IMAP, messages are stored on the server. That’s sort of true-ish, but it’s unfairly misleading in both cases. With POP, you can leave messages on the server if you want to, and with IMAP, you can download all your messages and store them locally. The simplified “IMAP-means-stored-on-the-server” explanation has led countless people to assume that you can use IMAP only when you have an active Internet connection. But that isn’t the case. For as long as I’ve been using IMAP, I’ve maintained local copies of every single message in my accounts, and have never had trouble reading, searching, filing, or otherwise managing my messages when offline.
The best way to think about IMAP is that the server holds the master copy of every message. Whenever an IMAP client connects to the server, it can synchronize changes bidirectionally — for example, new messages in the Inbox download to the client; changes made in the client while it was offline upload to the server, updating the master records. But the exact behavior is determined by the design of the client and settings chosen by each user. By default, Apple Mail (like most other modern email clients) keeps all your messages in sync between client and server. But if you prefer, you can configure your client not to cache messages for offline viewing, to cache only some messages, or to cache the text of messages but not any attachments.
I should add that even though the server stores all your email messages, this in no way prevents you from deleting messages. Although, again, the exact behavior varies according to your client and your settings, when you delete a message locally, your client normally tells the server to delete its copy too.
I’ll File Away -- Another prominent difference between POP and IMAP is that IMAP lets you define mailboxes (that is, folders for email messages) that are stored on the server and (in most cases) synced with your email client. In general, the effect is that no matter which IMAP client you use, on which platform, it will always reflect the same set of mailboxes with the same contents; you’ll never have to worry that you might have filed a certain message on the wrong computer.
With POP, there’s no such thing as server-based mailboxes, just an Inbox, so any filing you do must, by definition, be done in the client. However, with IMAP, even though server-side mailboxes are supported (and quite handy), if you prefer to store some or all of your messages in local mailboxes, nothing’s stopping you. In fact, if your IMAP provider imposes a storage quota, you may want to move messages from server-based mailboxes into local mailboxes from time to time in order to free up space on the server.
The Same Thing, Only Different -- I’ve heard it said that if you configure your POP client to keep all messages on the server — that is, not to delete them after they’re downloaded — then POP becomes so similar to IMAP that you probably won’t be able to tell the difference. But that’s very far from the truth.
Apart from the lack of server-based mailboxes (which, of course, you’re not obligated to use in IMAP), leaving messages on a POP server is much different from leaving messages on an IMAP server. Crucially, IMAP servers keep track of which messages you’ve read, replied to, and forwarded. So, suppose I connect to a POP account that has 15 messages in the Inbox. I download and read them, but leave them on the server. Now I go to a different client or computer and connect to the same POP account. The same 15 messages will download again (along with any that have arrived in the meantime), with no indication of which ones I’ve already read. By contrast, if I do the same thing with a pair of IMAP clients, each one will show me the same thing — these messages have been read, those haven’t; this one has been replied to; that one was forwarded; and so on. This makes it much easier to switch among clients — something that becomes increasingly important as more of us have not only multiple computers but also smartphones, tablets, and other Internet-connected gadgets.
Speaking of multiple clients, you should be aware that POP permits only one connection at a time per account, while IMAP has no such limit. So, although your three Macs, two iPads, Windows PC, and iPhone can all maintain live connections to an IMAP account, they’re forced to take turns with a POP account.
All of a Piece -- But now, let me turn that around and address another misconception, that all IMAP servers are created (more or less) equal. Would that it were so, but no. IMAP servers are as frustratingly different from each other as clients are. It all comes down to three words: specification, implementation, and configuration.
The IMAP specification, as I mentioned earlier, has undergone a number of revisions. In addition, it supports the use of optional extensions to provide extra features. When it comes time to implement the specification, one developer might use an older version of the spec, or interpret part of it in an idiosyncratic way, or choose to include or omit various extensions for one reason or another — while the next developer might make entirely different choices. And some developers might decide that the standard IMAP approach doesn’t meet their needs, so they leave things out, slap extra things on, and rejigger other things so they work in surprising ways. (This happens more often than I’d like to admit, although Gmail’s flavor of IMAP is arguably the least IMAP-like, which is not surprising since it was an afterthought rather than a part of the original Gmail design.) Moreover, IMAP servers have a variety of settings a system administrator can configure, just as IMAP clients have user-configurable preferences. All these variables can make any IMAP client/server pair behave much differently from any other.
I can’t tell you how many times I’ve had to say things like, “Yes, your IMAP server supports subscribing to specific mailboxes, and so does Outlook, but Apple Mail doesn’t,” or “Apple Mail supports IMAP IDLE (see “How Apple Mail May Be Anything but IDLE when Pushing Email,” 22 October 2012) but your IMAP server doesn’t,” or “Gmail’s idea of archiving bears only the remotest resemblance to Apple’s idea of archiving.” One especially troublesome area is the way various IMAP servers and clients handle deleting messages — a messy topic I address somewhat in my books about Apple Mail (“Take Control of Apple Mail in Mountain Lion” and “Take Control of Mail on the iPad, iPhone, and iPod touch”) but won’t delve into further here.
POP on over to IMAP -- Notwithstanding the several quirks and annoyances of certain IMAP implementations, my fondness for IMAP is right up there with my fondness for chocolate. (That’s way up there, in case you were wondering.) Let me summarize the advantages of IMAP over POP:
The server keeps a master copy of all your data (including mailboxes and message metadata such as read or replied). So you’ll see the same thing with any client on any platform.
You can connect to an IMAP account from multiple clients at the same time.
If your client supports it, you can have it download only message headers, with full message bodies on demand.
You can ask your client to search for messages on the server, even if they haven’t been downloaded. (The iOS version of Mail supports this, but the Mac version doesn’t.)
The oft-heard objection to IMAP that it takes away one’s control is a myth. As long as you have your client configured to cache a local copy of all messages and to delete messages on the server when you delete them locally, you maintain just as much control over your email as you do with POP. Most of the old assumptions that led users to favor POP — such as the expectation that a person will use a single computer for email most of the time, and the belief that online storage is expensive — are no longer valid in today’s world.
Are there still legitimate reasons to use POP? Sure. For one thing, it’s less chatty than IMAP, so it tends to be better in low-bandwidth situations, especially when lots of users are connecting to an underpowered server. (Having said that, mobile IMAP clients typically manage to do a great job even over slow cellular connections, but that assumes optimization of both client and server for that purpose.) Also, most providers cap each user’s IMAP storage quota, so if you have vast amounts of stored email, you may be forced to offload some of it to local mailboxes; by contrast, POP normally holds onto messages only until the user picks them up, so its storage requirements tend to be lower. And, if you’re concerned that your email provider can’t be trusted or is vulnerable to hacking, you might prefer not to keep unencrypted email on a server any longer than necessary. Finally, not all email providers support IMAP. But that leads me to my final point.
Stuck in the Past -- I’ve heard from a number of people who tell me they’d like to use IMAP, but they can’t, because their ISP doesn’t support it — or charges extra for it. So, two things here.
First, even if your ISP doesn’t offer IMAP for accounts on its own email server, that in no way prevents you from using another IMAP provider. When an ISP says they charge extra for IMAP, that means they charge extra to use their IMAP server, not any IMAP server. You can go right ahead and use iCloud, Yahoo Mail, AOL, Gmail, or any of a hundred other services that offer IMAP access to email — many of which are free.
Second, if your main email address comes directly from your ISP, and that ISP doesn’t support IMAP, you can usually set up an IMAP account with a different provider and then forward mail from your ISP to the new IMAP account. (Exact directions to do this depend on the provider.) That way, anyone with your old address can still reach you, while you get to enjoy the advantages of IMAP.
If you’ve weighed the pros and cons and decided that a switch from POP to IMAP is for you, see if your existing email provider offers an IMAP option — sometimes it’s as simple as flipping a switch on the server side, although you’ll likely have to configure an entirely new account in your email client. For further guidance, I recommend Kirk McElhearn’s Macworld article “How to convert a POP email account to IMAP.”
Article 5 of 8 in series
by Joe Kissell
Let’s start at the beginning.
Java, East of Krakatoa -- Java is the name of the fifth-largest (and most populous) island in Indonesia. I’ve been there a couple of times, most recently when I turned 40. My wife and I hiked up to the rim of Mt. Bromo, an active volcano, at sunrise on my birthday. Come on over some evening and we’ll show you our slides over a nice cup of… java. It so happens that a great deal of high-quality coffee is grown on the island of Java, hence the nickname. (It also so happens that I single-handedly consume 3.5 percent of the world’s coffee; hence another nickname for coffee, “Joe.”) In the early 1990s when a team of engineers at Sun Microsystems was developing a new programming language, they toyed around with several names before settling on Java, allegedly because they, too, were coffee enthusiasts.
So, for our purposes, Java is a programming language. I could tell you that it’s an object-oriented language largely based on C++, but if you’re a programmer you already know that, and if you aren’t, you wouldn’t care. Let’s just say that as programming languages go, Java is a pretty nice one. It’s powerful, popular, and — crucially — designed in such a way that once a Java application is compiled, it can run on many different platforms. That’s right, a given Java application can run on a Mac, a Windows PC, a Linux PC, or a smartphone without any modifications. (In practice, that’s a bit of an oversimplification, but it’s a convenient fiction.)
How does Java pull off this feat of legerdemain? It relies on something called a virtual machine. If you’ve ever run Windows or Linux on your Mac using an application like Parallels Desktop or VMware Fusion, you already have a general idea of what a virtual machine is — it’s an environment, created in software, that functions like a physical computer. Just as a Windows virtual machine lets you run Windows on a Mac (or even within another copy of Windows), the Java Virtual Machine (JVM) lets Java software run on any platform. Each host platform has a different JVM that’s designed to run on its physical hardware — for example, Intel x86 chips have one JVM, while ARM chips have a different one.
Now, there’s a little more to it than that, so please bear with me for two slightly technical paragraphs.
First, when I say the JVM lets “Java software” run on any platform, the software I’m referring to is what’s known as Java bytecode. Java bytecode isn’t Java as such, but rather a sort of intermediate language created when Java code is run through a program called a compiler. Ordinarily, this distinction wouldn’t be important to a non-programmer, except it turns out that other programming languages besides Java can also be compiled into Java bytecode, and then run by the JVM. So, someone could write a program in, say, Python or Ruby, and use a special compiler to build that into something that, as far as the JVM is concerned, is indistinguishable from a program written in Java. In this article, we’re concerned with any software that runs in a JVM, regardless of what language it was written in.
Second, a JVM by itself is usually not enough to enable Java bytecode to run on a computer. You also need a platform-specific version of the Java Class Library, which tells the JVM how to do particular tasks on that platform. For example, maybe a Java program contains an instruction to play the system beep sound. Mac OS X does that one way, while Windows does it another way. So, the Java Class Library takes an instruction that the JVM is trying to send to the host platform and passes it on in the form the host platform expects. The JVM and the Java Class Library are almost always distributed together as a package, and that package is known as the Java Runtime Environment (or JRE), commonly shortened to “Java Runtime.” The Java Runtime is sandboxed (much like iOS and Mac App Store apps), which was supposed to help with security, but secure sandboxes are extremely difficult to develop, and the Java sandbox hasn’t fared well — I’ll return to that issue shortly.
To sum up thus far: Any device with a Java Runtime installed can run Java bytecode, which may have been originally written in Java or some other language.
Once Upon a Platform -- In the early days of Mac OS X, Apple not only included a built-in Java Runtime (licensed from its then-owner Sun), it actively promoted Java as a “first-class citizen.” Developers were free to write their applications in Objective-C, Apple’s own programming language that was originally part of NeXTSTEP, or in Java. Either way, users would end up with a valid application that looked and felt (more or less) native. (Java apps have often been criticized as feeling “not quite right” because they often use interface elements that are different from those of native Mac apps, but that’s a relatively minor point.) As a result, lots of Mac apps were — and a few still are — written in Java.
Java isn’t just for stand-alone, double-clickable applications, mind you. A Java applet can also be embedded in a Web page. Assuming your computer has a Java Runtime installed, your browser has a Java plug-in (to support embedded applets), and Java support is enabled, highly complex programs called applets can run right inside your Web browser. Before Flash and Silverlight began to catch on, Java applets were a common way to add interactivity and complex computational capabilities to Web pages.
But over the years, Java has gone from first-class citizen to suspiciously regarded foreigner (and not just on the Mac). The whole story is long and twisted, involving a combination of technical, legal, and political issues. I’ll hit just a few recent highlights.
Java — including the tools to develop and compile it, the runtime environments, and various other pieces — has been open-source since at least 2007, but it’s maintained primarily by Oracle Corporation, which acquired Sun Microsystems in 2010. Although Oracle’s implementation of Java isn’t the only one, it’s as close as you can get to the “official” version. For a long time, the version of the JRE Apple included with Mac OS X was always several months or more behind Oracle’s latest version. And this was a problem when, for example, a security flaw was discovered. Oracle might fix it quickly, but Macs remained vulnerable for some time, until Apple caught up.
Let’s talk about those security flaws for a moment. I’m sorry to say the Java Runtime has had a lot of serious security problems, and more turn up all the time. (To be precise, Apple’s Java updates in 2013 alone address 56 unique vulnerabilities.) Notice that I said Java Runtime — it’s not the Java programming language itself that has issues, but rather the environment used to run Java bytecode. Even then, the real problem isn’t the Java Runtime as such, but rather the fact that if your Web browser has a Java plug-in installed and enabled, and you happen to visit a Web page that contains a malicious Java applet, it can do all sorts of serious damage. Some of the flaws enable Java code that’s supposed to stay safely within your Web browser to jump outside the sandbox, as it were, and cause all sorts of mischief elsewhere on your computer. It’s nasty, nasty stuff. And the bad guys have been working overtime to find and exploit these security holes.
Apple has used multiple tactics to address these problems, and for some time now has been trying hard to push users in the direction of not using Java at all.
Starting with Mac OS X 10.7 Lion, Apple no longer includes a Java Runtime with the operating system, but if you try to run a Java app, your Mac prompts you to download and install Java Runtime – it’s a matter of a few clicks. What you get if you do that is not the latest release. Apple gives you a version of Java 6 (that is, build 1.6.x), whereas the latest from Oracle is Java 7 (that is, build 1.7.x). If you want Oracle’s version, you can download it, and installing it will override Apple’s version. But you probably shouldn’t do that, because Java 7 has had even more security issues than Java 6. For the time being, Apple is actively updating its version of Java 6 with security patches, while Oracle is maintaining Java 7 with comparable fixes. And, unlike in past years, Apple is now delivering many of those patches just as fast as Oracle. In addition, Apple has blocked Safari from using certain particularly vulnerable versions of the Java plug-in. (Meanwhile, Java isn’t available at all on iOS, and you can see why.)
Joe on Java -- I want to reiterate two main points to be sure they’re crystal clear. On the one hand, neither the Java programming language nor the Java Runtime will hurt you or your Mac. Merely having the Java Runtime installed does not introduce any security risks. In fact, even running stand-alone Java applications is safe, as long as they come from well-known sources. Or, to put it differently, it’s just as safe to run a stand-alone Java app as it is to run any other app (because, after all, any app could in theory be compromised).
On the other hand, having Java enabled in your browser is, at this point, wildly dangerous. I strongly suggest turning it off. To do this in Safari, choose Safari > Preferences, click Security, and uncheck Allow Java. In Chrome, visit
chrome://plugins and click the Disable link underneath Java. In Firefox, choose Tools > Add-ons, click Plugins, and click the Disable button next to the Java Applet Plug-in.
If you’re using the latest version of Safari, you can enable Java selectively for individual Web sites (leave Java enabled, but then agree to each site’s usage of Java individually if you’re sure it’s safe; for details, read “Safari Updates Add Extra Layer of Java Protection,” 26 April 2013). But the number of Web sites that legitimately use Java these days is small indeed, and I suggest leaving Java off in your browser unless you’re absolutely certain you need it.
Now, in case you’re wondering if you should go ahead and uninstall the Java Runtime altogether, I’ll lay it out for you. If you’re running Lion or later, you’ll have the Java Runtime on your Mac only if you tried to run a Java app (in which case, if you still want to run that app, you still need Java Runtime) or you downloaded it from Oracle yourself (again, presumably because you needed it). If you’re running CrashPlan, which I strongly endorse, you currently need Java. (CrashPlan developer Code 42 Software is working on a non-Java version of CrashPlan for Mac, to be released later this year.) Portions of Adobe Creative Suite, including Photoshop, rely on Java. So do OpenOffice, a few games, and a handful of productivity apps. If you need an app that relies on Java, you must hang onto the Java Runtime. Stick with Apple’s version of Java, and turn it off in all your Web browsers.
If you don’t need Java but still have it installed, you can uninstall it. Rich Mogull has instructions for either uninstalling or disabling it, as the situation warrants, in his Macworld article “How to disable Java on your Mac.”
[Java map by Burmesedays. CC-BY-SA-3.0, via Wikimedia Commons.]
Article 6 of 8 in series
by Joe Kissell
Are you still using an AOL address, or one provided by your ISP? Do you share an email address with your spouse? Have you ever wished you could have a professional-looking email address in your own domain? In this installment of FlippedBITS, Joe Kissell looks at some common ways of using email accounts that are, shall we say, less than optimal, and explains how to improve your email image.Show full article
The first email message was sent in 1971. Over the more than four decades since, there has been plenty of time for the technology to evolve and for people to get used to it. Even so, on an almost daily basis I run into people who are doing it wrong, by which I mean making life unnecessarily difficult for themselves and inadvertently advertising facts that may be untrue or misleading.
In “FlippedBITS: IMAP Misconceptions” (11 April 2013), I talked about common misunderstandings about IMAP. Now I want to step back and look at email accounts and addresses more generally. The less-than-optimal approaches to email accounts I see so often are usually honest mistakes that result from not thinking through the way email works — and the way other people use email. Let me see if I can expose and clear up a few of these trouble spots.
What’s Your Email Address? I’d like to start with the most fundamental fact about your email experience: your email address. The famous 19th-century French gastronome Jean Anthelme Brillat-Savarin said, “Tell me what you eat, and I will tell you who you are.” Were he alive today, he might be able to make a similar judgment based on your email address. And whether you realize it or not, people do judge you by your address!
Now, I’m not merely saying that a Hotmail address is unfashionable. (It is unfashionable and always has been, but that’s neither here nor there.) I’m saying that one can often make an educated guess about a person’s technical ability, employment, and social savvy based on an email address — and those guesses (whether correct or not) may be unfavorable. For example, here are some stereotypes:
At the very bottom of the email address hierarchy are addresses from an ISP — that is, addresses ending in @att.net, @comcast.net, @cox.net, @earthlink.net, @anything.rr.com, @verizon.net, and so on. These betray perhaps the worst misconception, which is that you must accept what your ISP offers or that there are no better alternatives (there are always better alternatives to an ISP’s email). And they suggest that you’re stuck with your provider, because switching ISPs would mean giving up that email address. Even if you’ve been blissfully content with your ISP for years, the possibility always exists that a better, less-expensive, or otherwise more attractive option could appear in the future — or that your ISP could go out of business.
Addresses from Hotmail, Yahoo, Excite, Juno, and similar free email providers imply that you don’t take email very seriously, and may suggest a holdover from student days. And it’s distinctly worse if you have a computer-suggested name like firstname.lastname@example.org rather than, say, email@example.com (which at least tells me you’re an early adopter).
An AOL address tells me you were probably an AOL user back in the days of floppy disks and dial-up modems, and you kept the address just because it was too much bother to change it — or because you weren’t aware there were any alternatives. (More on changing addresses in a bit.) And by the way, if you’re still paying for AOL even though you don’t use them for dial-up access anymore, you’re wasting your money. Did you know you can keep using your AOL address for free?
Addresses tied to Apple’s services — those ending in @icloud.com, @me.com, and @mac.com — tell me you’re an Apple fan (which may be a positive or negative judgment, depending on who’s making it). But if that’s your primary or only address, it also suggests excessive dependence on Apple and a willingness to live with significant limitations when it comes to email.
A Gmail address suggests you’re a bit more sophisticated than the average email user, but not sophisticated enough to set up Gmail with your own domain name (or perhaps too poor — custom domain names used to be free but now require a paid Google Apps subscription, at $50 per user per year). In particular, when I get business email from someone using a gmail.com address, I have to wonder what kind of employer can’t spring for a professional-looking domain name or why the sender is choosing to send from a personal address instead of a work address.
Addresses in a .edu domain are fine for students and teachers, but when someone continues using such an address years after graduating, I wonder if it’s due to unemployment. Of course, you may just be proud of your alma mater, but using such an address for non-school correspondence years later is a bit like continuing to wear a class ring in your 40s. It makes people wonder why you haven’t moved on.
If your address belongs to a business’s domain (@macworld.com, @apple.com, @wellsfargo.com, etc.), that tells me you’re employed, and it tells me something about your employer if not about your specific profession. That’s all fine, but if I receive personal email from an unambiguously business address, I wonder what’s going on. Perhaps the person does not have the sense to keep personal and business email separate, or is too lazy to get a personal account somewhere.
Of course, if you own your own business, that’s another story altogether, because there’s often no need to separate personal and business correspondence. You might get email from Adam’s firstname.lastname@example.org address that has nothing to do with TidBITS. That’s his domain, and he can do whatever he likes with it. So it’s a business domain that also functions as a personal domain, which brings us to the next category.
Email addresses in a personal domain — that is, one you own yourself, whether or not it involves your name — tell me that you’re a highly clueful person, with at least modest technical sophistication and a better-than-average awareness of How Things Work. I also know that you could switch email providers if you ever found that to be necessary. The nature of your personal domain might also tell me something. I chose the domain alt.cc — which I use for both personal and business correspondence — largely for its compactness (I once co-owned the domain name computergeeks.com, which was far too unwieldy), and I also own the domain joekissell.com (for obvious reasons). But if someone sends me email from an address ending in @misogynist.com, you know I’m going to raise an eyebrow as I reach for the Delete key.
Of course, you may have more than one address, and you may carefully choose which one you use based on the situation. I certainly do. I have every single type of address listed above (except .edu), but I use them selectively and with attention to the recipient, the occasion, and what impression I’m trying to convey.
If you regularly use one of the less-desirable email addresses, don’t worry, you’re not stuck with it forever! I’ll make some suggestions in a moment, but first I want to mention another problematic email practice.
A Couple’s Address? Really? Every so often I get an email from a couple who share a single email address. And while that’s adorable on some level, it’s also infuriating. JohnAndNancy@ThePetersonFamily.com sends me a message and it’s signed “John.” Later, I want to tell John something so I send a message to that address, but Nancy replies. I never know who’s going to be on the other end of the conversation.
Look, couples. I’m sure you’re the two closest people ever, that you share a brain, and that you have no secrets from each other. Good for you. But as surely as you each need your own driver’s license and passport, you need to have your own email addresses too. John and I might want to discuss a surprise party for Nancy, and Nancy might want to buy John a gift online without worrying that he’ll see the receipt. There are a thousand other reasons why it’s worthwhile for even the most committed and trusting couple to have separate addresses. If you want to have a family address especially for email both people need to see (such as bills), that’s fair enough, but please do your correspondents a favor and let them know your personal address too. (You do know email accounts are available for free, right?)
Accounts, Domains, and Providers -- Why do so many people use less-than-ideal email addresses? One reason is a misconception that an email account must be tied to a domain name, a provider, or both. But that isn’t so. Sure, you can get an email address from your ISP that, in turn, is tied to that ISP’s domain name, but in fact the elements of email account, domain name, and provider can (and generally should) be entirely distinct.
Let’s start with your ISP — the cable, DSL, satellite, dial-up, or cellular provider you use to access the Internet. Virtually every ISP also offers email accounts, and in some cases they’re set up for you automatically whether you want them or not. But no one is required to use these accounts! If it exists, you can simply ignore it. Go ahead and use Gmail, iCloud, or your favorite IMAP provider for email. The fact that Comcast provides your broadband connection doesn’t obligate you to use Comcast as an email provider. (You may want to at least set up your Comcast address to forward email to your regular address, just in case Comcast uses it to send you support messages or account notifications.)
The same goes for Web hosts. Maybe you have a hosting package with a company like 1and1 or DreamHost. These and countless other similar services usually include email hosting as part of the package, and there’s nothing wrong with using that if you like. But you’re not required to, and it’s often possible to get better and more reliable service from providers that specialize in email. Even if you do go with a Web hosting service, you can and should use a custom domain — not a domain belonging to the hosting provider.
But what about other email providers? If you use another service to host your email, isn’t your address tied to that service? Well, yes and no.
It’s true that if you have an aol.com address, only AOL can host it, and if you have a gmail.com address, only Google can host that. The same goes for all the providers — including iCloud, Yahoo, and Microsoft (outlook.com, live.com, and hotmail.com).
But you don’t have to live with an address in a generic domain. You can have a domain of your very own and then direct that email to your preferred email provider. Even better, you have the flexibility to change email providers if the need should arise. And in many cases, you can still keep your old address as an alternative if you’re concerned that changing it would be infeasible.
Ditch a Locked-In Provider -- If you want the control, flexibility, and favorable impressions that come from having your own domain name, you can make it happen. The exact steps depend on the choices you make, but I’ll outline the process here.
First, pick a domain registrar, find a domain name you like, and register it. I’ve had good results with easyDNS and Directnic, but there are zillions of other registrars, too. These days, the going rate for domain names is about $15 per year — more if you want an unusual top-level domain, less on some bargain sites or if you’re transferring a domain from another registrar. The hardest part of registering a domain is finding a name that hasn’t been taken, but once you’ve done that, the rest of the process should take just minutes.
Next, pick an email provider. If you’re happy with your existing provider (whether iCloud, Gmail, or whatever) except for the fact that you don’t have your own domain name, the simplest approach is to log in to your account at your registrar’s Web site and configure it to forward all email for your domain to your existing address. That way you don’t have to change anything on the receiving side, although you may prefer to change the From address in your email client to reflect your new domain when you send outgoing mail. (This is often easier said than done, but I go into more detail about it, especially for Gmail, in “Take Control of Apple Mail.”)
If you aren’t happy with your current provider, now’s the time to choose a new one. You’ll most likely pay for the service, and although prices vary widely, there are many options under $50 per year. I use the easyMail service from easyDNS, but lots of people swear by FastMail, Google Apps, and other providers. If you choose a new email provider, you’ll have to specify which address(es) you want mailboxes for in your new domain. You’ll also have to follow the provider’s instructions for setting up MX (mail exchange) records with your domain registrar, so incoming email is directed to the right server. That sounds complicated but it’s just a matter of filling in a few blanks on a form, and most email providers and registrars provide clear, simple instructions for doing so, like these from easyMail.
Now, if you’ve changed email providers, configure your email client (such as Apple Mail) on each device you use to log in to your new account with the username and password you chose.
Finally — assuming, again, that you’ve changed providers — forward mail from your old address to your new one. Most email providers and ISPs have a screen somewhere in the account settings area of their Web sites where you can type a forwarding address. By doing this, you ensure that mail sent to your old address will still reach you, even if your correspondents don’t update their address books. (It’s still a good idea to send out change-of-address notices and change important subscriptions and accounts, but forwarding email removes one of the barriers to switching providers.)
Although each provider is different, I’ll explain how this is done with iCloud and Gmail. To forward email from iCloud, log in to your account at www.icloud.com/mail. Click the gear icon in the lower-right corner and choose Preferences from the pop-up menu. On the General pane, select Forward My Email To, enter an address, and click Done. To forward email from Gmail, log in to your account at mail.google.com, click the gear icon in the upper-right corner and choose Settings from the pop-up menu. Click Forwarding and POP/IMAP. Click Add a Forwarding Address and follow the prompts to set it up. Then select Forward a Copy of Incoming Mail To and choose that address from the pop-up menu. From the second pop-up menu, choose what you want Gmail to do with the original message after forwarding it (my choice would be Delete Gmail’s Copy). Then click Save Changes.
Of course, if you were using an ISP’s email account and you change ISPs, your old account, including that forwarding setting, will disappear when you discontinue service. (Worse, someone else might get that username and start receiving your mail, which can be awkward.) So if you’re thinking of switching ISPs, try to wait a few months after you set up your new email address, and tell every single person who sends email to your old address that you’re using a new one, effective immediately. (And, be sure to send that message from your new account, so replies don’t go to your old one!)
Later on, if your email provider goes out of business, encounters security problems, raises prices, or does anything else objectionable — or if you simply find one you like better — you can set up an account with a new provider and change your MX records again (as in Step 2), change your client settings (as in Step 3), and transfer your saved email to the new provider. Your correspondents will never know the difference.
Further Advice -- Having an email address in a domain you control and hosting your email at a provider you like can solve numerous problems and perhaps even improve your image. But that’s just the tip of the iceberg. In my new book “Take Control of Apple Mail,” I discuss many other ways to become a better correspondent, manage your Inbox, and make email a pleasure rather than a hassle. The book covers email etiquette, dealing with incoming and outgoing attachments, using signatures, providing the proper context in replies, judiciously using Cc and Bcc fields, and many other email tasks. I hope you find it helpful.
Article 7 of 8 in series
by Joe Kissell
Most companies that do business on the Internet have published privacy policies, and although they’re often full of tedious legalese, they’re worth reading. Whether they do anything to protect you is another question.Show full article
Sometimes you want to go where everybody knows your name, IP address, shopping habits, browsing history, birthday, mother’s maiden name, and other personally identifiable information. Other times you don’t use the Internet.
Most of us take it for granted that the Web sites we visit collect massive amounts of data about us behind the scenes. If you aren’t aware of this — or if you are, but wish you could keep more of that information private — I can refer you to a little book I wrote on that topic: “Take Control of Your Online Privacy.”
It’s helpful to have greater awareness of who’s collecting what data about you and why. You can do things like changing browser settings, adding plug-ins, and adjusting your preferences on various sites to discover when they track your actions and to reduce (though not eliminate) the endless flow of private information you send out as you use the Web. I talk about all this in my book.
But what about privacy policies? Nearly every commercial Web site has one, and you often have to agree to such a policy (implicitly or explicitly) when signing up for an account. Privacy policies spell out what data the company collects (particularly personally identifiable information), how it’s used, what protections are in place to safeguard it, and so on. Some people mistakenly think that these policies offer some guarantee of privacy or even legal protection. I’d like to disabuse you of that belief in this installment of FlippedBITS.
Sorry to say, but — not to put too fine a point on it — privacy policies by themselves don’t mean diddly-squat.
That’s not to say privacy policies are meaningless, and as I’ll explain in just a moment, I recommend reading them attentively. But don’t mistake a policy for a guarantee.
A policy is just that — a statement about the practices a person or company follows as a general principle. I mean, I have a policy of being honest, but that doesn’t mean I never lie. My library has a policy of charging patrons for overdue books, but sometimes they let it slide. A store has a policy of beating competitors’ prices, but draws the line when someone brings in an ad for a buy-one-get-two-free promotion.
What’s In the Fine Print -- I’ve made my point, I hope, that you shouldn’t put too much trust in privacy policies. But you should read them!
Privacy policies are often full of boring and inscrutable legalese, although a surprising number of them are written in something many of us would identify as closely resembling English. They typically include the following:
What types of information the site collects, under what circumstances, and for what uses. (This may include both general information, such as which browser you’re using, and information that more specifically identifies you as an individual.)
Whether and how the information is shared with other entities, such as advertisers.
What security measures the site uses to protect your data.
How to opt out of data collection.
You should take the time to read these policies — at least for the sites you visit most frequently — for several reasons:
Second, you could discover something disturbing enough to make you stop using the site. Some privacy policies are quite up front about the fact that the sites collect personal data about you and sell it to third parties. Others do little or nothing to safeguard the personal data they collect. If you’re uncomfortable about that, you can take your business elsewhere.
I tried a few sites (type two characters into the search field to get a long list of sites to browse) and found some interesting results:
Wired got a mere 39 — the lowest of any of the sites I checked.
Article 8 of 8 in series
by Joe Kissell
Recent versions of OS X and iOS have a built-in password manager called iCloud Keychain, which generates random passwords for you and syncs across devices automatically. So why would anyone need 1Password (or another third-party password manager)? Joe Kissell shares a long list of reasons, making a strong case for going beyond Apple’s free tool.Show full article
Everyone agrees that passwords are a pain. The idea that each user of a computer, Web site, or online service should gain access using a unique identifier (a username) and a self-selected password must have seemed logical back in the day, but the system hasn’t scaled well. Now we all need passwords for dozens or even hundreds of services, while frequent high-profile security breaches remind us that a password-based infrastructure is inherently fragile and vulnerable.
In response, service providers make ever-harsher demands of their users: create longer, more complex passwords; change them whenever the provider sees fit; answer security questions; add two-step verification; and so on. Frustrated users, in turn, respond in ways that make them far less secure: they often choose easily guessable passwords, and reuse the same password (or one of a few) everywhere.
I’ve been thinking and writing about the password problem for a long time. In the recently published “Take Control of Your Passwords, Second Edition,” I lay out the whole problem from top to bottom and help readers think through a sensible, safe, and sustainable strategy. One key recommendation is to use a password manager whenever possible. This type of software automatically generates, remembers, and fills in passwords as needed, and syncs them across your various devices. Although a password manager alone isn’t a complete solution to anyone’s password woes, it can eliminate a large portion of the hassle while increasing your security tremendously.
There are lots of great password managers out there, and I truly don’t care which one you use, as long as it works well for you. I know that apps like LastPass, Dashlane, Blur, and many others, have lots of fans. In addition, Apple’s own solution, iCloud Keychain, works in Safari for recent versions of OS X and iOS — and it’s free for anyone with an iCloud account. I wrote extensively about iCloud Keychain in another of my books, “Take Control of iCloud.”
My personal favorite, however, is 1Password, which I’ve been using for nearly ten years. I’ve found that it hits the sweet spot of power, usability, and affordability — and it keeps getting better all the time. I like it so much I wrote yet another book about it, “Take Control of 1Password,” which explains how to make the most of the app’s extensive capabilities, many of which aren’t entirely obvious.
But wait a minute! Since iCloud Keychain is free, requires no extra software, and is supported by Apple, why would anyone bother with a third-party product in the first place? I’ve heard this question a number of times. For example, when I covered the latest major release in “1Password 6 for Mac Adds Teams, Expands Sync Options” (18 January 2016), a commenter named Jim inquired:
This would be a great chance to ask the question I’ve always had about 1Password. I hear nothing but praise for it, but… What exactly does it do that Apple’s built-in tools (Keychain, iCloud Keychain, etc.) don’t do?
I’ve read so many glowing reviews of 1Password, yet that’s the part I still don’t get…
I replied by pointing out a number of things 1Password can do that iCloud Keychain can’t, but the question deserves a more extensive answer. After all, 1Password isn’t free and does have a bit of a learning curve — and switching from one password manager to another isn’t always simple. I can understand why this might seem like a Pepsi-versus-Coke choice, but it’s more like pitting a standard can of Pepsi against a Cherry Vanilla Coke float made with artisanal hand-churned organic ice cream — and two straws.
Before I get into the feature differences, let me make two quick disclaimers. First, although I’m talking only about 1Password here, many of the features I point out can be found in other third-party password managers too. And second, I’m not trying to diss iCloud Keychain. In fact, as I’ll explain later, it’s an ideal choice for certain tasks, and there’s no reason you can’t use it alongside a third-party tool.
1Password’s Advantages -- 1Password was developed long before iCloud Keychain was a gleam in Apple’s eye, and over many years it has been refined based in large part on user feedback, an approach that Apple often seems to be allergic to. Here are some of the ways in which 1Password surpasses iCloud Keychain:
Platform Support: If you use only recent-vintage Macs and iOS devices, this might make no difference to you. But if you happen to use Windows or Android devices, or even older versions of OS X (iCloud Keychain was introduced in OS X 10.9 Mavericks), iCloud Keychain won’t help you on those platforms. 1Password, on the other hand, can sync your data to all those locations, although admittedly you’ll need to download a legacy version of the app if you want to run it on Mavericks or earlier.
Browser Support: 1Password works with most popular browsers, so if you prefer to use Chrome or Firefox instead of Safari (or if you switch between browsers from time to time), that’s no problem. iCloud Keychain, on the other hand, works only with Safari (in both OS X and iOS).
Password Strength: iCloud Keychain can generate random passwords for you in Safari, which is undeniably handy. But all those passwords are exactly 15 characters long, following the pattern
XXX-XXX-XXX-XXX, where each X is an alphanumeric character. Because the three hyphens are invariant, all those passwords have an effective length of only 12 characters, and because none of the other characters can be other punctuation, those 12-character passwords are much weaker than ones built from a wider character set. (Also, some Web sites limit passwords to fewer than 15 characters.) 1Password can make random passwords up to 50 characters long, with your choice of attributes; you can even opt for a series of random words instead of random characters, although a password of that type must be considerably longer to be as strong as one composed of random characters.
Additional Data Types: iCloud Keychain can store passwords, username-and-password combinations, secure notes, and credit card numbers, but that’s it. 1Password can also store many other kinds of data, such as software licenses, passports, membership cards, licenses, and bank account numbers. In addition, it can securely store and sync virtually any document you care to drag in, such as a Word document, PDF, or photograph containing confidential data.
CVV Numbers: iCloud Keychain can store credit card numbers and their associated expiration dates, but not CVV (card verification value) numbers. Apple says this is for security, but it means that every time you buy something online, you have to drag your card out of your wallet, look up that number, and type it in. My feeling is that if iCloud Keychain is secure enough to hold my bank account number and login credentials, not to mention passwords that could unlock all kinds of other highly confidential services, it should be secure enough to store and fill in a CVV too. 1Password has no trouble storing and filling in CVV numbers.
iOS App Support: Browsers aren’t the only apps that use passwords. Think of apps like Slack, Buffer, Basecamp, SoundCloud, Instapaper, and dozens of others that connect to online accounts. Using a simple API created by 1Password developer AgileBits, developers can enable their apps to query 1Password directly — it’s much quicker and easier for users than having to switch to 1Password, look up credentials, copy, switch back, and paste. Well over 100 apps have already added this support. And what I find even more interesting is that developers of other password managers can use the same API, so if your app supports 1Password, it also works with other iOS password managers. Although it’s possible for specially modified third-party iOS apps to access saved Safari passwords (which, in turn, may sync via iCloud Keychain), very few apps take advantage of this capability.
One-time Passwords: Many sites now offer two-step verification as an extra security measure. The most common implementation is that after you enter your password, the site prompts you for a second code — a time-based one-time password (TOTP), which is normally generated by a separate app such as Google Authenticator or Authy, and changes every 30 seconds. But 1Password can generate these codes too, meaning you don’t have to install a separate app to obtain them (and you don’t have to switch apps as often either). iCloud Keychain lacks such a feature.
Syncing Options: As you might guess from the name, iCloud Keychain syncs exclusively via iCloud. 1Password can sync via iCloud too, but if you prefer to use Dropbox, direct syncing over Wi-Fi, or even (for iOS devices) syncing your data via a USB cable and iTunes, you can. (Yet another way to sync is to use 1Password for Teams or Families, discussed just ahead.)
Ease of Use: Storing and entering passwords in a browser is one thing, but what if you need to look up a password for some other reason, or make other changes to your secure data? On a Mac, you have to use the ancient Keychain Access app (in
/Applications/Utilities), which is incredibly cumbersome and unintuitive. On an iOS device, no such app exists; you can go to Settings > Safari > Passwords to see and edit your credentials, but even that is a clumsy interface. 1Password’s user interface, by contrast, is far more user-friendly. It’s easy to search, sort, organize, tag, and edit items, and you can even do things like sort your passwords by strength to see which ones might be in need of changing.
Teams and Families: If you want to share certain passwords securely with other people — coworkers or family members, say — you can’t do so with iCloud Keychain. (Like most iCloud features, it’s all about sharing stuff across your own devices, not sharing stuff with other people.) 1Password has long offered a primitive way to share data using Dropbox, but with 1Password for Teams or 1Password Families (each available for a modest monthly fee), your business or family, respectively, has a simple yet secure and versatile mechanism for sharing passwords.
Other Details: 1Password also stores a history of the passwords you’ve used previously for each site. It can alert you to passwords that may need to be changed due to a security breach or because they’re duplicates. And it has quite a few other small conveniences that add up to a much better experience in managing passwords. (If I’ve skipped over anything you find particularly important, please remind me in the comments!)
iCloud Keychain’s Benefits -- Having said all that, let me now change my tune slightly and say some nice things about iCloud Keychain:
Better in Safari for iOS: Because iCloud Keychain is built right into Safari for iOS, it takes at most a tap or two to fill in your credentials and submit a form. Since the advent of extensions in iOS 8, it’s reasonably convenient to access 1Password from within an iOS browser, but you’ll still have to tap an icon to open the Share sheet, tap the 1Password icon, authenticate with Touch ID (or a PIN or your master password, depending on your device and configuration), and tap the desired login item. Of course, 1Password is doing the best it can given the restrictions Apple imposes, but if you want the least possible friction when entering credentials in Safari for iOS, iCloud Keychain is the way to go.
System-level Credential Syncing: iCloud Keychain isn’t just for Web forms. It can also store credentials that are used at a system level, such as Wi-Fi passwords and Internet accounts (Google, Facebook, Twitter, email servers, and so on). So, if you enter the password for a new Wi-Fi network on one of your devices, then as soon as iCloud Keychain syncs to your other devices (usually within seconds), they’ll have that password too and can join the new Wi-Fi network without so much as a password prompt. (For some reason, iCloud Keychain syncs email accounts only with other Macs, not with iOS devices.) Because 1Password doesn’t have the system-level access that would be necessary for such a feat, it can’t perform the same trick.
Reliability: Your mileage may vary, but I’ve found iCloud Keychain to be almost shockingly reliable — it syncs quickly and nearly always does exactly what I expect. I’ve often griped about other types of iCloud synchronization working poorly, but in this case I can’t complain. Because it’s part of OS X and iOS, there’s never any software to update separately, never any data to back up separately, and no worries about compatibility.
Sure, that’s a shorter list of compliments than the one I gave 1Password, but they’re not insignificant. If you use only Safari on Apple devices; have only a modest number of accounts; prefer iCloud syncing; and have no need to store other data types, share credentials, or use one-time passwords, you might be perfectly content with iCloud Keychain. Without question, using iCloud Keychain is a thousand times better than using no password manager at all, and if you like it, more power to you.
However, keep in mind that this isn’t an either/or decision. You can use iCloud Keychain and 1Password together. For example, you might rely on iCloud Keychain to handle your Wi-Fi passwords and the credentials you use most frequently in Safari for iOS, but 1Password for everything else. Or you could try to keep both apps updated with the majority of your passwords, using whatever happens to be easiest at any moment (given your current platform and browser). Or use 1Password to generate new passwords but iCloud Keychain to store and fill them. Although using both together is more work and arguably a bit less secure than picking just one, it’s not an unreasonable approach.