Mac OS X hosts File Regrouped

A few months ago we looked at a method for trimming down the advertising noise on your Mac desktop. With time, a procedure like this gets fine-tuned. Here is the latest for Mac OS X Jaguar.

Historically I have touched on this subject as the first article or so of the year, a way to clean house, as it were. Recently I was taken to task for taking certain liberties in the course of the procedure. So I have scrutinized the complaints and attempted to make the whole thing as legitimate and bullet-proof as I can. Let me repeat my oft-said caveat, though. Your mileage may vary. (0)

This article is a systematic procedure for redirecting visual distractions from unwanted ad servers in a Mac OS X environment. It will borrow shamelessly from my previous articles on the subject. A note about implementing this in a classic Mac OS situation is included below. For other operating systems, take a look here and there. For an application made to accomplish automatically what this article lays out manually, take a look at Privoxy (with thanks to DC, RM & GD for that reference).

If you have previously gone through all or part of this procedure and now you want out, then follow the exit instructions below.



The way this works is based upon how tcp/ip, the network language of the internet, looks up the name of any host (i.e. networked computer or other gadget) that you might throw at it, whether in a browser address line or elsewhere. When you type in a name such as "", your computer does a name lookup in search of a raw numerical internet address in the form of "nnn.nnn.nnn.nnn" that corresponds to that name. It has several standard places to look, both locally and across the network. One internet address,, is called the loopback address, and is specially reserved. It stands for your own machine, sort of like pointing at yourself. Another internet address,, is illegal.

Now what if we combined these concepts? What if we took a known server, such as, and forced its corresponding internet address to be one of those two aforementioned numbers? Well, whatever else might happen, we can be certain that the real server will no longer be contacted. This could be a useful technique if the server in question were doing not nice things to your screen. Let's see what we can do.

At this point, allow me to rehash my disclaimer on conscience. If you are having mixed thoughts about thwarting ad servers, then consider this. A site has a right to be paid somehow for offering a valuable service, and a reasonable level of advertising is acceptable for this. Eudora's supported mode, for example, is a good balance. But the level of online advertising has become so ubiquitous and in-your-face that a line has been indisputably crossed. Fair is fair. You cannot thwart ad servers on every computer you use, so you aren't going to put these guys out of business by silencing them at home or on the few computers you have influence over. Just be reasonable. Support your favorite host sites with a purchase once in a while, that's all. Then press Mute.

There are two basic components to this procedure. They are: set host name lookup order correctly; and install a database of known ad servers.


Part 1: Set the Host Name Lookup Order

The single goal of this step is to tell your Mac to check local resources first for host name lookups. We do this by creating a text file called hosts, located in your /etc/lookupd folder, and which has a single line of content something like this: LookupOrder Cache FF NI DNS DS, the important thing being that the DNS parameter comes after FF and NI.

Mac OS X uses a tool called lookupd to do host name lookups, among other things. For an example of how lookupd performs a host name lookup, type man lookupd in a Terminal window and spacebar down to Configuration Examples. Press Q when done. In all the examples below, a fairly default search order is used. You need to check and record your own existing search order, and only move the position of the DNS parameter to the right of the other two. Because of the variety of ways that host name lookups can be done, you may have one or two additional parameters such as NIS or LDAP specified in your environment. Leave those alone. Tweak the examples to fit your situation. We're only dealing with three specific parameters here, namely NI, FF, and DNS, and their relative positions with respect to each other.

OS X can use two explicit ways of specifying this search order. Out of the box, OS X will search the network for host name lookups first before exhausting its local resources. This is precisely what we want to adjust. We will use the flat file method for this. (1)

First, check to see what your present search order is. It may be okay already. In a Terminal window, copy and paste the following command.

lookupd -configuration

A page of information should be returned that looks something like this:

[Mac:~] damien % lookupd -configuration

ConfigSource: file://etc/lookupd
LookupOrder: Cache NI DS
MaxIdleServers: 4
MaxIdleThreads: 2
MaxThreads: 64
TimeToLive: 43200
Timeout: 30
ValidateCache: YES
ValidationLatency: 15
_config_name: Global Configuration

LookupOrder: Cache NI FF DNS DS
_config_name: Host Configuration

[Mac:~] damien %

Basically, in the Host Configuration section, Cache should be first, and both NI and FF should come ahead of the rest. If so, then skip to Part 2 now. But if in fact DNS comes earlier, then you need to fix it. All you want to do is move the order around a little. Let's do that.

