I use a browser extension called Secret Agent from https://www.dephormation.org.u.... This works with Gecko-based browsers (e.g., Firefox, SeaMonkey) on Windows, Mac, and Linux systems. It sends fake HTTP headers to confuse Web servers that are trying to track my browsing activities. This causes many geolocation routines to give wrong results. I have Secret Agent set to change its faked headers on every HTTP request sent from my browser.

While composing this comment, I tested a few sites. One had me on the coast of Argentina and then (same Web site) in eastern Michigan. GeoIP thinks I am in Indonesia. Although I am indeed in southern California, JustMyIP thinks I am two counties further south. Appspot thinks I am in Palo Alto, about 350 miles north of my home. IP Address Geolocation was the closest, thinking I am in Los Angeles. I am about a five-minute walk from the Los Angeles County line but about 8 miles from the Los Angeles City limits.

Between Secret Agent and setting my cookies file to "read only", I have some limited protection from tracking.

Franchised car dealers already violate this promise; and many (most?, all?) independent service garages and body shops do, too. If you take your car to a dealer for servicing, your mileage is reported to CarFax, which then reports your mileage to your car insurance. If you have an accident and do not report it to your insurance, the accident is reported by the body shop that does the repairs. CarFax pays the dealers, garages, and shops for these data; and insurance companies pay CarFax.

What is worse is that erroneous data are difficult to correct. In advance of an insurance policy renewal, I received an E-mail message asking me to use the insurance company's Web site to report my mileage. When I reported 25,065 miles, the entry was rejected with a message indicating I could not report an odometer reading less than the prior reading. On the Web site, there was a link to view the mileage history for my car. The immediately prior entry was for 241,080 miles, reported by CarFax on the date of the last routine servicing of my car. I checked the invoice for that servicing; it indicated 24,108 miles. A zero had been added to the end of the mileage, either by the dealer's service department or by CarFax! Working with both the service manager at the dealer and the local agent for the automobile insurance company, it took several phone calls over a month to obtain a correction.

  See http://www.carfax.com/, which will charge you for a report on a specific car. See also http://www.mycarfax.com/, from which you can get a free report.

The scorecard gives negative marks for both PGP for Mac and PGP for Windows, for both "Are past comms secure if your keys are stolen?" and "Has the code been audited?" Both negative marks are quite wrong!!

Using the OpenPGP definition, decryption requires both a private key and a passphrase. If the private key is compromised but the passphrase remains safe, a file or message encrypted via OpenPGP cannot be decrypted. This depends, of course, on a lengthy passphrase that exists only in the user's head. My passphrase is over 20 characters long and contains upper-case and lower-case letters, spaces, and punctuation.

Older versions of PGP (a commercial implementation of OpenPGP) have indeed been audited. The source codes were made public. They were thoroughly examined by outsiders. And they were compiled and compared with the distributed binary code. I do not know if this is true of the latest versions, but the older versions contained no security vulnerabilities and still work quite well.

Everybody is NOT carrying around a smart phone. My wife has a dumb phone that satisfies her needs. I do not even have a dumb phone because I enjoy getting away from the phone.

GMT was rendered obsolete in 1972. The current international standard is UTC (Universal Time Coordinated).

What "twice a year"? When SoCalEd fails -- several times a year unrelated to weather -- I have to reset 7 clocks and check 3 more to make sure their battery backups kept them current.

Where I live, sunset today (after resetting 18 timing devices in my home) will be at 6:01pm.

How then do you deal with the occasional leap-second, in which the last minute of a calendar quarter has 61 seconds?

Counting not only obvious clocks but also the timers on our thermostat, garden irrigation system, blood glucose meter (I have type 2 diabetes), TV and DVD/VCR (which have separate "clocks"), the gas and microwave ovens, and controller for lights on front walkway, I had to reset 18 timing devices this morning.

