Why SSL-everywhere is not necessarily a good idea in all circumstances
I'm in a remote location where the only comms are via a satellite link. This is what my internet connection looks like at the moment:
[ron@mighty:~] ping google.com
PING google.com (4.35.21.152): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 67.201.56.75: icmp_seq=0 ttl=46 time=7264.039 ms
64 bytes from 67.201.56.75: icmp_seq=1 ttl=46 time=6773.034 ms
64 bytes from 67.201.56.75: icmp_seq=2 ttl=46 time=7007.539 ms
64 bytes from 67.201.56.75: icmp_seq=3 ttl=46 time=6106.535 ms
64 bytes from 67.201.56.75: icmp_seq=4 ttl=46 time=5740.475 ms
64 bytes from 67.201.56.75: icmp_seq=5 ttl=46 time=5052.218 ms
64 bytes from 67.201.56.75: icmp_seq=6 ttl=46 time=4352.883 ms
64 bytes from 67.201.56.75: icmp_seq=7 ttl=46 time=3468.035 ms
Under these circumstances I can just barely open a regular HTTP connection, but most HTTPS connections time out before they can be established. So I can't do a Google search :-((Even submitting this to HN required multiple attempts.)
12 comments
[ 2.8 ms ] story [ 39.9 ms ] threadNo, we're not going to prevent and/or stone-wall encryption just so a connection with an average 7+ second latency works marginally better.
As an aside - this satellite connection is one of the worst ones I've seen. Old satellite connections are supposed to be on average about 1 second of latency[1] (and that's considered bad).
[1] http://arstechnica.com/information-technology/2013/02/satell...
You may wish to get Opera browser and utilise their "Turbo" service (it is an optimising proxy, it compresses the page content, removing several round-trips, etc). Should have smooth out the issues a little bit.
Who argued for that? Nobody has asked for SSL to be banned, or for SSL to not be available, or even that SSL shouldn't be the default.
It's interesting. It's something that many developers wouldn't think about, but it has a real world consequence for this user in this instance.
Yes, we aren't going to throw away SSL because they had a bad experience, but it IS interesting to note, and it may even lead a few developers to think about how their tools could impact the users in non-optimal conditions.
It doesn't have to be an argument to be interesting...
By your description it sounds like your current location is temporary (which is fortunate ;P) but that you'll revisit this location in the future, so it might be worth your while to explore different UDP data transfer algorithms once you're back with sane Internet, then test said techniques when you revisit where you are now.
Best case scenario, you might be able to tunnel TCP over some kind of "best effort" UDP retry algorithm that overcomes a proportion of the losses; it should be possible (while complicated) to implement a more intelligent packet-loss mitigation system that handles significantly broken connections better than TCP does.
A far simpler system might be a VT100-esque text terminal running on top of a best-effort transfer layer like those described above. The only problem with this method would be the input latency, although it may fare better than a browser overall (!).
Also, I'm not sure if it's relevant (my understanding of networking is sketchy), but I find it amusing that 67.201.56.75/0's description is "Zerolag Communications" xD (http://bgp.he.net/net/67.201.56.0/21)