On Sun, Nov 29, 2009 at 10:19 AM, chris hofmann <chofm...@meer.net> wrote: > There is some early thinking about the Jetpack security model at > > https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model
This looks like a great start. A few things you might consider: 1) If the Jetpack is not signed with a CA-verified certificate, you might consider having the developer self-sign the Jetpack. That could help with the issues raised in <https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Code_Updating> for unsigned Jetpacks. (You can check that the update is self-signed with the same key.) 2) The document doesn't explain how Jetpacks interact with web content (e.g., web pages). Many of the vulnerabilities in existing extensions are due to unsafe interaction with malicious web pages. You might consider if there is a way to structure the API for interacting with web pages to make that easier to do securely. For example, you could isolate the the content-touching parts of the Jetpack behind a JSON message passing interface, like you've done with third-party libraries. 3) One of the things we found in our study (which Adrienne has made public at <http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-139.pdf>) is that many extensions use nsIFile to store extension-local persistent state. You might consider providing an alternative API (e.g., something like localStorage) that lets Jetpacks store persistent state without the authority to read and write arbitrary files. Adam _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