If it doesn't exist already, create the folder /etc/lookupd and a file within it called hosts, not to be confused with the hosts database file, below. To do this, open a Terminal session, and copy and paste the following steps (some of which are redundant in case this folder does indeed exist already).

cd /etc
sudo mkdir lookupd
(Enter your administrator password)
cd lookupd
(If any files exist, make copies of them using the cp command.)
cp hosts hosts.original
sudo echo LookupOrder Cache NI FF DNS DS > hosts

Optionally, you can switch the above order so that flat files get referenced first, like generic unix. (8)

sudo echo LookupOrder Cache FF NI DNS DS > hosts

You'll need to reboot for the changes to take effect. Hotshot unix aficionados can restart lookupd themselves from the command line without rebooting. (6)

Finally, run the lookupd -configuration command once again to check your work. It should look very similar to the example above, with a Host Configuration section identical to whichever of the two search order options you selected. If there is a problem, then stop and regroup. Check your steps. Check the Troubleshooting section. Contact me if you're stuck. If this point isn't right, the rest won't work.

There is also a NetInfo database entry for this search order. However, in all of my tests I found that everything works just fine with the flat file search order alone. So I have chosen to leave out the NetInfo procedure for this. If you're interested in doing it anyway for completeness, then check an Apple article on the subject, or drop me a line. For interest's sake you might like to compare the search order in the Apple screen shots with our own flat file search order above.


Part 2: Install a hosts File

This step finds you a preconfigured hosts file (no relation to the one in Part 1) that already contains an extensive list of known ad servers, then installs its contents into your NetInfo database.

Step 1: Download and Prepare Data File

First, we download some stuff. Download and unpack this hosts file onto your desktop, with thanks and credit to the maintainers. (This is the version of the file, which works flawlessly with OS X. A or loopback version is also available.) (4) Drag the HOSTS file out of its folder and into your Home folder. Rename it to lowercase hosts.

Download and install the unix2dos package from osxgnu. Open a new Terminal window. Run dos2unix on hosts, to fix the line endings. (2) The syntax is simply

dos2unix hosts

It won't make any difference to run it multiple times on the same file, as the endings are fixed the first time and there is nothing to do in successive times. Be sure to do this each time you download a fresh HOSTS file.

There are other hosts files available on the web that are made for this purpose. If you feel like poking around and finding these, now would be a good time. Just save them with names like hosts.this, hosts.that, hosts.other and so on, and all in your Home folder, and duplicate the process with each one. You can load 'em all if you like. Really, though, the first one is more than sufficient.

Though I do not favor editing this large file, I might recommend one edit to the adventurous. Open hosts in TextEdit. Near the top, there is a passel of servers belonging to, which Apple uses to serve up graphics for many Apple web pages. Select these and cull 'em out. Save and exit. Otherwise, after you are done loading this file into NetInfo, you will find an uncanny number of broken graphics on the Apple site. (3)

Alternately, you can download this simple script, with thanks to the Linux guy in my office who cooked it for me! Unpack it to your desktop, and drag the single file called akamai into your Home folder. Now open a Terminal window and move the file to a good place like so:

sudo mv akamai /usr/bin

You've already dragged the HOSTS file into your Home folder and renamed it. Your new Terminal window will open in the same folder by default. Simply type akamai to remove every instance of an Akamai server in the file. Done.

Now your hosts file is ready for loading.

Step 2: Backup Current NetInfo Entries

Backup your existing list of hosts with this command:

nidump -r /machines / > machines.original
cat machines.original

If you have added the odd host or two along the way, you should see them listed along with at least these two:


If you have deleted your last machines directory and since created a fresh (i.e. empty) one, you may want to install your original list of hosts from your backup into the database again before proceeding. Here is the code: (7)

sudo niload -r /machines / < machines.original

Step 3: Load Data File Into NetInfo

Finally, let's move on to the big one. You've downloaded the hosts file, dragged it into your Home folder, and run dos2unix on it. Now it's time to load it into your NetInfo database. (5) Enter the critical command, with (visual feedback) or without (it's faster) the -v switch:

sudo niload -v hosts / < hosts

This will take many minutes, as this hosts file is huge. If you want to import other hosts files into NetInfo, then repeat this process, substituting the respective file name. Up-arrow in Terminal gets your recent commands. Remember to first run dos2unix on any hosts files you use.


Part 3: Tweaking DNS Entries

