My contact info's in my profile.
Is it because you offer a lot of training or simply because you figure he'll pick up what he needs fairly quickly and eventually surpass the app security expert? Or is there a different reason?
I asked a similar question to Zed Shaw at CUSEC last year. Something along the lines what do you think about Joel Spolsky saying you should only hire the very best. He said he prefers someone who's willing and able to learn because he'll just teach them and they'll become a very valuable person.
For one thing, even though everyone always goes around arguing that there's only one right way to do things, the fact is that any given organization has their own habits and methods and reasons, and very experienced people may be more reluctant to "fit in".
You have the experienced people who are stubborn and want to do things their way because in their experience that works best but you also have the experienced people who know that the best way to do things is the way that the team is best structured to implement well and maintain efficiently in the future.
The passionate people have the same problem. Passion brings on a strong desire to do things "right" so some will refuse to adapt to the team, their passion dictating what the team should do and others will be more passionate about results rather than methodologies.
It's simple. The best security researchers are people who have (or at least could) ship software. There is a big swath of high-end work that you simply can't deliver if you can't code. That's where Matasano plays. I suppose you could be a very strong Payment Card Industry certification consultant just by getting very good with WebInspect, but to reverse an embedded kernel, isolate the code that handles a protocol you caught on the wire, and then code a fuzzer for that protocol, you need to be able to read code in a bunch of languages and write code very well in at least one of them.
As a consultancy, there are fringe benefits to our clients from us staffing projects with former devs:
* Devs know how to talk to other devs without sounding like morons or bureaucratic checklist-checkers, and sounding like that is a big problem in my industry. For instance, devs don't tell clients that single-line changes to shipping codebases are "trivial" and should only take minutes to roll out.
* Devs can provide remediation advice that is better than "switch to parameterized prepared statements" or "check input better".
But the reality is, we like working with devs because they are on the whole better at breaking software. They read faster, they don't balk at writing complicated test programs, and they know how pieces fit together --- and those junctions are where software usually fails worst.
I sure hope you're speaking given that they just today announced it on the website http://2010.cusec.net/11-20/thomas-ptacek-security-researche... =)
All the advice I can give you is be honest and be yourself. CUSEC has always been very informal compared to most other conferences, more of a discussion between students and people they respect more than anything else.
John Kopanas, the founder of CUSEC, mentions it every year. He created CUSEC simply because he wanted to talk to and hear from people in the software engineering community that he respected. It's always been that every since.
EDIT: I tried to bet one of my friends that you would have the most technical talk at CUSEC. He wouldn't take the bet. If your talk is anything like this post http://chargen.matasano.com/chargen/2009/7/22/if-youre-typin... though I can't wait to hear it!
If people tell me real-world crypto is going to keep people in their seats, though, I'm totally down for that; it's a much easier talk.
I don't feel very comfortable giving advice about the direction of your talk; I can only speak for myself. If you have questions I highly recommend you ask the director of presentations. That said, personally I think the case in favor of DRM could be quite interesting since I've never heard a technical person argue in that direction. (At least not while doing more than simply assuming the token devil's advocate role.) If you make a good case you'll definitely get lots of questions/objections after!
* That the security goal of DRM is not about absolute platform integrity, but about meeting the commercial objectives of content providers, and that when you relax constraints from "absolutely protecting media" to "making sure titles are difficult to pirate during their new-release window to maximize profit", you get opportunities for interesting approaches to security, like renewability.
* That taken together, these two ideas suggest that DRM is actually a really interesting CS problem, and --- leaving politics out of it --- even if you believe it's destined to fail, it's worthy of study.