The RFC you linked to points out: in a proxy situation, this establishes a secure connection between you and the proxy (between proxy and target site is undefined). If you want end-to-end TLS, it states you must use CONNECT to create a tunnel.

I can't imagine Amazon would funnel TLS encrypted connections through AWS using this method, since the whole point of Silk is to analyze/cache/preload the content (end-to-end crypto would break this ability). If they couldn't read your HTTPS data, it would be less latency for you and cheaper for Amazon to have the client connect directly. Their Help site makes it sound like proxy/cached mode is the default setting, so IMHO it still is effectively a man-in-the-middle.

Thankfully, it looks like you can disable it (or use a different browser), so I may just be paranoid for no reason.

So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.). Call me paranoid, but if I read this right, this sounds like a frightening idea.

So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.). Call me paranoid, but if I read this right, this sounds like a frightening idea.

There's all this talk of URL shortening services - whether third-party, or in-house implementation.

The question here is this: Why are the URLs so long to begin with?

Why does it have to be:
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical

A full title in the URL is, IMHO, a very inefficient idea. The excuses I've heard are:

Search Engine Optimizations (better performance when keywords are in the URL)
Okay, I can't argue that some search engines do stuff like that. But shouldn't the TITLE or META tags have more bearing on this than how ridiculously long the URL is?

"The URL has meaning, so you know what you're clicking", Context, etc.
I suppose that when I see a URL like
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
as opposed to something like
http://example.org/blog/526
I would have a slightly better idea of the article's content before clicking on it. But then again, I can't really say that I've decided against clicking on a link just because of the link URL. I would, instead, decide whether I'd want to visit the link by its link text/description.

So <a href="http://example.org/blog/526">blog on link shortening</a> would still have the same effect on me as a long URL IMO. If it were bookmarked, the same rules would apply.

Hell, if I were handed an obfuscated shortened URL without context, I'd know even less of what I was getting myself into.

I think the proper solution is to just stop making ridiculously long URLs to begin with, so we don't have to rely on obfuscation/hashing/shortening to accommodate services that have character limit restrictions. And we'd save bandwidth too, apparently. Win-win?