This step shows you how to adjust to taste. And there is just no accounting for taste. Who knows? Maybe you really want to visit but can't, now that it is "blacklisted". You'll want to be able to edit or delete an entry like this, and also add additional nefarious hosts yourself that you discover over time.

Open NetInfo Manager from Applications/Utilities and unlock it. A directory in this context is the NetInfo database entity used to organize data in a hierarchical way. Select the machines directory in the second column. There are very many entries in there, so give it a minute or three to fill out. They'll be listed in alphabetical order. Some hosts may be grouped together under one, where the remaining ones are treated as aliases for the first. No matter. Poke around until you find the host entry of interest. Suppose it's Select it in the third column, and press Delete (or rename it slightly). You will be asked to confirm. Do so.

Example of NetInfo Tweak

Similarly you can add a new entry. Pick any host near the location where your new host would fit. Press Cmd-D to duplicate it (this will take a few moments, as you are effectively rearranging some thousands of host entries), then select the copy. Its properties will appear in the box at the bottom of the NetInfo Manager window. Click the host name on the right, which will be named something like copy. Edit it to read the name of the ad server host you want to thwart. Click away from this entry, and you'll get a confirmation box again. Do it. The new host name will update shortly.

You can use the same procedure to add a favorite host. For example, I have friendly names for each of my network hosts, earthy names like Mac and Linux, each of which has a real IP address such as, of course. Use the copy trick, and edit in the host name and its actual IP address in place of the loopback or null address. Done!

Example of NetInfo Favorite Host


Congratulations if you persisted this far. Believe me, once you get this working, you'll be stunned at how much browsing noise you must have tolerated until now. I've indicated one solution. There are others. I can tell you that researching and testing for this article took longer than expected. Believe it or not, actually doing this procedure doesn't take very long. It was the testing and noting of each step in the beginning that took the time. Using hosts as a filter doesn't remove 100% of ads, because there are other ways of spawning ads on your screen. But it does greatly reduce them. The most important step in this procedure is the first one, which sets the order in which host name lookups are done. Without that, you can hosts until you're blue in the face, and it just won't work.

I thank those who did the work of compiling the database files and utilities and those who wrote up various how-to and how-it-works articles for hosts files on unix that all contributed to my understanding. My role here is merely to bring it all together. It worked for me, and I'm confident it will work for you too. Enjoy the peace. Ciao.


Appendix 1: Undo

Don't go in until you can see the way out, I always say. But before you undo, take stock and be sure of why you want out. If you are having a problem with something, the cause may be elsewhere, as it often is. Check the troubleshooting section before doing something rash.

To completely undo this procedure, you merely need to do two things, which we will step through in a moment:

· Delete (rename is better) the folder /etc/lookupd if it never pre-existed (most likely), or restore its original contents if it did (not likely); and

· Delete the /machines NetInfo directory and restore your original one.

Rather than rushing for the door, though, why not try a few deliberate steps first, such as these...

If something glitched with the host name lookup order, then rename the lookup order flat file like so:

sudo mv /etc/lookupd/hosts /etc/lookupd/hosts.broken

Now reboot and test your system once again, and try to reproduce the observed glitch. If you're back on the air, then consider that the original installation could have contained a typo. Why not try this step one more time? If after rebooting you're still dead in the water, then the problem is elsewhere, like maybe with your network cable, ISP, etc.

If something glitched with the hosts stuff and you have to restore your original collection, use the niload command like so:

sudo niload -r /machines / < machines.original
(Enter administrator password)

In either case, you can take stock, re-evaluate, and reinstall the appropriate step when you feel comfortable. (7)

If it's really hopeless, then here is the way out.

To delete the host lookup flat file and folder, just rename the folder like so:

sudo mv /etc/lookupd /etc/lookupd.broken

Upon reboot, OS X will ignore this folder. When you're happy after a month that everything is back to original, then delete the thing altogether like so:

sudo rm -R /etc/lookupd

To undo the hosts entries that you imported into NetInfo, open NetInfo Manager and unlock it as above. Select the machines directory. Rename it to machines-old or machines-broken or something. You could delete it, but you might be sorry. Restore your original one from your machines.original file like so: (7)

sudo niload -r /machines / < machines.original

or, if you saved an expanded collection of favorite hosts,

sudo niload -r /machines / < machines.modified

Once again, after you are happy for a month or so, you can go back into NetInfo Manager and delete the renamed directory altogether.


Appendix 2: Troubleshooting

