Slashdot Mirror
Google Chrome Will Adopt HTTP/2 In the Coming Weeks, Drop SPDY Support
An anonymous reader writes: Google today announced it will add HTTP/2, the second major version of Hypertext Transfer Protocol (HTTP), to Google Chrome. The company plans to gradually roll out support to the latest version of its browser, Chrome 40, "in the upcoming weeks." At the same time, Google says it will remove support for SPDY in early 2016. SPDY, which is not an acronym but just a short version for the word "speedy," is a protocol developed primarily at Google to improve browsing by forcing SSL encryption for all sites and speeding up page loads. Chrome will also lose support for the TLS extension NPN in favor of ALPN.
What? POST is the non-idempotent one. See the table in http://tools.ietf.org/html/rfc..., section 8.1.3
Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport. For "national security" in homeland, amirite? God save the homeland!
Huh?
Google has pushed continually to increase the usage and the security of transport encryption. Google's SPDY, the basis for HTTP/2, was designed without any unencrypted mode; it's all TLS all the time. The IETF insisted on making unencrypted transport optional in HTTP/2, but you can be sure that Google won't take that option. Google's next-next generation replacement for HTTP, called QUIC, is a more radical redesign build on UDP rather than TCP, and also has no unencrypted mode. Encryption is baked so deeply into QUIC that it basically can't be removed. Google has also been instrumental in pushing the industry off of various weak versions of SSL/TLS, most recently leading the charge in removing SSL3 support. It was Google's researchers that brought Heartbleed, BEAST, CRIME and POODLE to light. Google Chrome was the first widely-used browser to implement certificate pinning, which was instrumental in the quick discovery of the DigiNotar CA compromise. Google engineers are working to develop a more final solution to the CA trust problem with the Certificate Transparency project. I could go on and on with all the great encryption-related work Google is doing (including my own small contributions to strong crypto on Android).
I think there's an extremely compelling argument to be made that Google is doing and has done more for internet transport encryption security than any other entity for quite some time.
(Disclaimer: I'm a Google security engineer, not a Google spokesperson. The above is not an official statement but only my -- very strongly held -- personal opinion.)
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
In this case, "text" is short for "automatic conversion to/from ascii with CRLF line endings". That is, the sending side will convert from the local format to ascii with CRLF, and the receiving side will convert from ascii with CRLF to the local format.
The local format may be ascii with LF, or even EBCDIC.