But this is not merely a twice-a-year effort. Failing to do proper preventative maintenance on its system, Southern California Edison can have an electrical outage at any time of the year; weather is rarely a factor. Every time there is an outage, I have to reset 7 devices and check three more to make sure their internal battery backups did not fail. Then there is the tall-case clock (also known as a grandfather's clock); if I forget to wind it before it runs down, I must then reset it. And there are two battery-driven clocks that occasionally need new batteries.

Most speed-test Web sites fail to tell the user where the the server at the other end is located or who owns it. For that reason, I generally use Speedtest.net or DSLReports, both of which allow me to select a distant server. Speedtest.net has a really large set of responding servers all over the world. DSLReports has a very limited set of servers for its Flash-based test but seems to match Speedtest.net for its Java-based test.

I have a browser extension that obfuscates my browser's outgoing HTTP headers and thus confounds many geolocation algorithms. Both Speedtest.net and DSLReports generally think I am someplace other than where I really am, in some cases on a different continent. I am not sure what is being tested in this situation, so I generally disable the extension.

I went to work for System Development Corporation (SDC) in 1969. SDC was actually the company that established computer programming as being distinct from building computers; before then, the only people programming were the engineers who built the computers. SDC was a good company with good pay and good benefits. Then, SDC sold itself to the Burroughs Corporation, which succeeded in a hostile takeover of Sperry Univac and became Unisys.

At Unisys, we found ourselves in an environment that treated highly experienced technicians and professionals as if we were assembly line workers. Unisys even imposed work rules on us salaried employees that are actually legal only for hourly wage-earners. I should have recognized the abuse sooner than I did and "jumped ship". I could have timed a change for when shortage of software experts made job jumping very profitable. Instead I stuck it out until mass layoffs were very near.

When Burroughs and Sperry Univac merged, the resulting Unisys had more than 120,000 employees. Today, Unisys has less than 25,000.

I must disagree with the replies that indicate programming is poorly paid. I earned sufficient pay that I was able to retire very comfortably before I was 62.

I would suggest that programmers learn how to test rigorously the software they create. This requires that they also write software specifications that are testable, after which they should learn to write formal test procedures. They can then advance into becoming requirements analysts and software test engineers (except in states where "engineer" is a career that requires a license). There are too few analysts and testers, who are often paid much more than programmers. Large computer-based projects are failing because of a lack of clear, objective, and testable specifications. Attempts to put those projects into actual use are disastrous because of a lack of testing.

For some details about my career, see http://www.rossde.com/retired.....

Given that snydeq wrote the opposite of what we think he meant, he might not understand your (Anonymous Coward's) correction. After all illiteracy often includes an inability to understand what is written and not merely an inability to express one's self in writing.

snydeq wrote: "I simply loved to code and could have cared less about my 'career' ..." That means snydeq cared more than he could have cared. If he instead wrote: "I simply loved to code and could not have cared less about my 'career' ...", that would mean he did not care at all.

I paid someone to go into my cramped upper attic (during a hot summer day) and run a cable from my wife's PC to our router, which is located in our lower attic on the other side of the wall from my own PC. He then ran a cable from the TV cable to our modem. This latter involved removing several cable splices in favor of just 1 or 2 in order to improve the quality of the signal.

Although I had subscribed to Time Warner Cable for Internet service, the system did not work. TWC had to come to my house and lay a new underground cable from their own junction box at the street to my junction box on my house. The existing TWC cable (more than 35 years old at that time) just did not have the capacity to handle a broadband Internet connection. During that, I noticed that the old cable had merely been laid in a trench in the ground without any conduit; a conduit would have made the task so much more easy. Unfortunately, the new cable was also placed without any conduit. I got credit on my TWC bill for the time between subscribing and getting the new cable.

Although the router has WiFi capability, I disabled that.

Problem #1 is NOT a problem in California. A safe deposit box at a bank is not sealed when one of the owners dies. Those who are on the signature card to open a safe deposit box retain full access after one of them dies.

In my case, the box is part of a bank account that is owned by a living trust that is part of my wife's and my estate plan. For continuity, our trust requires that there always be two trustees; and our heirs are excluded from being trustees to prevent conflict among them. Nevertheless, our son was on the signature card for the safe deposit box; the bank allows existing signers to add anyone to the card. When he died, the bank required a new signature card without his name on it. We then added our daughter to the card. If either my wife or I die, the trustee-in-waiting named in the trust document becomes the second trustee. She will then be added to the signature card. In the meantime, the bank does not block any access to the box by anyone on the current signature card when one of them dies.

For problem #2, I do not disclose at which bank -- let alone at which bank branch -- our safe deposit box is located. I definitely do not disclose the box number. If a court order was issued to access the box, it would have to be served on me for me to locate the box. At that point, I would have the opportunity to go back to court to challenge the order. Anyway, there is nothing on our box that represents criminal activity. A civil lawsuit that would require the other party to access my box might involve an improper "fishing expedition" since the other party would not have any prior knowledge of the box's contents.

I did the same. My Web user IDs and passwords are in an envelope in my bank's safe deposit box as well as in a strongly encrypted file on my PC. The encryption key exists only in my head and in that envelope.

But for some non-Internet files (e.g., complete PC backups, tax returns from prior years), the files are encrypted via PGP. Decrypting them requires a passphrase (longer than a password, with embedded blanks and punctuation); some require my PGP private key. The envelope in the safe deposit box contains the passphrase on paper and the private key on a floppy, on a CD, and on paper. Otherwise, the passphrase exists only in my head. (My PGP public key is indeed public and is found on a number of key servers around the world.)

When my wife's cousin died, his widow could not access anything on his PC. I hope my wife does not have that problem.