SPDY of the Future Might Blow Your Mind Today
belshe.com
belshe.com
This is arguably not a problem for clients that explicitly opt in for this sort of proxy setup. But it sounds like this is not the case for the Kindle Fire. Based on this article (i don't have a Kindle Fire to test this theory), i'm guessing the browser has custom CA's for the SPDY proxy so that the SPDY proxy can spoof any domain through the magic of SNI. If all this is true, then it's pretty evil. People who know enough to check for the "secure connection" badge in the browser would be fooled into thinking they have end to end encryption to the website they are viewing. In reality, the proxy, and whoever runs it, silently has complete access to your unecrypted traffic.
There's quite a few assumptions here. And I'm not a SPDY expert so I may be overlooking something. But this doesn't sound like an optimization i'd be comfortable with.
Based on this article (i don't have a Kindle Fire to test this theory), i'm guessing the browser has custom CA's for the SPDY proxy so that the SPDY proxy can spoof any domain through the magic of SNI. If all this is true, then it's pretty evil.
I don't think this is correct, although I can't describe how Silk actually works.
One example is Opera, they are even compressing http data, pictures etc. before transmitting to the client over a binary socket.
I mean, SPDY has some technical benefits of its own, but the biggest items in the "Pro" column are that it's an open spec and Google has thrown its weight behind it, even dogfooding it in their top sites and a major open-source project. This got people's attention, which previous efforts didn't really manage so well.
http://download.cnet.com/8301-2007_4-57351535-12/whats-comin...
Just grab a Nightly if you want it now.
http://download.cnet.com/8301-2007_4-57351535-12/whats-comin...
Note also that newest pre-versions of Firefox have SPDY (need to enable via about:config)
Also, before, gov't would need to install wiretapping stuff at central offices. With this, Amazon or whatever SPDY provider could just let them have "virtual wiretaps" which I'm sure won't be abused.
From an engineering standpoint, this is cool, but I can't see how this would function without introducing way worse privacy problems. In a world where we'll most likely need to rely on a decentralized Internet that is impossible to regulate, this is a step in the wrong direction.
That's a problem with binary protocols. How does Spdy help the 'open web' when you can't even tell what's even going on at the network layer even after spending lots of time trying?
This blog also like every other advocating Spdy ignores that HTTP tunneling in practice provides the same benefits. And the last graph is the same as for an HTTP proxy, nothing to see there.
Also, efficient formats/protocols need to use byte counting, and byte-counted "text" protocols (BEEP and bencode come to mind) are effectively human-unreadable anyway.
Why? Machine-to-machine communication is for machines, after all, isn't it?
What you call "heavy parsing" is heavy parsing for humans. It's actually easier for machines, because they simply reference (and verify) an offset.
Are you advocating designing a protocol primarily around how easy it is to interactively troubleshoot? Certainly that has value, but on the modern Internet, is it really the dominating concern?
- try checking what a webapp does. TRIVIAL. We're talking minutes.
- try checking what a binary app on your computer does. one with DRMs or advanced "anti crack" stuff for example. FREAKING HARD. Even if you're a wizard, it still takes a few hours. For mortals, we're talking weeks. Weeks!
And that my friend, is why what you wrote is wrong.
You're using the browser or WireShark almost guaranteedly. You can continue to use the same methods with SPDY or compressed/proxied SPDY.