An innocent blog post demonstrating that it’s trivial for anyone to see passwords in clear in Chrome is slowly building up into a whole scandal. The Chrome team was quick to respond but unfortunately, that answer simply poured oil on a fire that was already burning quite brightly.

Here are a few predictions:

• As we speak, the Chrome team is having an emergency meeting to discuss the situation.
• Within a few days, they will announce that they are going to fix the problem.
• In a couple of weeks, the next version of Chrome will no longer display passwords in clear without additional action from the user.
• In the months that follow, the other browsers will fall in line and implement a similar fix (Update: Safari already prompts you for your machine password before showing you its passwords, thanks Fabrizio for pointing this out).

I’m guessing Justin Chuh is probably regretting answering so hastily (you know you’re in hot water when Sir Tim Berners Lee calls your answer “disappointing”) and this might be a good illustration of being immersed into a domain for so many years that you start missing out on obvious things. We’ve all been guilty of this at some point, where our own expertise is reinforcing a flawed premise and that very expertise is preventing us from being critical of that very same premise.

The general idea is that once someone has physical access to a resource you are trying to secure, that resource is pretty much gone, so you shouldn’t spend too much time trying to address that scenario.

A common response to this is that once someone gains access to your computer, they can still log into your favorite web sites without knowing your passwords, but this is a straw man: the exposure of your passwords in clear text can be devastating since this knowledge can then be used to many more web sites. If you give me a password cookie, I can only log to so many web sites in a few minutes. If you give me your clear text password, I can spend hours back home trying to log in various web sites without worries.

The danger with the “physical access is not worth addressing” premise is that it’s tempting to do absolutely nothing to address this case (which is what most browsers do, Chrome is not the only culprit here) instead of doing at least a minimum. For example, maybe you have some cash in your home that you save for emergencies and you are wondering where to hide that money. Just because a burglar inside your house can steal whatever they want at that point doesn’t mean you shouldn’t at least make it a bit harder for them. Surely, hiding that cash inside socks in a drawer is a bit more secure than leaving it in plain sight on the kitchen table.

This added bit of security can be crucial for two reasons:

• It raises the technical bar on the thief. With the current situation, someone who sits down in front of your unlocked workstation can know your passwords within ten seconds and just a few clicks. Hash and hide these passwords and suddenly, reading them is no longer accessible to a large part of the population.
• Time is also a factor. When someone gains access to your computer, they might only have a few minutes and anything you can do to delay them (such as installing a hash decrypter) is that much time they don’t have to steal something else.

Whatever happens, I think we will all come out of this situation with more secure browsers.

Email tips which I thought were common knowledge.

Avoiding embarrassing forwards

Problem: You receive an email (say from a customer), you pass it along internally with a few comments and… you accidentally copy the author of the email with details they were not meant to read.

Solution: Instead of “Reply to all”, adding your team in Cc and removing the customer (the part a lot of people forget), forward the whole email and then add your comments. It’s much easier to avoid mistakes when you have to populate an empty To: box than when you have to edit an existing list of To's, Cc's and Bcc's.

Don’t send too soon

Problem: writing an email that’s not ready to be sent yet.

You need to write a detailed email which is not supposed to be sent just yet (for example because you are describing something you’re still working on). How do you make sure that you don’t send the email until the time is right?

Solution: Write it and save it as a draft but don’t enter anything in the To: box. Do this last.

Say no to ugly emails

Problem: You want your emails to look nice.

My emails routinely contain code or shell output, and as much I love Gmail, its abilities to format are pathetic, both from a user interaction standpoint (why do I need three clicks to indent text to the right?) and from a theme standpoint. For example:

In order to get this ugly rendition of code, I had to indent the snippet manually and then change its font. And it still looks terrible.

Solution: Use Markdown Here, a Chrome extension which not only allows you to format your code in Markdown but also uses some pretty nice CSS.

You only need a few backticks and, optionally, specify the language:

```java
public class SlidingWindowMap {
  public SlidingWindowMap(Set keys, int maxCount, long periodMs) {
    // ...
  }
  /**
   * @return a key that has been used less than `maxCount` times during the
   * past `periodMs` milliseconds or null if no such key exists.
   */
  public String getNextKey() {
    // Your brilliant Solution goes here
  }
}
```

Click the Markdown button and voilà:

Your turn now, what email tricks do you use which you think very few people know?

Last week, I mentioned a bug that I caused and a few people asked me details about it, so here is what happened.

The code in question is parsing a calendar and processing meetings. Before showing the buggy code, here is what a shortened version of the fix ended up looking like:

while (maxDays < 7 && (eventCount < 20) || attendeeCount < 40) {
    // process meetings
    // increment maxDays whenever we cross a day boundary
    // possibly increment eventCount or attendeeCount based on the meeting
}

The bug went unnoticed in production for a few days until suddenly, the servers started pinning all their CPU's and shortly thereafter, depleting the memory of each instance. A restart was the only remedy.

This code runs a loop through someone's calendar and stops until we've gathered enough information. The maxDays variable is what I call a "safety valve", a condition used to guarantees that the code doesn't run amok in case its normal processing flow never finishes. And yet, the crash seems to indicate that the code was doing exactly that.

With this introduction out of the way, here is now the line that caused the bug:

Actually... you've already seen it, it's the code I pasted above. Did you spot the problem?

That's right, a simple set of parentheses in the wrong place. Because they are surrounding the wrong expression, they completely defeat the purpose of the safety valve, which only triggers for people with empty calendars (explaining why it took some time to trigger that bug).

Two characters to bring down an entire server...

Can we learn anything about this bug, besides the fact that testing needs to cover edge cases? A static analysis tool can't be of much help here since we're completely in the realm of runtime behavior, but is there some way that an automated tool could have warned me about the flaw of this termination expression?