story
By your analysis, Gmail could implement a feature that lets a sender run arbitrary JavaScript in the recipient's browser, and this would have no security impact as long as the JavaScript sandbox was not escaped. But in reality this would be a huge breach, because there are valuable things inside the sandbox that attackers should not have access to.
Put another way, this wouldn't help defend Chrome from NaCl, but it would help defend the NaCl app from it's clients. This would be in Google's interest to implement because it would make the platform more attractive to developers.
I see your point. I guess you're saying, there could be a photo editing app in which Alice can send pictures to Bob, and Mallory might send a malicious picture to Alice that coerces her client into betraying all its photos.
Why would Google want to not bother applying a belt-and-braces exploit mitigation that costs 0% CPU?
But NaCL is also used to isolate "built in" embeddables e.g. Flash, which I have used as an example of a NaCL plugin that comes with chrome in both the previous posts?
Another example is the voice activation plugin that got them into so much trouble recently...
Imagine you walk past your colleagues computers saying things like "let's google something naughty" loudly...
And now let's extend that to playing an audio snippet that invokes a stack smash? :)