If things seem to work but performance goes down the tubes, then odds are you are suffering the "waiting web page" syndrome. Either use a null address version of the Big ad server database file, or install the eDexter virtual web server. Amazingly, eDexter adds no discernible overhead to your Mac's CPU load. (5)

If you get "permission denied" errors with any of the steps, you probably aren't an administrator. If this isn't your Mac, then you are probably out of luck for doing any of this. In an early version of this article I showed how to create the file /etc/lookupd/global, which also inadvertently caused this problem. If it exists, try renaming that file with the command sudo mv /etc/lookupd/global /etc/lookupd/global.dud, followed by a reboot.

However, if you are indeed an administrator, then try this. Though all of the above commands use sudo instead of the more assertive su wherever admin privileges are required, some users have indicated that enabling the root account, which is disabled by default, gets them a lot of mileage here. To do this, open NetInfo Manager, and pull down Security, Enable Root User from the program menu. If it makes no difference to you, turn it off again as soon as possible.

By the way, booting my OS X installation CD (hold down "C" as it boots) and running the Reset Password utility from the pull-down menu has saved the day for me a couple of times.

If you are uncertain that things are working, try to ping localhost first, to make sure the system works. Press Ctrl-C to stop it. You are pinging yourself, so it should respond instantly with timing results. Now try the same thing on a known ad server host. If ping doesn't return a address for it, then check for obvious typos in the NetInfo directories, e.g. machinez instead of machines. If that structure looks okay at first glance, then check OS X's current host lookup order with the following command in a Terminal window:

lookupd -configuration

A page of information should be returned that looks something like this:

[Mac:~] damien % lookupd -configuration

ConfigSource: file://etc/lookupd
LookupOrder: Cache NI DS
MaxIdleServers: 4
MaxIdleThreads: 2
MaxThreads: 64
TimeToLive: 43200
Timeout: 30
ValidateCache: YES
ValidationLatency: 15
_config_name: Global Configuration

LookupOrder: Cache NI FF DNS DS
_config_name: Host Configuration

LookupOrder: Cache FF NI DS
_config_name: Service Configuration

LookupOrder: Cache FF NI DS
_config_name: Protocol Configuration

LookupOrder: Cache FF NI DS
_config_name: Rpc Configuration

TimeToLive: 60
ValidateCache: NO
_config_name: Group Configuration

TimeToLive: 300
ValidateCache: NO
_config_name: Initgroup Configuration

LookupOrder: Cache FF DNS NI DS
_config_name: Network Configuration

[Mac:~] damien %

The Host Configuration section's lookup order should correspond to your settings in Part 1. If the DNS agent shows up ahead of the flat file and NetInfo agents, then Part 1 didn't take. Try a reboot before anything else. If that does not get you the correct search order, then you'll have to redo that part. The cause is likely a typo somewhere. Also, doing this step requires you to be an administrator. The sudo password is the same as the one you entered when you first installed OS X; and the first installed OS X user - you - is always an administrator.

If ping does return instant timing results for the loopback address when you test but not when you test an ad server, then check the NetInfo machines directory for lots of entries. If just the first one in the hosts file got entered, then save your hosts file again using another text editor that can save in plain text format. Your problem in this case is how end-of-line codes are done. Nothing's ever simple, is it? (If you use the huge hosts file from the link above and just run dos2unix on it with no further edits, you should not encounter any of these troubles.) Now repeat the niload process in Part 2. Just up-arrow in your Terminal window to recall previous commands.

If there are indeed lots of host entries, then pick one and click its host name. Right-arrow to the end. Does it stop? Or does it wrap? If it wraps, then each name has a carriage-return appended to it because you forgot to run dos2unix on the file. Sorry, but you'll have to delete the machines directory, restore the machines.original or machines.modified file, and repeat the above process. You see, the unix and DOS versions of the file have one invisible difference: how they end a line. That's where dos2unix comes in.

If, instead of host entries, you see a lookup order, then you somehow managed to mix up the two hosts files from Part 1 and Part 2 respectively. They're easily confused. Look, I didn't invent this stuff. A quick way to tell the difference between them? The one in Part 1 hat determines lookup order is a mere one-liner. The one in Part 2 that contains a database of known ad servers has nearly 20,000 host entries. You do the math. You will have to undo your work and start again. Use the steps indicated in Appendix 1: Undo, above.

