In an ever-evolving world where every technology gets a transition sooner or later, Hypertext Transfer Protocol (HTTP) seemed the exception: it went on unchanged for fifteen years. Too much time for Google, who started developing its own alternative: SPDY. As time would have it, SPDY became the cornerstone for the work on the new HTTP/2, and now that this new standard is so close as to be in IETF Last Call state, Google is happy to say Hello HTTP/2, Goodbye SPDY, move in to the new standard, and drop SPDY support on Google Chrome in about a year.
This news is available in Ars Technica and Slashdot too.
Related Stories
My previous submission showed the spooks piggybacking hackers. A previous disclosure from the Snowden stash run by The Intercept shows how much care the spooks take care about your (tax) money - they piggyback ad-trackers as well, in a programme codenamed BADASS:
British and Canadian spy agencies accumulated sensitive data on smartphone users, including location, app preferences, and unique device identifiers, by piggybacking on ubiquitous software from advertising and analytics companies, according to a document obtained by NSA whistleblower Edward Snowden.
...
For users, however, the smartphone data routinely provided to ad and analytics companies represents a major privacy threat. When combined together, the information fragments can be used to identify specific users, and when concentrated in the hands of a small number of companies, they have proven to be irresistibly convenient targets for those engaged in mass surveillance. Although the BADASS presentation appears to be roughly four years old, at least one player in the mobile advertising and analytics space, Google, acknowledges that its servers still routinely receive unencrypted uploads from Google code embedded in apps.
Maybe SPDY had a better idea than HTTP/2?
Today, the next major version of HTTP took a big step toward becoming a reality; it’s been officially finalized and now moves towards being fully standardized. According to a blog by Mark Nottingham, the chair of the IETF HTTP Working Group, the standard was completed today and is on its way to the RFC Editor to go through editorial processes before being published as a standard.
HTTP/2 is a huge deal; it’s the next big version of the Hypertext Transfer Protocol, marking the largest change since 1999 when HTTP 1.1 was adopted.
The new standard brings a number of benefits to one of the Web’s core technologies, such as faster page loads, longer-lived connections, more items arriving sooner and server push. HTTP/2 uses the same HTTP APIs that developers are familiar with, but offers a number of new features they can adopt.
Chromium Blog has published an update on Quick UDP Internet Connections (QUIC). QUIC is a UDP-based transport layer network protocol which began testing in the Google Chrome browser in 2013. One of the goals of QUIC is to reduce latency compared to TCP by making fewer round trips between clients and servers. It also handles multiplexing and packet loss better.
QUIC clients store information about QUIC-enabled servers that have been connected to previously, allowing a secure connection to be established immediately (zero-round-trip). Google claims this can enable significant reductions in page load times:
The data shows that 75% percent of connections can take advantage of QUIC's zero-round-trip feature. Even on a well-optimized site like Google Search, where connections are often pre-established, we still see a 3% improvement in mean page load time with QUIC.
Another substantial gain for QUIC is improved congestion control and loss recovery. Packet sequence numbers are never reused when retransmitting a packet. This avoids ambiguity about which packets have been received and avoids dreaded retransmission timeouts. As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections. These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
Google plans to propose QUIC to the Internet Engineering Task Force as an Internet standard, just as it has done with SPDY, which is being superseded by the HTTP/2 standard.
Google isn't the company that we should have handed the Web over to
Back in 2009, Google introduced SPDY, a proprietary replacement for HTTP that addressed what Google saw as certain performance issues with existing HTTP/1.1. Google wasn't exactly wrong in its assessments, but SPDY was something of a unilateral act, with Google responsible for the design and functionality. SPDY was adopted by other browsers and Web servers over the next few years, and Google's protocol became widespread.
[...] The same story is repeating with HTTP/3. In 2012, Google announced a new experimental protocol, QUIC, intended again to address performance issues with existing HTTP/1.1 and HTTP/2. Google deployed QUIC, and Chrome would use QUIC when communicating with Google properties. Again, QUIC became the basis for IETF's HTTP development, and HTTP/3 uses a derivative of QUIC that's modified from and incompatible with Google's initial work.
It's not just HTTP that Google has repeatedly worked to replace. Google AMP ("Accelerated Mobile Pages") is a cut-down HTML combined with Google-supplied JavaScript designed to make mobile Web content load faster. This year, Google said that it would try to build AMP with Web standards and introduced a new governance model that gave the project much wider industry oversight.
A person claiming to be a former Microsoft Edge developer has written about a tactic Google supposedly used to harm the competing browser's performance:
A person claiming to be a former Edge developer has today described one such action. For no obvious reason, Google changed YouTube to add a hidden, empty HTML element that overlaid each video. This element disabled Edge's fastest, most efficient hardware accelerated video decoding. It hurt Edge's battery-life performance and took it below Chrome's. The change didn't improve Chrome's performance and didn't appear to serve any real purpose; it just hurt Edge, allowing Google to claim that Chrome's battery life was actually superior to Edge's. Microsoft asked Google if the company could remove the element, to no avail.
The latest version of Edge addresses the YouTube issue and reinstated Edge's performance. But when the company talks of having to do extra work to ensure EdgeHTML is compatible with the Web, this is the kind of thing that Microsoft has been forced to do.
See also: Ex Edge developer blames Google tricks in part for move to Chromium
Related: HTTP/2 on its Way In, SPDY on its Way Out
Google Touts QUIC Protocol
Google Attempting to Standardize Features of Accelerated Mobile Pages (AMP)
Google AMP Can Go To Hell
The Next Version of HTTP Won't be Using TCP
HTTP/3 Explained: A Work in Progress
Microsoft Reportedly Building a Chromium-Based Web Browser to Replace Edge, and "Windows Lite" OS
Mozilla CEO Warns Microsoft's Switch to Chromium Will Give More Control of the Web to Google
(Score: 2) by c0lo on Wednesday February 11 2015, @10:40AM
So? (et alors)? (don't let me hanging there, go on with explaining the consequences...)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 5, Informative) by Nesh on Wednesday February 11 2015, @11:05AM
One of the consequences is that the mandatory secured connection of SPDY using TLS have been dropped.
IIRC HTTP/2 doesn't retain that always-on encryption requirement.
HTTP/2 can be used to 'speed up' HTTP without using TLS.
(Score: 5, Interesting) by Hairyfeet on Wednesday February 11 2015, @01:49PM
If its anything like HTML V5 can we just say "no thanks" and move on? I was looking forward to HTML V5...until the corps got done sticking their 2c in, now its got DRM baked into the spec, claims to replace Flash yet doesn't do a third of what Flash does and what it does do it does poorly (compare resource and CPU usage of HTML V5 H.264 versus Flash with VP8 or even VP6 and its a bad joke, HTML V5 needs hardware acceleration to keep from being a slideshow whereas I can take a 12 year old P4 and run 720P flash at 30 FPS+ strictly on the CPU with cycles left over) and comparing like to like it uses more while doing less pretty much across the board.
Call me a Luddite if you want but IMHO the problem I have with these is that before they seem to be developed from an engineering standpoint whereas now you have too many parties with their own agendas tacking shit on. Instead of focusing on increasing performance without sacrificing security we end up with each group trying to push tech which will benefit their business models and I may be getting cynical but I just don't have high hopes it won't end up another bloated mess like HTML V5.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 1, Interesting) by Anonymous Coward on Wednesday February 11 2015, @02:27PM
The downside is to continue to use flash and java plugins.
I think I have updated my flash plugin at least 3 times this *year*. I removed java about 2 years ago for the same reason.
I use no-script. Gave flashblock a whirl but it was annoying to use with no-script also.
Flash is a security nightmare at this point. It served us well. But adobe has not kept up with staying ahead of the scammers. It is clear they do not take security very seriously. It is an afterthought. If you are missing hw accel for v5 blame your browser.
HTTP2 for me does not do much at all. For the guys serving this up it is pretty good. It lets the use less resources for the same data. That I get a small speed bump is fine by me. HTTP3 should be where it gets interesting and they drop HTTP1/0.9 features.
(Score: 2, Insightful) by Anonymous Coward on Wednesday February 11 2015, @03:01PM
I am starting to think we (as in security conscious users) will look back on the flash/java days with fondness. With plugins it is easy to isolate the risk, with ask-to-activate on a per page basis you don't have to worry about drive-by exploits. It wasn't perfect - there is still the possibility that a hacker is able to get their flash code on a page with legitimate (and useful) flash content, but that's a thousand times harder than injecting flash on some random web page.
But HTML5 makes that sort of control much more difficult. Maybe someone will come up with a no-script equivalent that gives users easy fine-grained control over various HTML5 functions. But AFAIK, HTML5 was neither designed nor implemented with any thought along those lines so if it ever happens, its going to take a lot of work for someone to do it.
(Score: 2) by urza9814 on Thursday February 12 2015, @01:37PM
Why? You could do it with a Greasemonkey script.... document.getElementsByTagName() ought to be sufficient, maybe with a few getAttribute() checks...
(Score: 1, Insightful) by Anonymous Coward on Monday February 16 2015, @11:59AM
You may be on to something.
Some things I like about HTML5: audio and video tags (which are really syntactic sugar for the object tag), the time tag, the simplified header, and I can see the point of canvas, though I really prefer SVG.
There are many things I don't like about HTML5: mostly that it is designed as a security flaw.
I also do not understand why video decoders need to be baked into the browser executable, when twenty years ago an embedded window of a media player was already better.
I never liked flash. I would have preferred for it to be a separate executable rather than the browser parasite that it was. I never liked RealAudio either, and that at least did something useful.
(Score: 1, Informative) by Anonymous Coward on Wednesday February 11 2015, @01:18PM
>Google unveiled the protocol in 2009, claiming it would deliver as much as a 55 per cent speed increase for the web's highest-traffic sites. Google's decision to kill SPDY in Chrome will go unnoticed by most users. Both the web browser and the server must support the protocol for it to have any effect, and few web servers enabled it – Google being a notable exception, naturally. Google says it won't remove support for the spec from Chrome until "early 2016." Meanwhile, a version of Chrome that supports HTTP/2 will roll out to the browser's Stable release channel in the next few weeks.
(Score: 5, Interesting) by Entropy on Wednesday February 11 2015, @02:49PM
The scariest thing I saw about HTTP2 was 'explicitly trusted proxies'. Of course, that can go a lot of ways, but if it's implemented as
any trusted certificate authority can issue a 'trusted proxy' certificate and MITM all SSL connections... Screw that. Clearly ISPs can
not be trusted to decrypt traffic in transit that should be encrypted... and in fact no one can. That's why it's end-to-end encryption.
(Score: 2, Interesting) by McD on Wednesday February 11 2015, @04:47PM
As noted a year ago by Lauren Weinstein [vortex.com]
Anybody have an update? Or is this fail still baked in?
(Score: 2) by tempest on Wednesday February 11 2015, @06:04PM
My understanding of the problem was that TLS was required, so the only way to cache content was to decrypt it first. Since they've relented on the mandatory encryption part in http2, the MIM thing shouldn't be an issue.
(Score: 2, Insightful) by Entropy on Wednesday February 11 2015, @11:27PM
In my opinion in today's world it should all be encrypted. We've seen evidence that everyone is watching. Verizon is injecting supercookies into my phone so I'm tracked on the Internet why? Because they can. It's unfortunate but the only way to keep ISPs from doing crappy things is to lock them out of the session. In today's world cached content isn't exactly something I'm interested in as the small pipe is the one to my phone/home..not the one into the ISP.
(Score: 0) by Anonymous Coward on Wednesday February 11 2015, @11:21AM
Word has it that Chrome Browser hides the url http:// to ease the transition to SPDY.
(Score: 0) by Anonymous Coward on Wednesday February 11 2015, @03:30PM
Sorry, really not trolling or flamebait and maybe a RTFA is in order... But what is it that I should expect out of HTML2 or SPDY that we don't currently have? Will I Internet any better?
(Score: 2) by kaszz on Wednesday February 11 2015, @11:45PM
I suspect more obfuscation and trust-us proxies. Benefactors will be listening organizations and corporate profits.