Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was.
Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java See this discussion on Android image processing: https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.
