Live data from Hacker News

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

chrishateswriting.com

121–130 of 139 posts

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

#121
post #43

Earlier quoted context omitted.

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.

If the urls are guessable then someone could harvest images without having been given urls by authorized users.

[deleted]

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

#122
post #62
post #55

We wanted to do this at a news site I worked for (since we had way too many cookies) but the problem was Google news. On 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.

Set cookie for www.example.com?

Unfortunately they used various subdomains for things.

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

#123

Earlier quoted context omitted.

No need, because you can gzip compress, which will make even better savings than that (because it can also compress and save space taken by tags etc, not just class names).

You could do that and gzip though; it would probably yield some savings. An obfuscator generating code à la iocc efficiency would be quite neat (e.g. http://www.ioccc.org/2012/endoh1/endoh1.c )

>You could do that and gzip though; it would probably yield some savings.

Nope. That's classic non-engineer thinking. The same kind of thinking that does "optimization" without profiling.

Let me introduce you to my friend: http://en.wikipedia.org/wiki/Diminishing_returns

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

#125
post #15
post #9

I doubt domain length will really make any difference, gzip compression should take care of a longer domain name.

The 50 bytes figure represents a compressed response. (We actually write all of our pages compressed to disk before serving them -- nothing is served dynamically. But that's for another post...) The example below isn't the most scientific, but should give you a rough idea. Test index page with different static URLs: URLs as 4cdn.org -- 23261 bytes compressed URLs as 4chan-cdn.org -- 23311 bytes compressed URLs as 4ch…

Can someone with more ZIP-algorithm knowledge than me explain why a difference in word length of 5 characters can result in a difference of compressed result length of 50 characters? I mean, a reference to a 1000-character word takes as much space as a reference to a 1-character word?

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

#126
post #46
post #44

Earlier quoted context omitted.

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…

I've found that uglifyjs does about as good a job as Closure Compiler, but waaay faster. Could be a nice speed up in deploy times for you.

closure kicks uglify for size when compiling with advanced optimisations.

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

#127
post #114

Earlier quoted context omitted.

Flat files on a disk == awesome

Why even write the html to disk? 4chan flushes history so aggressively I'd think you could fit all the high-traffic stuff in memory. if there's a power-blink and the posts get lost? Its 4chan.

Without fsync, its effectively that; but you get atomicity (with unlink etc) and can use multi process etc.

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

#128

Earlier quoted context omitted.

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.

Or printing out and handing it over.

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

#129
post #105

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.

You can... you just have to shell out money for a 4chan pass :\

I have one.

> "4chan Pass users may bypass ISP, IP range, and country blocks" > "Pass users cannot bypass individual (regular) IP bans."

So, if some random spammer uses the same VPN server, it gets blocked by an individual ban. This rapidly happens to all popular shared VPNs.

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

#130
post #126
post #46

Earlier quoted context omitted.

I've found that uglifyjs does about as good a job as Closure Compiler, but waaay faster. Could be a nice speed up in deploy times for you.

closure kicks uglify for size when compiling with advanced optimisations.

I found that the advanced optimisations broke our Javascript when I compared the two a couple of years back. We weren't interested in rewriting our Javascript to make it compatible with the Closure.
Post reply on HN