Who You Gonna Trust?

I recently wrote about Adobe’s new Flash Player 9 and Flex 2 solutions, and mentioned a forthcoming Adobe eBook solution that leverages these technologies. Some folks took issue based on a perception of security problems with Adobe software, citing security advisories such as this. The criticism even descended into satire, warning readers of “Stephen King level horrors” ahead. Well, the bottom line here is (to paraphrase GhostBusters): “Who You Gonna Trust”?
Satire aside, security is a serious topic and merits serious consideration. Before specifying or redistributing *any* reading system client software publishers should consider the security implications, including the track record / capabilities of the proposed vendor (or themselves, if contemplating supporting a OSS/home-grown solution).
While Flash Player and Adobe Reader have not been entirely free of security issues, I believe Adobe/Macromedia’s track record is quite good and compares favorable to other major SW vendors – including browsers. I’m not focused in this area but we’ve pretty much had researchers discovering hypothetical exposures, vs. users experiencing actual malware attacks – in fact the exposure above was discovered by our own dedicated security team. Adobe requires security audits before releasing software, and we treat hypothetical security exposures as critical, issuing patches frequently. We also follow a practice of giving users control over their security and privacy settings. Adobe has distributed far more client software (non-OS) than any one else in the world. When you have 100s of millions of installations are you going to have some security issues? Absolutely. But those who adopt Flash Player or Reader can have confidence in Adobe to address these issues.
Some links:
Adobe security advisories main page
Flash Player security
Detailed white paper on Adobe Flash security
One positive factor here is size. Flash Player is relatively small and that means that the code has proportionally few nooks and crannies (in security geek speak it “presents a smaller threat surface”) – many times smaller than (for example) a J2SE Java VM.
Again, I’m not saying Flash Player is perfect – nor that I personally like all applications of Flash, particularly not in-my-face ads – just that as a basis for a Rich Internet Application (RIA) that goes beyond HTML’s capabilities FP’s security footing and track record is a plus, not a drawback, at vs. any alternative that I’m aware of (certainly compared to trusting an arbitrary native-code Windows app or ActiveX control). If someone tries to sell you another eBook reading system – ask them about their implementation architecture’s sandbox model, their dedicated security team, their track record in issuing patches, their financial wherewithal, and their demonstrated ability to manage large-scale client deployments.
A separate issue I got feedback on is using SWF for eBook content – and I may have confused some people about our intentions on this front. Actually Adobe already has a solution that does this – FlashPaper 2. While FlashPaper delivers some ease-of-use advantages vs. (say) Adobe Reader 7, it did not take the world by storm – if it had I might be a Macromedia employee now ;-). Content publishers want interoperability, transportability, and archivability, and solutions that directly consume open standard formats like PDF and XHTML deliver these benefits. Whereas turning documents into SWF, Mobipocket .PRC, PalmDoc, or BBEB is a one-way trip (although if I had to “compile” my content to one of the above, the format that’s supported on 98% of Internet PCs would arguably be the best choice, and that’s exactly what a number of digital magazine vendors are doing).
That being said, at the point where documents blur with applications – for example learning systems – there’s clearly a role for programmatic interactivity on the client. And for handling interactivity, I’d certainly trust SWF over a native Windows EXE.