You are generally correct. E-911 passes two important pieces of information to the Public Safety Answering Point (PSAP). One piece is the phone number of the caller, which is delivered through ANI. The second piece of information is the caller's location, delivered in a separate SS7 element know as ALI--Automatic Location Identifier. On a standard copper POTS line, ALI can be determined just by the physical circuit over which the call is being placed. For VoIP, which does not run over a permanent circuit, ALI information has to be "made up" and inserted in the SS7 routing information by the provider.

This information could theoretically come from the account information, but is not done this way in practice. Many consumers use different billing addresses from the primary location where they use their VoIP. There are now two common methods for populating ALI info.

Over the top VoIP providers, such as Vonage, have a big notice about E-911 issues with their service, and make each customer populate their own ALI information in their online account. This is somewhat risky, since these VoIP service tend to be nomadic-I can use my Vonage ATA to connect to any broadband connection, and if I change my location, it is up to me to update my ALI status. (There are horror stories of people setting up at a hotel, having a heart attack, calling 911, and having the ambulance show up at their house).

Providers of integrated VoIP, such as Comcast, have developed ways to use the IP address associated with the VoIP call to lookup the physical address of the caller. This works because Comcast is also providing the underlying broadband connection, which is tied to a particular physical location.

The FCC discussed these complications in a 2005 Order which required providers like Vonage to take extra steps to notify customers about the 911 risks, and to collect accurate ALI information.

I'm not quite sure why this is modded as funny, since CallerID and ANI ("Automatic Number Identification") are actually two separate elements of a call as noted above. ANI is a built in signaling component of SS7 that generally cannot be modified by the calling party. See definition here.

Still, although ANI may not be "spoofable," it can be manipulated or uninformative. For example, any call placed from any phone in my office carries a general company ANI even though the call could be originated from any of hundreds of phone numbers owned by the firm. We also have off-premise extensions (OPXs) that connect to the office PBX via SIP. Calls placed from those OPXs have the same ANI as calls made from the physical office, which would be deleterious if a call was placed to 911 from one of these phone. (We have implemented a safety workaround for this, but the point still stands.)

I was interested to see that the largest denomination offered by Apple is actually $2,500. From the second link: """Apple Gift Cards can be purchased from the Apple Online Store in any amount between $25-$2500.""" I wonder why the hackers don't go for a denomination greater than $200?

The story of the EV1 is much more complex. There is a great movie about the EV1 called "Who Killed the Electric Car." http://www.imdb.com/title/tt0489037/ It's clearly produced from an anti-GM standpoint, but it raises a lot of questions about GM's practices, motivations, and their current inability to provide a hybrid-electric vehicle that works.

Google is an innovative company, and innovation often includes trial and error as well as improvements to an original idea. No one makes you use their products, and in this case, gmail is only one of many email providers. If you would prefer slightly more reliability from a corporation providing a product guarantee, feel free to look elsewhere. I like the way gmail works much more than any other email app I've tried, and am happy to accept the occasional issue, especially for all of the positive developments that have come from continued work on the project. Remember not so long ago when you couldn't chat in gmail?

will it blend? http://www.willitblend.com/videos.aspx?type=unsafe&video=iphone