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).