This article seems to focus on spreading FUD about HP printers. The truth is that most network-enabled printers have similar web interfaces and system administrators need to be diligent about securing them if they are going to attach them to a network. This is nothing new and it's not specific to HP in any way. Most any printer with a web interface, including many (all?) of the ones showing up in that Google search, offer mechanisms to require a password to access them. They also usually offer SSL to protect the passwords from packet sniffing, but a good systems administrator should not even allow their printers to be visible beyond their firewall. If they merely spent the time to set a password on the web interface, then Google would not index them.

The link to the web listener is merely the documentation on configuring the network settings for an HP JetDirect printer. You'll find something similar for Brother, Canon, Epson, Ricoh, etc. The last link about an unpatched JVM is complete misinformation. The link points to an article about Java's latest vulnerability being patched, but I've searched online and can find no evidence that any HP printers actually run Java. The best I can determine is that they are referring to the HP LaserJet Toolbox which is an embedded Java Applet on some web interfaces for LaserJets. There is no need to update the firmware on your HP printer for this. The security vulnerability there would be in a JVM running on the computer that you are using, not the printer, and that JVM is fully upgrade-able and can even be removed if your concerned about Java.

The only real news here is just how many system administrators have left their printers exposed to the Internet without a firewall, and, on top of that, have not bothered with even basic security on their devices like setting a password on the web interface and mandating HTTPS to secure their printers.

This article seems to focus on spreading FUD about HP printers. The truth is that most network-enabled printers have similar web interfaces and system administrators need to be diligent about securing them if they are going to attach them to a network. This is nothing new and it's not specific to HP in any way. Most any printer with a web interface, including many (all?) of the ones showing up in that Google search, offer mechanisms to require a password to access them. They also usually offer SSL to protect the passwords from packet sniffing, but a good systems administrator should not even allow their printers to be visible beyond their firewall. If they merely spent the time to set a password on the web interface, then Google would not index them. The link to the web listener is merely the documentation on configuring the network settings for an HP JetDirect printer. You'll find something similar for Brother, Canon, Epson, Ricoh, etc. The last link about an unpatched JVM is complete misinformation. The link points to an article about Java's latest vulnerability being patched, but I've searched online and can find no evidence that any HP printers actually run Java. The best I can determine is that they are referring to the HP LaserJet Toolbox which is an embedded Java Applet on some web interfaces for LaserJets. There is no need to update the firmware on your HP printer for this. The security vulnerability there would be in a JVM running on the computer that you are using, not the printer, and that JVM is fully upgrade-able and can even be removed if your concerned about Java. The only real news here is just how many system administrators have left their printers exposed to the Internet without a firewall, and, on top of that, have not bothered with even basic security on their devices like setting a password on the web interface and mandating HTTPS to secure their printers.

Actually, you can't transfer a domain when it's close (~30 days I think) to expiring to avoid it expiring mid-tranfer. You shouldn't not loose any time off of the original registration. It should just extend it so it's probably better to transfer now. Check on the rules for that from both registrars.

GoDaddy has both DNSSEC and AAAA glue for IPv6 for the .ORG domains. pir.org has a list of registrars supporting DNSSEC for .ORG.

It might be nice to know whether the Bank your using is using a signed zone, for example. If they don't, your prone to receiving DNS data that points to a crackers IP address. SSL does not protect against this attack if SSL is not used. Most people don't realize when SSL is in use or not and will gladly log into a site without SSL. SSL can only protect once the end user gets the right IP address of the SSLized Web Server they need to log into for their Bank.

Your Windows computer still relies on an outside computer for doing the DNS lookup. This recursive DNS server can also validate all DNS data and drop data that fails validation protecting your client Windows computers. Comcast is currently in DNSSEC trials, but Comcast end-users can switch their DNS servers to the test servers and get all their DNS data validated automatically. Once this goes live, all Comcast end-users will get benefits of DNSSEC. Also, anyone can run their own recursive validating DNS servers internally and not rely on their ISP's DNS servers.

It is possibly to run a validating resolver on your own laptop which validates DNS data regardless of where you are connected to the Internet. You can be using any free Wi-Fi hotspot of your choosing and still be assured that the secured DNS data is accurate. Granted, this is only for zones to which you have valid trust. An unsigned zone, as most are currently, can still be spoofed.

To help with this situation, there are a number of Trust Anchor Repositories (TAR) that do a certain amount of testing on the trust anchors to verify they are correct. I use ISC's DLV repository on my home servers, but there is also SecSpider that has a large database of keys as well. They run multiple resolvers around the planet that regularly pull for DNS keys and verify that they are consistent across all servers. It's less secure than trust provided by the parent, but still extremely difficult for crackers and in the absence of a signed parent, a decent alternative, IMHO.

Actually, any validating resolver should drop DNS data that failed to validate. Most DNS data is currently unsigned which means that is can't be validated. That does not mean it failed to validate, just that it the data is not secure. A stub resolver can notify it's calling process whether the data is secure or not, but data that should be secure and failed to validate will never be passed to the process.

The DNS extension called EDNS0 allows larger UDP DNS queries so that TCP can be avoided. The size for UDP queries is now at 4096 bytes from the 512 byte limit without EDNS0. A lot of the preparation going into DNSSEC has been testing for resolvers with broken EDNS0 support. I find that the vast majority of my DNS queries with DNSSEC enabled are still successfully sent as UDP with EDNS0 currently.

Actually, they've announced the date to now be July 15, 2010. http://www.root-dnssec.org/

Size does play some part in it. There are a number of smaller two-letter country code TLDs that were signed before .ORG as well as the fact that .GOV also beat .ORG to being signed with .GOV being signed in March of '09 and .ORG being signed since June of '09. I think the big news is that .ORG is now allowing regular domain owners to submit their keys into the .ORG database. VeriSign who runs both .COM and .NET plans to first sign the smaller .NET which is still larger than .ORG. before finally tackling .COM.

OpenBSD has a flag to report DNSSEC status.

Actually, much of the use of Vorbis is hidden in videos. I have a number of hi-def videos that, while use H.264 or similar MPEG 4 codecs, also use Vorbis for the audio track and a Matroska container. It's easier to find this than OGG Vorbis music files, from my experience.

I believe proper quoting will fix that problem. All CSV files I've seen exported from OOo seem to quote automatically, but not sure about Excel. Try:
"Smith","Joe","E","121 Mockingbird Lane","Metropolis","BS","(330)555-1212","0023456789"

Normal numbers naturally don't need quoting. You can even embed quotes in fields by doubling them up:
0123,"5'2""","Height"
Which is the number 123, followed by 5'2" as in 5 feet 2 inches, and Height.

Yes, the quotes are correct.