Thanks for your reply. This is Thursday in the UK so I'm going to pre-emptively apologise for this rant. But we in the infosec community informed the wider comm

Thanks for your reply. This is Thursday in the UK so I'm going to pre-emptively apologise for this rant. But we in the infosec community informed the wider community in 2008 of the problems of Java Serialiazation. That is 8 years ago. Sami Koivu, peace be upon him in December 2008 showed that arbitrary deserialisation in Java was a security risk (http://slightlyrandombrokenthoughts.blogspot.co.uk/2008/12/calendar-bug.html http://slightlyrandombrokenthoughts.blogspot.co.uk/2008/12/c...). Not to mention that SERIAL-5 (http://www.oracle.com/technetwork/java/seccodeguide-139067.html http://www.oracle.com/technetwork/java/seccodeguide-139067.h...) of the Java Security Guidelines for Java SE has this to say: Guideline 8-5 / SERIAL-5: Understand the security permissions given to serialization and deserialization Permissions appropriate for deserialization should be carefully checked. Additionally, deserialization of untrusted data should generally be avoided whenever possible. And do you want to have a guess as to how many times Serialization was used to bypass the Java Sandbox between when Sami Kouvi made his blogpost and someone made a con talk on about Apache. Hint: it is greater than 1. [https://tyranidslair.blogspot.co.uk/2013/02/fun-with-java-serialization-and.html https://tyranidslair.blogspot.co.uk/2013/02/fun-with-java-se...] We have also demonstrated numerous times to the programming community that deserialzation of user data is dangerous. For example Stefan Esser has shown numerous times that PHP deserialization is dangerous both because PHP deserialization is a source of bugs in itself and because it is a source of bugs because it interacts with application code in unexpected ways. We have seen the same thing in both python with unpickle and ruby with YAML. I'm going to let you in to a secret within the infosec community. You can find bugs by just applying existing research in new and novel ways because developers do not follow security research. I feel like I'm falling into some rationalism fallacy by ranting at you because you are doing something useful to improve security. But you could be doing much much more. You have a voice and people will actually read your blog as compared to Sami :( You could have mentioned that we people should stop doing ObjectStream#readObject() or you could have pushed for updating the JavaDoc to say: THIS IS A BAD THING DO NOT DO IT. EDIT: apologies to anyone that realized that java serialization was bad before the Sami post. I wouldn't be surprised if this was part of the Java secure code guidelines before then or if someone had exploited the issue before then. It just so happens that Sami's post was my introduction to Java Serialization vulnerabilities.