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.
Small things add up: 4chan's migration to a cookieless domain
71–80 of 139 posts
Re: Small things add up: 4chan's migration to a cookieless domain
#72Earlier 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.
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
#73Earlier 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.
Re: Small things add up: 4chan's migration to a cookieless domain
#74I'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).
Re: Small things add up: 4chan's migration to a cookieless domain
#75Earlier 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 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> 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…
Re: Small things add up: 4chan's migration to a cookieless domain
#77I'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).
https://developers.google.com/analytics/devguides/collection...
Re: Small things add up: 4chan's migration to a cookieless domain
#78A 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…
Re: Small things add up: 4chan's migration to a cookieless domain
#79> 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…
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> 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.
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.