However, according the HTTP archive websites make about ~90 requests per page [1]. The average browser does about 6 requests per hostname, and 15-20 total [2]. In this situation, our critical path has at least 4 requests, thus we are paying 4xRTT in just latency.
Yeah, the attack barely work without the lock, as you would have to rely on pure luck on getting the port delta small enough.
Because of the lock, the first request you make after you get the lock was likely garbage, and then you have 250ms to get as many requests as you can. Performance here was key, since you couldn't easily do simultaneous requests so you ere limited by the number of round trips you could do in that time.
Some people managed to do simultaneous requests, but you had to do more book keeping since the delta on the first responding webhook contained all the information (eg, for a failed first chunk on N requests, you would expect a difference of 2*N). You would also have to synchronize with the lock, which isn't easy.
Due to load on the servers, SSL negotiation was extremely slow, so using a Keep-Alive connection was required for decent performance.
My final Python implementation managed to eliminate about 4 candidate chunks/sec even under heavy load. I managed to finish #90.
Using S3 as an origin isn't a terrible idea, especially if you want very high availability for a low ops overhead.
We use S3 behind Edgecast, and it works great.
We also have a standby server and CDN in case we need to failover at the DNS level in the unlikely case either of those go down. This may be overkill for other sites, who probably should spend time planning for far more likely interruptions to availability (EC2 interruptions, etc).
CloudFront invalidation is definitely a pain, since they have no global purge or prefix purge (/bar/foo/*). CloudFront also won't handle Content-Encoding negotiation for you, though it will Vary on it if you ask it to.
We used CF in the past, and had a bunch of machinery to purge just those assets that changed.
S3 is wonderful, but CloudFront is missing a few bits, despite having a great price at a low volume.
Given that this is licensed Creative Commons under Attribution, Non-Commercial, and No Derivative Works, -- and notwithstanding a general desire to respect the authors wishes (http://blakemasters.tumblr.com/post/22922727433/read-share-p...) -- it becomes a question as to whether it is a truly derivative work.
Since the meat-and-potatoes of the work is entirely textual, and faithfully reproduced, you could argue that work is non-derivative and within the license.
CC puts two additional restrictions on “transformation” and “alteration,” but it is not clear on what those would be. It would be reasonable to argue in the spirit of the license, that as long as we do not alter the meaning, intent, or spirit of the original work we did not alter or transform it. Any stricter interpretation would like defeat the purpose of licensing something CC, as any form of distribution requires some, however small, amount of altering (eg, I have to convert it to photons before I can hit your retinas).
There are precedents for what is considered a “derivative work” in the US, but usually as to define “new” works that may desire protection, but not likely as many in this reverse situation where we wish to argue that a slightly altered version is equivalent.
If I made printed-to-PDF from my web browser, is that a derivative work? a transformation? a substantial alteration?
If we take a strict (perhaps stretched) interpretation of Masters desires: you should read it only on my website and share only links to it from there? Then why license it as CC BY-NC-ND? Such interpretation of the license gives you no rights you did not have before under fair use (or fair dealing).
Can you iterate on this a bit more.
Based on this I am actually a bit unsure if blake is not miss-interpreting BY-NC-ND at all.
E.g.
http://mollykleinman.com/2008/10/20/cc-howto-no-derivatives/
interpretes the legal text like this:
"The key words here are “recast, transformed, or adapted.” A derivative work involves enough creativity and originality that it constitutes a new copyrightable work. Simply converting a work from one medium to another — from print to digital, or CD to MP3 — does not produce a derivative work."
Not that it matters - they asked people not to create epubs/pdfs so i removed mine just to respect the wish.
That's a great link. I think it matches my interpretation of the No Derivatives provision.
I think you are very much in the free and clear from the standpoint of the license. The language of the CC license does say that you are free to reproduce it and include it in collections. It even suggests that the media in question is not important: "rights may be exercised in all media and formats whether now known or hereafter devised". There's no point in making reference to "hereafter devised" media if they medium is assume to be fixed at the time of license.
Further, "[the] rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats" which clearly gives you the right to change mediums as long as we do not violate the clause on adaptations.
The adaptation clause, of course, it up for some interpretation. However, the definition of a derivative work under US Copyright law is likely what was envisioned. If it was not, it would have probably been a huge blunder to call this the "No Derivatives" license. The standard test here seems to be whether the transformation had any significant creative input, and since you conversion was almost purely mechanical, I would argue that it was not significant enough to be considered a derivative.
One thing you did forget to do was to include the CC license itself.
Nevertheless, I donated $50 just for the excellent work they do on OpenSSH.