Live data from Hacker News

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

chrishateswriting.com

71–80 of 139 posts

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

#71
post #21

Earlier quoted context omitted.

I'm interested in learning more about _how_ secure random URL parts are, and what kinds of attacks are seen in practice. Presumably an IP would get blocked after enough 404s?

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.

Why even include the original name of the file to begin with, though?

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

#72
post #69

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.

I wouldn't agree. There are completely legitimate reasons to set cookies on *.domain.com -- it isn't "clueless/stupid" to do so, just less ideal.

I wasn't making a statement, just trying to clarify and then making an analogy to verify my understanding. I think I omitted a question mark where I should have had one.

Certainly, it is not automatically a bad idea to set such cookies. I see that.

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

#73

Earlier quoted context omitted.

I kind of like it for FB. It's nice to be able to easily show a friend a photo, whether or not they are friends with the person who posted that photo and sometimes even whether or not the friend has a FB account.

Nice for you, but potentially not so nice for the poster of the photo who thinks that only his or her friends can access it.

Nothing that right-click, save, upload to imgur couldn't accomplish though.

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

#74
post #52
post #49

I'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!

Well it's a single kilobyte, but 100 KB in aggregate. 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).

Have you ever thought of running server-side analytics?

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

#75
post #58
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

78.75%? That's great news!

I imagined a lot of people would be using mobile and I know that Safari iOS doesn't support SPDY. Does this mean that > 80% of users are browsing on desktops, or is it possible there's a mobile app that's reporting a false user agent?

Or maybe all the iOS users fell victim to waterproof tests...

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

#76
post #14

> 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…

Sounds like a situation where X-Sendfile could help?

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

#77
post #52
post #49

I'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!

Well it's a single kilobyte, but 100 KB in aggregate. 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).

The newest version of Google Analytics eliminates most of the cookie bloat. There's now just a single id cookie that's around 30 bytes or so.

https://developers.google.com/analytics/devguides/collection...

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

#78
post #44

A quick look shows that you could minify the Javascript quite a bit more (which is relatively easy, and would save a lot more than 50 bytes). You might also look at inlining all of the Javascript into the HTML directly (this is what Google does), which saves the extra HTTP requests. You could also do this with some of the persistent images on the page (logo) and inline them with base64 (but I don't think it actually…

Thanks for pointing that out. We minify production JS using Closure Compiler but sometimes that leaves room for improvement. There's definitely a tradeoff between inlining JS and small images, but I think in our case it makes more sense to leave them external to leverage browser (and since we use a CDN for static content -- edge) caching. I believe I tried to get ngx_pagespeed up and running when it was announced, bu…

It is the second time in this discussion that you mention the downsides of using FreeBSD, and you present it as an historical choice. Do you have upsides as well? What were the criteria that made you pick, 10 years ago, FreeBSD over another OS?

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

#79
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…

the markup before is already 1,836 bytes

All those bytes are justified because they are rendered on the screen provide direct utility to the user. The extra 50 bytes does nothing but slow the page down.

there would be a lot more potential in the source by shortening CSS class names etc

There is no either/or here: this can and should be done as well.

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

#80
post #79
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…

the markup before is already 1,836 bytes All those bytes are justified because they are rendered on the screen provide direct utility to the user. The extra 50 bytes does nothing but slow the page down. there would be a lot more potential in the source by shortening CSS class names etc There is no either/or here: this can and should be done as well.

Is there a good CSS minifier which looks at the CSS as well as the HTML, and shortens class names automatically? In most cases I don't really care what the class names are in the final HTML, as long as they match up with the CSS.

I realize there are a lot of things that could go wrong, such as * correlating the HTML and CSS for an entire site instead of just one page * dealing with third party dependencies that require certain class names to be used

Just wondering if there's any work already done with this approach.

Post reply on HN