May 23, 2014

Security Standards and Name Changes in the Browser Wars

The Netscape/Microsoft browser wars in the mid-90's were really vicious and competitive. They really had it out for each other.

Netscape had developed the SSL protocol. The initial version had cryptographic flaws and was broken pretty quickly, and never released. The first production version was SSL 2, which was in use for a few years. (I don't know the exact versions of Navigator it shipped in.)

SSL 2 had some flaws, both cryptographic and practical; not dramatic enough to make replacing it a crisis, but it clearly needed some work from early on.

As a part of the cutthroat competition, Microsoft decided to revise the SSL 2 protocol with some additions of their own, and specified a protocol called "PCT" that was derived from SSL 2. It was only supported in IE and IIS.

Netscape also wanted to address SSL 2 issues, but wasn't going to let Microsoft take leadership/ownership in the standard, so they developed SSL 3.0, which was a more significant departure.

Various people in the industry & community didn't want a fork, so we (Consensus Development, where I worked with Christopher Allen at the time, and where I had written the SSL 3.0 reference implementation under contract to Netscape) hosted a meeting between representatives from Netscape and Microsoft; I forget everyone who was there, but I recall that Bruce Schneier was there (before he was famous), and probably Paul Kocher, who had designed the SSL 3 protocol; Barbara Fox represented Microsoft. And we negotiated a deal where Microsoft and Netscape would both support the IETF taking over the protocol and standardizing it in an open process, which led to me editing the RFC.

As a part of the horsetrading, we had to make some changes to SSL 3.0 (so it wouldn't look the IETF was just rubberstamping Netscape's protocol), and we had to rename the protocol (for the same reason). And thus was born TLS 1.0 (which was really SSL 3.1). And of course, now, in retrospect, the whole thing looks silly.

The Quality of News

Here's a comment I wrote in response to this post on Facebook from Mike Hudack:

As long as an ad impression on a "serious story" pays as much as an ad impression on a listicle and people are more interested in viewing listicles than real news, this will likely continue. Facebook accelerates the problem, but is not its core source. And the media outlets that produce this crap are just following the incentives: if they don't do it, someone else will (and that someone else will be all over your social media feeds).

America's tradition of quality journalism stems from two sources: bundling and the fact that some fraction of media outlets were owned by families and businesses who were interested in their reputations, not just their bank accounts. Serious news has never sold well, but as long as you had to buy a newspaper to get both the front page and the sports page, one could support the other, and it was in the interest of the families that ran those papers to be seen as serious; they funded the news desks to maintain that image. This worked, particularly when newspapers had strong, well-defended businesses which weren't vulnerable to disruption, and the bundling helped everyone hide the truth about what components of the bundle the audience actually cared about.

Now, however, people consume content one page view at a time: bundling has vanished, and brand value is low. Anyone can start a media outlet, and there's no audience loyalty. Advertisers pay pretty much the same amount for an ad view regardless of what content it's next to. And programmatic buying has eroded any value advertisers gave to serious brands: now they just want to find the audience, wherever they are. The revenue and cost of a serious news piece vs. a cheap slideshow is clearer than ever and easy to optimize. So it's a race to the bottom, and devil take the hindmost.

There's plenty of great content out there—probably more than ever—but it doesn't get a lot of attention, particularly on social media.

Personally, I think the most likely way out is charging readers for quality news and surviving the sharply reduced audience that will imply. It will entail focusing reporting on concepts that can't be easily "aggregated" by other outlets. The free media will still be a sewer, and most people will only read that. But maybe we could develop a supportive and self-sustaining ecosystem for quality reporting for the people who care about it. That said, it's hard to get there.

April 23, 2014

An open letter to a Google Now product manager

Google Now is awesome. You can search for an address in Google Maps and automatically get that destination transported to your phone for super-easy directions, etc.

Unless, of course, it doesn't work for some reason. And there’s no indication of why the address you searched for isn’t on your phone; could be a lot of things—sync problems, maybe Google didn’t think it important enough to surface, etc.

After a number of months of feeling like Google Now didn't work for me all that well, I finally realized that it’s because I don't have Web History enabled on my Google Apps domain. Presumably, Google Now consumes the Web History logging stream, and if you don't save your searches, it can’t copy them over to your phone. Fair enough (although one might hope for the ability to ephemerally share such data across your account without logging it forevermore).

What is insane is that this is the default and how hard it is to discover and fix. Google Now, which is one of Google's big tech advances and product advantages, they should be making it easy for people to use and discover. It took me about a dozen steps to turn it on for my domain after I’d diagnosed the problem (with no prompting from Google).

It should be absolutely clear to a Google Now user that they’re missing out on functionality if they have Web History disabled. When you open Now, there should be a card at the bottom telling you that it's off. Even in the Now settings, I don't believe that the Web History setting works for Google Apps domains.

And in the Google Admin console, it should make it clear how to turn on Web History with a direct link to the setting. Right now, it's super-challenging for a Google Apps admin to turn it back on: I knew what it was, and it still took me a lot of back-and-forth between the admin panel and the documentation to find it:

  • Go to my Google Apps Admin console
  • Click on “Manage the way Google Apps Works for You”
  • Fail to find Web History
  • [back and forth between console and admin docs]
  • Determine that it's in “Other Google Services”
  • Can't find that anywhere
  • Discover that it's hidden by default under "More Controls". (BTW: this hidden icons thing was a bad idea.)
  • Go into “Other Google Services”
  • Can't find Web History anywhere.
  • Figure out that the bland, easily overlooked blue bar is filtering to only show me ”Top Featured Services” may be hiding something useful (BTW, this should be more noticeable and be a more common idiom.)
  • Dismiss it with the [X].
  • Discover that Web History is the ONLY disabled service (beside AdSense) in my domain.

February 28, 2014

Getting Custom Notifications for Important E-mail

I get a lot of email, and sometimes I miss something, or I don't notice something urgent right away.

Here's how to configure Gmail on your Android phone to alert you distinctively when you get an urgent email.

First, identify what is important. It might be emails from someone in particular, or with a particular topic, etc. Most recently, I configured a special alert for emails from a particular notification service that always have a certain string in the subject.

Then, in the Gmail web UI, set up a filter for these messages in Gmail and assign them a new label which is specific to this class of messages.

Now, from your phone, go to that label, and from the menu icon in the upper right, choose "Label settings". Then, set this label to sync to your phone (for any duration), and you can then choose a notification sound. Choose a sound you don't use for other notifications on the phone.

Now, whenever you get an email from this category, you'll get a distinctive sound which tells you what's up without you having to even unlock the phone.

You may be able to use this ability to specifically notify on the emails you care about to reduce the alerting for emails you don't care about. You can turn off notifications for new messages in categories or labels that are not urgent. Then, when your phone goes “ding”, you'll know that it's something worth interrupting you for.

November 23, 2013

Common password checker

There are a lot of standards out there for password quality, usually something like "at least 6 characters, with both upper and lower case and a digit or alphabetic character".

These are horrible rules. They mean that a password like "Passw0rd" is thought to be better than "Y1&j)" or "cork-bairn-meson-most-ago". However, it is not. Clever password crackers will, first thing, try a large dictionary of known passwords before they start iterating through strings brute-force, and it's only in the latter stage that using a longer password or a bunch of different character types helps.

So, if you want to get your users to choose passwords that are more likely to be secure, the most important thing is to reject the kinds of common passwords that are most likely to be guessed. Google actually tracks the passwords that crackers try to break into accounts with and notes these as "weak", regardless of how tricky they seem.

So, I built a thing: I took the 1,139,118 most-frequently-used passwords from a large password leak (from the social site RockYou in 2009) and built a password checker. This contains every password that was used 3 or more times across the 32 million leaked accounts. ("Passw0rd" was used 207 times.)

Enter a password below and discover if it's any good. The implementation uses a Bloom filter tuned for approximately 0.1% false positives, so there's one chance in a thousand that a password will show as "weak" when it's actually not on the list. The Bloom filter makes the data transfer smaller (2 MB) and allows very fast checking of candidate passwords agains the list. Nothing is sent back to a server: the checking is done in the browser.

Candidate password: not foundweak
Loading...

Of course, even if your password wasn't found, it still might be quite weak: large password dictionaries have a billion passwords to try before they start churning through every possible string. To generate a better password, you might want to try my password generator. If you're interested in using either to help make your site more secure, let me know, I'm happy to help.

Endianness in Javascript

I just needed to determine endianness from Javascript; this is needed because ArrayBuffer and associated classes operate directly upon memory buffers, which is great when you want to slurp in some binary data without the overhead of JSON-conversion, but does imply an endianness dependency.

I probably could have just ignored the question (at the expense of all my Alpha-powered users), but I'm OCD enough to write the check.

function littleEndian() {
  var buf = new ArrayBuffer(4);
  var bytes = new Uint8Array(buf);
  var words = new Uint32Array(buf);
  bytes[0] = 1;
  return words[0] == 1; // little-endian
}

But I can't test it.

October 26, 2012

Adam Tumor Wrap-up

I started posting Adam's status to this blog because I needed a way to communicate with family and friends, and I abandoned it when his situation didn't really require it. But, having dropped it mid-situation, I left an uncertain status for anyone who came across the blog without knowing the family. Sorry about that!

Adam is doing great. He came home for visits starting at Christmas, and we had a great Christmas. A few weeks later, he started sleeping at home, and commuting into the hospital for therapy every day, which we continued through the spring, then took the summer off. In the fall, we moved to outpatient therapy a couple of times a week, which we did for the 2011-2012 school year, then took another summer off. This year, he's in preschool 5 days a week, and doing great.

We've had some complications, but they're pretty minor, all things considered.

December 14, 2010

Back at Rusk

Just like Lindsay Lohan, we're back in rehab.
Rusk is the top facility for rehab in NYC and one of the best in the country, and it’s absolutely the right place for Adam to be right now. In fact, I made a bit of a problem on Friday night and over the weekend when the administrators at NewYork-Presbyterian and Rusk failed to get him down here on Friday. The climax of that fuss was when they told me that they’d like me to put down a deposit to cover three weeks of care because Blue Shield is closed on the weekend. But I think they were just putting me off—when I asked them where I could bring the check, or if they insisted on cash, they stopped returning my calls.
That said, compared to the newly-built magnificence that is the NYP Greenberg pavilion, the physical plant here does seem a little dated & dowdy. But the care here is right, the staff are excellent, and the food is much better than at NYP (seriously, it’s like making NYP one of the best hospitals in the country required that they have the worst food I've experienced outside of an airplane).
On the subject of insurance: besides being closed on the weekend, the Google health insurance (through Blue Shield of California) has been awesome. We haven't had any problem at all with approvals, and Google's in-house Blue Shield rep has been super-helpful, including calling me Saturday evening to try to work through our problems. While it’s hard sometimes to know how much benefit our kids get from the material rewards of our work lives, I know Adam and the rest of our family are thankful for the support that has enabled his excellent medical care.
We’re hoping to get Adam out of here and home before Christmas. Wish him good luck.

December 11, 2010

Successful Head-shrinking

Here's two photos of Adam this morning, showing his now un-swollen noggin.

December 10, 2010

Back and Forth

On Tuesday, Adam came back to NewYork-Presbyterian to have an MRI and to have a shunt put in to drain the bubble under his scalp. It’s done wonders for his looks (sorry, I don't have a picture right now).
The MRI looked fine; the doctors say he’s doing great and they expect him to have a really strong recovery.
He had the shunt put in Thursday afternoon. It is a bit of tubing (with an anti-siphon valve) that runs from under his scalp (but outside of his skull) down to his abdomen, running just under his skin the whole way. It drains excess fluid, but it’s my understanding that when his surgical wounds fully heal, it will then be idle, as its source is outside of the skull. Putting it in was just a 20 minute operation.
As of Friday morning, he was cleared to leave NYP to return to the Rusk Institute and get his therapy restarted, but we ran into a bureaucratic foul-up; NYP & Rusk wasted the whole day not getting their act together, so we’re still in NYP’s pediatric wing as of Friday night. Last time we went to Rusk, we wasted two days on admitting and insurance paperwork and on actually getting over there. Right now, I fear we’ll repeat that experience, and not get therapy restarted until Wednesday; however, we’re trying to do all we can (with the help of some friends) to get down there over the weekend and get him going on Monday.
Adam is doing well; he seems more comfortable and he’s smiling a lot more. He apparently spent the day asking for pizza; it’s great to have him that engaged & expressive. His doctors all seem to be very happy with his recovery, and we’re hopeful as well.