Oh, wow :-) To put things in perspective, it probably helps to understand that virtually all video hosting sites perform batch, queue-based conversions of uploaded content. There is a good reason for this design: video conversions are extremely CPU-intensive - and an orderly, capped-throughput queue gives you much better resilience to DoS attacks.
Alas, this model is not very user-friendly: it may take good 20 minutes to upload a clip to Vimeo over my lowly DSL connection, and then another 40 to wait my turn in the conversion queue. If the video I uploaded turns out to be in an unsupported format (I'm still using MS-CRAM), I have just wasted an hour of my time. A simple workaround would be for Vimeo to have a client-side check that flags obvious problems before sending any data to the server. It's not a security feature, but it minimizes my pain. Does it make sense to duplicate this check on the server, too? You could, but I don't think it adds real value: after all, the converter will sooner or later perform the same check anyway. And for users who want to take Vimeo down, uploading tons of cat videos makes more sense: after all, converting them will cost more than just bailing out early on an invalid file. As for other attacks you mention: it's fairly easy to construct valid videos that also work as file archives, HTML documents, or shell scripts. Ultimately, sites that deal with user-supplied content often have to make tough decisions that don't fit in the neat defitions of ISO standards or academic papers of the old. Mechanisms such as quotas, various abuse-detection heuristics, rapid scalability - and even user education and good UX design - go hand-in-hand with more traditional approaches to minimizing risk. /mz _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/