Yup. It's sure the first result on Yahoo. Of course, the last update prior to yesterday that I can find has approximately nothing to do with this "Android Data" thing.

A bit more research, and you'll find: The site was last updated yesterday. The content that was there at it's last indexing on Google and MSN is the same as what is currently up at www.pushpuppets.net. As well, android-data.com (the actual domain for the "product") was registered on 2009/04/20; it's been around for a grand total of 12 days. The site that was there before, according to archive.org: it's a parking page for someone else operating a business by the name of "Android Data Services", though checking androiddata.com on archive.org gets you the same site: defunct since 2006, with it's last update being 2003/01/23. Searching for android-data.com gets you no site whatsoever, on Google, Yahoo, or MSN.

This reads to me as though truth is more idiotic than fiction. Nefarious is more likely the case: everything I've been able to tell suggests that the name and product have been dead for at least 3 years, if not more likely 6 years. Looks more like a case of "I might be able to sue Google for lots of money" than anything. The likelihood of actually winning any lawsuit there, suing over a product that nobody has ever heard of, on a trademark that nobody has ever heard of (until today)... um, right. Maybe if he were actually developing & promoting that product, then he'd have something to say.

Hm. Well, methane will generate CO2 as it's end result, whether it's used for power or not - it undergoes an oxidation reaction over time: CH4 + 2O2 -> CO2 + 2H2O. It's also 75 times more potent than CO2 as a greenhouse gas, and as it decomposes to CO2 anyway, net output of CO2 from burning methane from such sources as cow dung is nil.

Wind, solar, and hydrogen all have their issues: wind and solar are unreliable over time, because they both ultimately depend on the weather conditions, and hydrogen isn't an energy source. Free H2 uses a lot of energy to obtain, unless it's obtained from fossil fuels, which, while potentially better for the environment, still leaves us with a non-renewable resource.

Hm. I've got Clear in Portland; I'm in 97239, for what it's worth. They might not advertise it as being available - the primary reason that I've been able to tell is because the signal strength / quality isn't anything great. It's certainly enough to get the job done - once the equipment is placed in a good spot, I still get 5.5Mbit, but in a bad spot (which can be as little as a few inches from the good spot: at least I have ziploc bags and tape, since it's taped to the end of my balcony right now) I'll be lucky to get dialup speeds.

The realm is only half of the identifying element - the URL requesting authentication is the other half. For basic authentication (RFC 2617, section 2), the realm value is only for the server sending it; if another server (identified typically by [ http/https, hostname, port ]) sends me a WWW-Authenticate header with the same realm name specified, for the purposes of authentication it is a different realm. In digest authentication (section 3), it is possible to have credentials go across multiple servers, but such servers have to be specified in the initial WWW-Authenticate header in a "domain" parameter; otherwise, the authentication is again only available to the server sending the WWW-Authenticate header in the first place.

Ultimately, unless your system, DNS server, proxy server (if you're using one), gateway, or the target server, have been broken into, obtaining the credentials for any given realm is going to be difficult; if your system has been broken into, this is pointless because they could just as easily install a keylogger to capture the authentication information as it's being entered; if your gateway has been broken into, then unless you're performing all authenticated transactions over HTTPS and/or not using HTTP Basic authentication, the information is going across there in cleartext anyway, and tcpdump is all that's needed to extract it. Since the proxy server tends to exist at the gateway level anyway, the same issues apply there. As far as the target server goes - you can either capture the authentication info there, or, since you've got permissions to do anything the webserver is capable of, including generally accessing the authentication DB, just grab the authentication information and be done with it.

So... good luck at attempting to reuse the exact realm of another server - since, for the purposes of comparing authentication realms, the realm name is little more than a token which identifies a given protection space on a single server (or multiple explicitly specified servers in HTTP Digest, but that's still explicit).