UrlBlogGrey

Natalie and I will be leaving for the Hawaiian island of Kauai on Tuesday for our wedding on Friday, June 30th! Time feels like it has been moving several times (?) faster than usual. It has a weird resemblance to the last week of high school, when something that seemed like it was going to take forever to complete came to an abrupt end. Of course, I've had a lot of great experiences since high school and expect the same to be true after getting married!

Natalie is agonizing over which shoes to wear during the ceremony, and I have some clothing vagaries to be resolved. But we're mostly ready to doo-dis :)

We'll be staying in Princeville, Kauai, from Tuesday through Monday. Kauai is notorious for unpredictable weather conditions, so we're keeping our fingers crossed that everything turns out well! On Monday, we will fly from Kauai to Maui where we'll be staying at the Ritz-Carlton, Kapalua. Our stay in Maui will last until Saturday, and ought to be filled with fun, sun, and other Hawaiian cliches! We're tot-excited, though it would nice if we both had more vacation time available. We'll be gone for nearly two weeks, which is the most that we can afford since neither of us has much vacation-time accrued at our new jobs. I need to make vacation-time a point for negotiation in the future.

Oh, and my Dad and I will probably get some golf in while on Kauai. We played last weekend in Santa Cruz, and neither of us managed to get sun-burned!

Posted by Scott at 9:09 AM | Permalink

I was looking at my credit card statement on-line and saw this image on the entry-page advertising how I can add another user to my credit card. What makes me laugh/vomit is the teenage daughter demanding a credit card from her father who reluctantly hands it over. As if she's saying "Daaahd, comeonand givemeacredit caard." And then the Dad says, "Ok, Breanna, just try to keep your spending under $2000 per month." Then Breanna says "Whatever."

Posted by Scott at 3:13 PM | Permalink

I came across an article that I deeply resonated with while looking at the RSS feed for Merlin Mann's 43 Folders site. Some of Merlin's best points included the brilliance of the Gillette Mach 3 razor, the importance of using a shaving brush, and the love-hate relationship a man has with shaving.

I've been using the Mach 3 razor since switching from an electric razor. My experience with electronic razors (what I used until age 24) has been very poor: they've given me a crappy, uneven shave, and probably contributed to my acne as a teenager. However, changing to a safety razor wasn't easy. I had to learn to shave with the grain (in my case, from top to bottom), use lots of water, and not be fanatical about getting every bit of facial hair gone (over-doing it can lead to cuts and irritation).

At present I have my shaving routine down to a science. And the Mach 3 does an excellent job, though the $9/month spent on replacement blades seems excessive considering the simplicity of their construction. But that explains why Warren Buffett has long been an investor in Gillette - so long as they don't do anything stupid, Gillette will continue to make money hand-over-fist from men and women who continue to replace their razor blades and supplies.

But I do loathe shaving. It's the part of my morning routine that I hate the most. It's time-consuming, requires close attention at a time when I'm just waking up, and is extremely repetitive. Maybe I should grow a beard. Hmmm...

Posted by Scott at 2:20 PM | Permalink

I installed an Open Source firmware called OpenWRT on our Linksys WRT54GS wireless access point about 2 months ago. My main reason for doing so was that it allows me to perform port mapping rather than just port forwarding. This allows me to map WAN service ports to different LAN service ports. This a neat trick to reduce the likelihood of a network attack since services are exposed on the WAN/Internet adapter on non-standard ports.

OpenWRT has demonstrated itself to be highly configurable and reliable. I also like the ability to run a caching DNS service. And, I can assign static IP addresses to my LAN computers and publish their computer names through the DNS service. It's much easier to remember the host-name 'tivo' than '192.168.1.2'.

OpenWRT also provides the ability to install numerous modules on the system, and is limited only by the access points small amount of physical memory. I have version 1.0 of the WRT54GS, which yields 32 MB of RAM - plenty for what I require of the system. I highly recommend using the OpenWRT firmware if you've got a Linksys WRT54GS or other supported device. My access point was purchased in Spring 2004, and I'm amazed that I can still rely on it to provide me fast, secure access without an upgrade in over 2 years. Perhaps I should expect more of my other electronic devices!

Here's a screenshot of what the web-based administration tool looks like:

Posted by Scott at 9:58 PM | Permalink

A security vulnerability was discovered in the RealVNC software in mid-May 2006 that exposed a means of bypassing the authentication step while connecting to a RealVNC server. VNC is a network protocol that allows multiple clients on a network to remotely interact with a computer running a VNC server program, such as the RealVNC software affected by the vulnerability. Being able to avoid authentication means that anyone might be able to connect to a computer running a RealVNC server, regardless of whether they have the authority to do so.

There are a lot of programs that handle authentication in an insecure way; however, most of these programs rely on secure transport protocols (i.e. SSL) to keep the authentication credentials safe while in transit. However, this vulnerability means that even if you tunnel the unencrypted VNC traffic through a secure channel (i.e. an authenticated SSH session), the VNC server is vulnerable if the port it's listening on is open to the public. This vulnerability can be patched by operating a firewall on the machine and exposing only the SSH port to the public. Once authenticated using SSH, a client can tunnel their VNC traffic to the VNC server port on the same machine from behind the firewall (over the loop-back device).

This vulnerability is pretty serious, but I think that it provides a good incentive for people to follow better security practices when using VNC servers. The value of firewalls and SSH cannot be emphasized enough.

Posted by Scott at 8:43 AM | Permalink

I posted an entry in my blog about a week ago regarding the inclusion of a Google Suggest search plug-in with the alpha release of Firefox 2.0. Natalie wrote to me to let me know that she had seen such a search plug-in available for the 1.x releases of Firefox. I decided to locate such a plug-in but was unsuccessful. The reason: Google pulled it. Their motivation: it was a compelling feature, and its absence might pressure more people to download and install the Google Toolbar (I have nothing against toolbars in a technical sense, but I think that they can be invasive and unnecessary).

I think this reflects poorly on Google since the availability of a Google Suggest search plug-in doesn't significantly compete with Google's business-model. It does, however, reduce the amount of user machine's that are 0wn3d by the Google Toolbar and reporting browser activity back to the mother-ship.

Posted by Scott at 1:54 PM | Permalink

Recently, I've been working on a problem similar to the following: a client accepts a digital certificate associated with a piece of remote code (ActiveX, Java Applet, etc.) The code signed using the certificate might be designed to do something benign like download weather information to the client's web browser. Sounds harmless. But what if a malicious party takes the remote code, leaves it intact, serves it to a client who has accepted the certificate, and then tricks the remote code to download to the client's system something other than weather information - say, spambot software? This produces an outcome far different from what the user had in mind when they accepted the digital certificate to view their local weather.

The problem here is that digital certificates are rarely restricted to a specific operation. The client can't say "Yes, I trust company XYZ, but only to download weather info." Rather, they can only say "I trust company XYZ." In this sense, the trust relationship is very ambiguous. As an analogy, I trust my auto mechanic to work on my car, but I don't trust him to prepare my taxes.

Computing applications, particularly those that are networked, need a more precise method of defining and restricting trust. The consequences of not doing so can lead to horrible surprises for software vendors and customers as they begin to see their trust relationships exploited by people with malicious intentions.

Posted by Scott at 1:52 PM | Permalink