Forgot your password?
typodupeerror

Comment: Re:Amazon Silk + SSL = MITM? (Score 1) 249

by Kupo (#37556878) Attached to: Amazon's New Silk Redefines Browser Tech

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.

Comment: Amazon Silk + SSL = MITM? (Score 5, Insightful) 249

by Kupo (#37549184) Attached to: Amazon's New Silk Redefines Browser Tech
Cross posting from my old comment. As per their help:

What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com/ ).

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.

Comment: Amazon Silk + SSL = MITM? (Score 2) 521

by Kupo (#37544958) Attached to: Amazon Kindle Fire Surfaces
As per their help:

What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com/ ).

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.

Comment: Alternative Solution: Implement it Right? (Score 5, Insightful) 354

by Kupo (#27550409) Attached to: Can rev="canonical" Replace URL-Shortening Services?

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?

White dwarf seeks red giant for binary relationship.

Working...