Hacker News Reader

Comment by icebraining | Hacker News Reader

Well, HTTPS adds latency due to its handshake, and of course it uses more CPU, especially on the server (unless a dedicated SSL offloaders is used).

View on HN

Rules of thumb for 2011:

• If you are generating your content in a dynamic creation system, the encryption overhead of SSL is not going to matter.

• SSL initial session latency is highly variable based on packet round trip time of the user. Some people will be irritated, other's can't tell the difference.†

␄

† I suppose there is room in the world for a CDN-like entity that places anycasted SSL entry points in strategic locations (or topology sensitive DNS lookups), then uses a zero-turnaround at startup encryption protocol back to the "real" servers. (Say, HTTP over a VPN or something more clever, after all you are the client and the server, life is easy). You'd even beat straight HTTP since by keeping alive the HTTP link to the real servers you'd save the TCP SYN turnaround. 👍

‡ Unrelated: The unicode committee has lost their mind. OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph. I suppose now that PILE_OF_POO and NAIL_POLISH are taken care of the committee will add everyone's avatars from all systems.

I thought you were joking about PILE_OF_POO and NAIL_POLISH until:

http://www.fileformat.info/info/unicode/char/1f4a9/index.htm

http://www.fileformat.info/info/unicode/char/1f485/index.htm

WHY?!

I assume you've seen this? http://💩.la

http://www.panic.com/blog/2011/07/the-worlds-first-emoji-dom...

> OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph

All I see is EOT symbol

And yet on the flipside, it should prevent interception of login credentials or page-content filtering.

> it should prevent interception of login credentials

That was already possible using HN's OpenID support and a secure provider.

OpenID doesn't prevent session hijacking though does it? It would just prevent the credentials being stolen.

> That was already possible using HN's OpenID support and a secure provider.

Not actually sure what your point is here.

Using OpenID (with a secure provider) to login to HN prevents the stealing of login credentials and was possible even without HN supporting HTTPS. I don't see what's strange about this.

By the way, I'm not claiming that enabling HTTPS is wrong, I'm giving potential disadvantages. It's the website admins' job to weight those against the advantages and decide whether it's the right thing to do or not.

OpenID may prevent stealing login credentials, but it doesn't prevent stealing the cookie which identifies your session.

Also, if you can hijack the http, you can link to a phishing site which prompts users for their OpenID provider (typically their google account) credentials. Maybe they would notice that the domain name of the phishing site (say googleopenid.com, which is available) is fishy ...

https gives you more than just encryption.

I meant why the fact there was a way to do it already actually related to the debate overmuch. This protects people who just use a bog-standard HN account, and further secures all users when actually on the site regardless of login method.

On the server side, it is ycombinator's decision if they can handle the additional cpu cycles. i believe they can, or else they wouldn't have enabled it.

on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it.

>on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it.

That doesn't seem to be the general opinion here: http://news.ycombinator.com/item?id=2565694

And high(er) latency on HN would be a problem because ... ? It's such a highly interactive website? There are billions of high quality images to be loaded? Hundreds of ajax calls going back and forth every second?

Right.

You can't feel the latency?

It adds half a second or more to initial page load times. For doing any sort of marketing where potential customers are arriving at your landing page, that's huge.

Not necessarily so noticable. I've been running my personal site with https and the effect is fairly minor on the whole in terms of load times. Not zero, but low enough that your average user on the other side of the Atlantic wouldn't notice much of a difference to normal.

Admittedly this is a poor comparison vs a huge site, but then you'll probably find the server processing time is your greater foe.

I was refering to my own feeling when loading HN, a (in comparison) very simple website.

I am sorry if it sounded like I was talking about any website in general. That is not the case.

For some sites, where security particularly matters, using https by default on your landing page seems like good marketing.

I can't tell the difference... HN is pretty damned slow already as it is.

Reply on news.ycombinator.com