Google's False Start gets a real stop
Google security researcher Adam Langley has announced that Google is abandoning attempts to bring its secure connection speed-up False Start technology to HTTP/S enabled sites. False Start was introduced in Google's Chrome open source browser and attempted to speed up secure connections by reducing the number of round-trip passes involved in setting up an SSL connection – this was achieved by getting the client to send the "Finished" message and first ApplicationData message in one packet, rather than sending "Finished", waiting for a response and then sending the first ApplicationData message. False Start could reduce the time taken to start connections by 30 per cent.
But there was a problem. Langley explained that, while FalseStart was implemented in Chrome and Google believed that it was compatible with a most web sites, it used a blacklist for sites which were False Start intolerant. Google's engineers found that it was hard to work out which sites would fail and it became harder still to work with the large community of web administrators and vendors. Langley said "One, fairly major SSL terminator vendor refused to update to fix their False Start intolerance" but did note that he didn't believe it was acting in bad faith. Another problem was having to work in more languages than just English with the system administrators, despite having good local liaisons around the world.
"False Start was causing more problems than it was worth" said Langley. But it is not the end for the optimisation; Google will continue to support the technique with sites that implement NPN, which is being used with Google's SPDY technology – SPDY also endeavours to speed up connections by multiplexing and compressing multiple requests into one connection. Until SPDY takes over, Langley says, False Start will just be "an arcane, unused optimisation for the most part".