Review: Issaquah Brew House

After a long day of Eileen and Jeanie studying constitutional law and me painting an interior wall, Tom stopped by and we decided to head out to the Issaquah Brew House for dinner. We were met with what I can only describe as the most untimely service I've ever received at a restaurant.

It made a good excuse to give the "Submit a review" feature of Google Maps a whirl. The review is online.

The experiences have led me to wonder what the optimum server to table ratio is. I know there's a lot of clamor on the internet that claims that the gruff service in Europe is because servers handle more tables and (as a result) have to be somewhat more efficient, and have less time to be personable. Presumably someone with experience in restaurant management would have a good idea, but 6 tables seems like a reasonable maximum from what I'm reading online.

How Long Do You Wait For Responsible Disclosure?

A vocal minority of people were critical of the timeline last time I found a security flaw so let's try this: (names changed to protect the innocent and the guilty)

• 2007-Jan-16 - Reported local privilege escalation issue to Vendor D
• 2007-Jan-17 - Vendor D will "review as soon as possible"
• 2007-Jan-31 - Vendor D "working on planning a fix", will coordinate release when product update has ETA
• 2007-Apr-20 - Vendor D thinks it would be better if Vendor J made changes to fix the problem in Vendor D's software
• 2007-Jun-21 - Contacted Vendor J for status
• 2007-Jun-22 - Vendor J says precisely which changes they're going to make for their next release (slated for Q4). These changes are not enough to protect Vendor D's software.
• 2007-Aug-29 - Vendor D says they've made suggestions to Vendor J, but otherwise aren't going to do anything to fix this issue
• 2007-Oct-01 - It turns out that Vendor J's recent builds indeed don't do enough to cover up the vulnerability in Vendor D's software

Beyond that, people running current versions of vendor J's software will be vulnerable forever because vendor D says they aren't going to do anything about it: (from Vendor D's August 29th email)

[Vendor D] does not currently plan to make changes to our existing products
to directly address the problem you reported. The changes would require
considerable architectural modifications for those products, and the changes
could cause other problems for those products if [Vendor J] subsequently
release[sic] an ... update to address the underlying problem.

My immediate thoughts are that a disclosure deadline late this month would be appropriate at this point. That'll give me time to prepare a third-party patch to make the fix that Vendor D should've made ages ago, and give the parties some additional PR prep time (beyond the 9 months they've already received). I have to say that Vendor J really isn't at fault here, Vendor D made a stupid mistake and now doesn't want to take the time to fix it.

But this is blog land, so maybe people have thoughts.

Update: I've told the vendors November 1 (or earlier at their discretion).

...but how many Big Macs will it buy?

There was a conversation about investment at work that mentioned stocks, gold and the "Big Mac Index" so I decided to do a quick analysis.

Year	Big Mac	DJIA	Big Macs per DJIA	$/oz Gold	Big Macs per oz Gold
2001	$2.54	10790	4248	271	106
2002	$2.49	10259	4120	278	111
2003	$2.65	8601	3245	343	129
2004	$2.90	10409	3589	417	143
2005	$3.15	10827	3437	428	135
2006	$3.15	10883	3454	530	168
2007	$3.22	12474	3873	640	198

It didn't quite work out the way I had expected it to. Plotting the CPI (or the Euro) against these numbers might also be interesting.

Data Validation Rant

I just signed up to renew my ACM membership for the first time since I was a student back at WWU. I have to admit to feeling kind of bad about having finally caved in to the direct mail they've been bombarding me with, but it did offer a reasonable discount. So I'm busy filling out their online form that asks for all sorts of information they can use to direct additional marketing at me and I click the "continue" button, but alas I cannot continue.

So why can I not continue? Everything I entered is correct, I double-checked. It turns out I put a dash in my zip+4 code, and for them that's an error. The US Postal Service disagrees, and in fact insists that xxxxx-xxxx is the "standard format" for a zip code. One would hope that the ACM of all organizations could figure out how to validate data without looking stupid, but apparently that's too much.

This is a real frustration in lots of other online settings as well. There are quite a few online merchants that refuse to process your payment unless you leave the spaces out of your credit card number. They display stern warnings like "Important: Please do not put spaces or dashes between credit card numbers." If they can't even figure out how to remove extraneous spaces or dashes from the information I give them, should I be trusting them to get the rest of my order correct and not have my personal information stolen? Dealing with that input is maybe 4 lines of code if you're trying to make it hard. It's usually not the merchant's fault, they're just buying some third party service. Any service that merchants are having to pay for that can't manage to get this right should be publicly shamed for their lack of competence.

Email addresses are also apparently a tricky beast for people who are building online tools. There are a lot of characters that are valid in an email address that various online services tend to choke on. There are numerous examples online disguised as "how-tos" that are actually "how-not-to-dos". The example I'm picking on in this case doesn't accept addresses with a + in them. Addresses like learn+to+read@rfc2822.int are in fact perfectly legitimate email addresses, as are addresses with hyphens, underscores, carets, tildes, equals and a lot of other somewhat obscure characters. Mail servers seem to deal successfully with these things, one would hope most
web application writers could cope with it too.

Come on all you folks that are building tools for the web, it's not hard to get these things right by just being little bit more pragmatic about it.