Where are the graphics on the Apple web site? The Apple site uses graphics served by Akamai servers, several of which are black-listed. You'll know them by the missing graphics on the site. Maybe you'll want to throw these servers back into circulation. They are a lot easier to edit out from the downloaded hosts file before you load the thing into NetInfo. You may find it easier to delete the machines directory altogether and start again with an edited hosts file. Remember to load your own collection of hosts first, using this command:

sudo niload -r /machines / < machines.original

To remove any individual server from the list of redirected hosts, open NetInfo Manager once again, unlock it with your admin password, and select /machines. Depending on your Mac's horsepower, this could trundle for a minute or two. Now merely slide down the list, select a server you want restored (they're in alphabetical order), and press the Delete toolbar icon. You could also rename it by appending, say, an "!" to the host name, in case you change your mind later. Click away to some other host and confirm to save your work. You may or may not have to close and reopen your browser afterwards.

If you try installing this hosts file into Mac OS, it won't work. Mac OS requires a different format. There are OS 9 versions of ad-oriented hosts files available. Slight text editing of line breaks and CNAME text may be required. Thanks to a tip, I found that the above hosts file requires every instance of CNAME to be replaced with the letter A. An alias, however, may be configured with CNAME. Whatever. Try the file as-is before editing. Remember to save the edited file as plain text. When ready to install it, open the Tcp/ip control panel to select and pop it in. Bingo. You're done. This Mac OS version of hosts is not well-supported, though. If you have a canned script for converting a standard unix hosts file into Mac OS format, please contact me. I would fully expect eDexter to work with Java in Mac OS, as well as the trick. Also, a product called Hostal might be the animal for you if you spend a lot of time in native Mac OS. It also works in OS X.

If you want to install this hosts file into a Windows machine, then download, unpack, rename, and edit the file in Wordpad as above (to remove Akamai entries, say), and save as standard text. Then drag the file into C:\Windows, or C:\Winnt for NT/2000 machines. Nothing needs to be done on line endings, in case you were wondering. A free utility called HostsToggle could turn out to be quite useful also.

Proxy servers may give you some trouble with this business. I have received information how certain proxy setups can cause host lookups to go directly to the proxy server, bypassing all local settings. That's a problem. Although I cannot guarantee it will work for you, I might suggest that you try placing your proxy server settings in the Network system preference instead of in your browser preferences. You may not have a choice; but if you do, then this might work for you. I suspect, though, that the final solution would involve filtering the ad servers on the proxy host itself. However, if you're a Squid or other proxy expert with a solution to this dilemma, please drop me a line. A couple of people have, and consensus has it that you need to run squid locally, or at least have the ad server database installed on the squid machine. Not pretty if you aren't the sysadmin.


Appendix 3: Notes

1. Here is one area where things have changed slightly with Jaguar. The format is a little different (abbreviated) and now includes the flat file parameter, previously missing. It still goes out to a remote DNS before looking up a host in OS X's own NetInfo database, though. This is a bug. You have to fix this.

I anticipate that someone might take issue with me on this, so here is the evidence. I just happened to have the opportunity recently to do a wipe 'n' load install of OS X on one of our iMacs. For the record, I deliberately left all settings default. The machine first saw OS X 10.1, followed by Jaguar, and again followed by the latest Apple software updates at the time. Here are the results from a lookupd -configuration query for each case:

LookupOrder: CacheAgent DNSAgent NIAgent DSAgent
_config_name: Host Configuration
- 10.1
LookupOrder: Cache FF DNS NI DS
_config_name: Host Configuration
- 10.2
LookupOrder: Cache FF DNS NI DS
_config_name: Host Configuration
- 10.2.3

Note that in all cases a DNS lookup comes before any local NetInfo lookup, and in the first case flat file lookup isn't in the chain at all. Seeing is believing.

2. If you'd prefer not to install dos2unix, then run this alternate but equivalent series of commands (with credit and thanks to SE), which I will just quote:

"I found the following sed script to work... NOTE: It didn't work in the default Mac OS X shell, tcsh, so I changed to the Bourne shell first. Also, the ^M is a single character, generated by typing Ctrl-V Ctrl-M."

sh$ sed s/^M//g hosts > foo
sh$ mv foo hosts
sh$ exit

3. If you inadvertently load more servers into NetInfo than you intended, you can either dump the whole load or you can delete individual servers. There is no nice way to delete a small batch of them. Either way, open NetInfo Manager and unlock it. Select the /machines directory. This will take a minute or two to load. To dump it completely, rename it to, say, machines!, using the dialog box in the lower half of the window. To delete one server at a time, locate and select it in the next column, then press the Delete button. In both cases, when you click away NetInfo Manager will ask you twice to confirm each change. Do so.

