Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small things add up: 4chan's migration to a cookieless domain

chrishateswriting.com

Post reply on HN
Print view View original

91–100 of 139 posts

Re: Small things add up: 4chan's migration to a cookieless domain

#91

Post by hobohacker »

moot wrote: post #58
maxk42 wrote: post #45

Earlier quoted context omitted.

A huge portion of their user-base doesn't visit with SPDY-capable browsers.

Actually 78.75% of our users are on Chrome/Firefox! SSL is forced on our domain you post to (sys.4chan.org) with redirects and HSTS, and we set cookies with proper Secure and HTTP-Only flags. Maybe some day we'll force SSL site-wide, but I don't think that's the right decision for now. I definitely encourage people use the EFF's wonderful HTTPS Everywhere extension though: https://www.eff.org/https-everywhere

I'd love to hear what's stopping you from forcing SSL site-wide. Is it cost? If so, what are the specifics if you don't mind sharing?

Also, I don't know if you're using different VIPs for load balancing or lack of SNI support reasons or what not, but if your certificate provides proof of authentication for all your hostnames (probably need to use SubjectAltNames and maybe wildcards too) and the VIPs match, then Chrome & Firefox will send requests for those different hostnames over the same SPDY connection.

Re: Small things add up: 4chan's migration to a cookieless domain

#92

Post by AsymetricCom »

I don't have any of these problems with 4chan because I block most of their JS and I don't accept 3rd party cookies, and I definitely don't let any Google APIs run on my local machine. Google's APIs are for Google's hardware, which my hardware is not a subset of.

Re: Small things add up: 4chan's migration to a cookieless domain

#93

Post by Guvante »

doctorfoo wrote: post #63

Hey moot, why don't you let pass users bypass individual IP blocks? I refuse to disable my VPN, so it means I can't post any more. A shame 4chan has no way for privacy conscious users to post, especially given your support of StopWatching.us and such.

It heavily depends on how they implement IP bans. Often they are done at a much lower level, making verifying the user is logged in impossible. Doing them at a high level usually makes the ban not effective as they still waste a bunch of overhead.

The alternative is to have two views of the site that hit different servers, one that requires login and another that does not, but that introduces a whole slew of other problems. It would probably be the way to go if you wanted to do this however.

Re: Small things add up: 4chan's migration to a cookieless domain

#94

Post by Guvante »

lucb1e wrote: post #51

Now, what about the extra DNS lookups? That adds 1x roundtrip time for the user, plus 20-40 bytes of IP header (v4/v6), plus 8 bytes UDP header, plus ~25 bytes for the query and ~100 bytes for the reply.

The DNS lookup only has to be done once and is then cached on the users local machine, at least for the overall request (if not longer).

Thus the cost is only 160 bytes for the page, which isn't all that much.

Additionally assuming their cache timeouts are non-trivial there are several caches to reduce the delay incurred by this.

Re: Small things add up: 4chan's migration to a cookieless domain

#95

Post by pw77 »

TorKlingberg wrote: post #61
lucb1e wrote: post #51

Now, what about the extra DNS lookups? That adds 1x roundtrip time for the user, plus 20-40 bytes of IP header (v4/v6), plus 8 bytes UDP header, plus ~25 bytes for the query and ~100 bytes for the reply.

Wouldn't that be cached after the first load?

Doesn't that depend on the browser? Chromium definitely does cache DNS records (chrome://net-internals/#dns). I remember Firefox relying on a system configured DNS cache (dnsmasq or pdnsd on Linux).

Re: Small things add up: 4chan's migration to a cookieless domain

#96

Post by sk5t »

wvenable wrote: post #4
quchen wrote: post #2

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. That's a void argument in the article. If they were serving pages with 500 bytes each this would indeed be a huge improvement, but no page is 500 bytes. I just opened 4chan.org, and the markup before is already 1,836 bytes. The entire frontpage of /b/ is 114,428 bytes, and saving 50 is absolutely negligible. On th…

You are looking at the traffic sent by the server to the client but cookies are sent by the client to the server. Upstream vs. downstream. Cookies are much larger proportion of the request. Also the response can't even be sent until the entire request is retrieved.

Excellent point... we can also safely assume the average user's upstream connection is quite a bit slower--likely on any metric other than latency--than his downstream.

In addition, let's not forget to multiply the cookie overhead by the number of images on the page... likely to be quite a large number given 4chan's love of images and enormous, eager-loaded discussion threads.

Re: Small things add up: 4chan's migration to a cookieless domain

#97

Post by kibibu »

sliverstorm wrote: post #65
bjt wrote: post #38

Earlier quoted context omitted.

But then you still have to remain vigilant against a clueless dev or random JS lib on www.domain.com setting a cookie for .domain.com, which your browser will helpfully include with requests to cdn.domain.com. With the completely separate root you're protected from that. http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path

So basically it doesn't have to be that way, but to protect yourself from cluelessness/stupidity, you do it. Kind of like Unix permissions vs. jails/virtual machines. Both are secure, but one is more secure against incompetence than the other.

We use wildcard cookies to let users login to www.domain and peek at beta.domain without logging in again. This isn't incompetence so much as reducing user drag. Perhaps I should have set it up to use www.domain/beta/ instead.

Unfortunately, this means our cookies are sent to static.domain. Worse, once we get rid of beta.domain there's no going back on wildcard cookies - there's no way to force clients to expunge cookies.

Re: Small things add up: 4chan's migration to a cookieless domain

#98

Post by cheald »

moot wrote: post #37
cheald wrote: post #35

Earlier quoted context omitted.

They don't. You could serve your site off of www.domain.com and your CDN off of cdn.domain.com easily.

Correct, but only if you don't set any *.domain.com cookies, which as it turns out most do.

Right -- if you're serving your website off of the root, then you're going to have this problem. If you serve it off of www (which, as it turns out, is how domains were originally intended to be used!) then you don't.

It's not an inherent flaw of the tech. It's a flaw in how we use it.

Re: Small things add up: 4chan's migration to a cookieless domain

#99

Post by cheald »

kibibu wrote: post #97
sliverstorm wrote: post #65

Earlier quoted context omitted.

So basically it doesn't have to be that way, but to protect yourself from cluelessness/stupidity, you do it. Kind of like Unix permissions vs. jails/virtual machines. Both are secure, but one is more secure against incompetence than the other.

We use wildcard cookies to let users login to www.domain and peek at beta.domain without logging in again. This isn't incompetence so much as reducing user drag. Perhaps I should have set it up to use www.domain/beta/ instead. Unfortunately, this means our cookies are sent to static.domain. Worse, once we get rid of beta.domain there's no going back on wildcard cookies - there's no way to force clients to expunge coo…

You could use beta.www.domain.com.
Post reply on HN