Small things add up: 4chan's migration to a cookieless domain
51–60 of 139 posts
Re: Small things add up: 4chan's migration to a cookieless domain
#52I'm very curious why an anonymous site that doesn't even allow registered users gets 100k worth of cookies on a typical connection. Not saying you're doing anything wrong, just curious. I assume some of it is for ad tracking, but that's still a hell of a lot of data!
It's almost entirely Google Analytics, unfortunately. Our ads are served from a different domain (4chan-ads.org) for specifically this reason (user privacy and cookie bloat).
Re: Small things add up: 4chan's migration to a cookieless domain
#53I never even contemplated the size of cookies before seeing this. It never occurred to me that it could create such an overhead. It'd be incredibly handy if we could set a header like `x-send-cookies: NO` to stop the browser sending cookies along for static content. Great post, a real eye opener.
Re: Small things add up: 4chan's migration to a cookieless domain
#54Now, 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.
Re: Small things add up: 4chan's migration to a cookieless domain
#55On Google news thumbnails would not be shown unless they came from the same domain as the other page.
So our content was on "www.example.com" and pictures were on "media.example.com" but the cookies were for "example.com" so got sent with every image request.
Re: Small things add up: 4chan's migration to a cookieless domain
#56> If you’ve been linked directly to a Facebook photo, you may have noticed the domain wasn’t facebook.com, but instead something like fbcdn-x-x.akamaihd.net. Large sites load static content from special domains for a few reasons, but primarily to reduce request overhead, and sometimes security. This works for 4chan, but in case of Facebook, it actually reduces security - since cookies cannot be checked for photos on…
If you give the url of the photo you are allowed to see to someone else, you can give the actual photo as well. I don't get the security risk here.
Re: Small things add up: 4chan's migration to a cookieless domain
#57I'm a bit paranoid, don't trust google and never really liked the idea of recaptcha on 4chan because of the illusion of anonymity found there. The cherry on the top is finding out uses Google analytics (mind you I haven't been there in a while. Back then I wasn't nearly this concerned with privacy)
Re: Small things add up: 4chan's migration to a cookieless domain
#58They should probably also force connections trough their SPDY supported HTTPS, rather than making it an option.
A huge portion of their user-base doesn't visit with SPDY-capable browsers.
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
Re: Small things add up: 4chan's migration to a cookieless domain
#59Earlier quoted context omitted.
I'd be very interested in this... I used to visit 4chan all the time back in the day, not so much now, but I do enjoy reading statistics about the site. Thanks for this article moot.
I've been meaning to write a post about all of the weird stuff we do in the interest of maximizing our limited resources. We've always had to stretch things as far as possible given server, financial, and time constraints, which has led to some interesting/unorthodox "solutions."
Re: Small things add up: 4chan's migration to a cookieless domain
#60Earlier quoted context omitted.
I'm pretty certain 4channers are good at tracking down profile URLs from just a Facebook image URL/filename. I don't think you can access the full album per se, but you can definitely locate the profile.
that's because the image urls actually include the profile id.