I read up about it on the wiki, and I have some questions, but I think I have answers to, but am not 100% certain, and I don't wish to misrepresent things. I'm exploring 'secure' javascript cryptography from every angle I can, and caja came up as a discussion point. Some of the problems with javascript crypto (but not all[0]) are:
- Third-Party Problem: Any third party supplying code can poison the entire runtime - XSS Problem: Any XSS flaw can poison the entire runtime Now, imagine we wrote all our crypto-code and cajoled it. From what I see in the playground, while the cajoled javascript is opaque (much like gmail's javascript), there's no way to prevent innocent code (or perhaps I should say, malicious uncajoled code) from reaching into the cajoled code and fudging with it. So imagine we wrote all our our normal javascript, including all the fancy animation stuff, and cajoled it. And we likewise wrote our crypto javascript and cajoled it separately. It seems like it would be very difficult, if not impossible to have UI javascript that couldn't reach out into the document object and then into the cajoled crypto javascript, but let's say we still managed to do it. Any HTML injection flaw (XSS if you wish) could still reach into the cajoled crypto code and fudge with it. Are those statements accurate? -tom [0] I think all of them (omitting Poisoned Caches) are outlined here: http://lists.w3.org/Archives/Public/public-identity/2011Dec/0064.html