4. NetInfo is the Apple preferred method of doing things. But you may prefer the traditional unix "flat file" method. I have it on reliable authority that flat file host name lookups take far longer than NetInfo lookups. So, if you still want to do it this way - and ONLY if you do - then copy the HOSTS file into /etc using the following commands:

sudo mv /etc/hosts /etc/
cp /etc/
cat HOSTS > hosts.merged
sudo cp hosts.merged /etc/hosts

To undo this step, delete the file as follows:

sudo rm /etc/hosts
sudo mv /etc/ /etc/hosts

To tweak your hosts file later, edit it in TextEdit, using the following syntax:

sudo /Applications/ /etc/hosts

The format is fairly clear. Blank lines are ignored, as are lines beginning with the "#" symbol. Close this copy of TextEdit when you're done with a Cmd-Q.

Remember, to cause OS X to read this file before accessing the NetInfo database, place the FF value ahead of the NI value in Part 1, above.

It may indeed be worthwhile to test out a flat file hosts database, if only to experience the efficiency of NetInfo. You can install the same hosts file both into NetInfo and as a flat file simultaneously. Which one gets referenced first depends on the lookup order. Keep in mind that a normal host lookup will take substantially longer, having first to fish through both before going out to a DNS on the network.

5. Some web pages will wait until an ad server has responded before they continue loading. If you opt to use the loopback version of the Big HOSTS database file, then take a look at eDexter, a java program that responds to web requests to the loopback address, and pretends to be those ad servers as far as your browser is concerned. Drag the eDexter folder into Applications. Now, using TextEdit, write a one-line script file for it called eDexter.command with the following contents:

sudo java -jar /Applications/"eDexterJavaDog Folder"/eDexterJavaDog.jar

Save it in your eDexter folder, give it execute privileges with the command chmod 755 eDexter.command (with thanks to JB for that), and add it to your Login Items system preferences. You will have to supply an admin password for it at login time in its Terminal window, which you can then minimize. Alternately, you might be able to install the same code minus sudo as a system startup script.

An alternative to eDexter is using a database of addresses instead of the standard loopback address. As noted above, you can download a version of the Big HOSTS file. Or you can open the loopback version in TextEdit and replace every instance of with yourself. Regardless of which you choose, doing this causes web references to drop to the floor immediately. The risk is that is an illegal IP address, and may cause problems on some web pages. However, I and several others have done this with perfect results to date. So if you feel comfortable enough with editing the hosts file before installing it, then go ahead. You can always download a fresh copy of the loopback version and install that afterwards if gives you any trouble. Of course, you'll still need to run dos2unix on any hosts file before installing it.

6. If you play with the lookup daemon search order in Part 1 and don't want to reboot each time you make a change, try this tip, with thanks and credit to RW:

I would like to point out that rather than restarting the computer after updating the NetInfo location/lookup order, one could simply restart the lookupd daemon:

First, launch Process Viewer (Applications/Utilities) and select the item named 'lookupd'. In the lower portion of the window is the Process ID.

Next, launch Terminal and issue the following command (replace the {Process ID} with the above number):

sudo kill -SIGUSR1 {Process ID}
(Enter admin password)

After a few moments, the lookupd daemon will be restarted automatically.

Here's another one, all in one line, with thanks to MB:

sudo killall -HUP lookupd
(Enter admin password)

As before, wait a minute, and lookupd will have restarted automatically.

7. If you have lost your machines.original backup file, you can download mine, which will be close enough. It should unpack onto your desktop automatically, or you can do it manually with StuffIt Expander. Drag the unpacked file into your Home folder and go from there.

8. Strictly speaking, this isn't what you want to do. But in our case it makes no difference because there is no flat hosts file, and the FF search will be done in a microsecond. One alternative use for this trick is to still keep the nefarious hosts lined up in NetInfo, but use a flat hosts file for a small handful of personal hosts you regularly use or just for testing. The flat hosts file will get consulted first, and a successful search will stop there.

0. Please note that in the final analysis you are responsible for any consequences. I am happy to help as far as possible, but there is a limit. So experiment on your home machine first. If you do this on your office server and bring down your billion-dollar enterprise, you can bet there will be consequences. If you do have problems with this stuff, feel free to post to the forums, as well as to contact me directly. For some nice legal, see below on this site.